Answers.Body: <p>You are correct, you would not want to add those fields to the news items directly. Like you said, it would cause problems if you wanted a News item pinned on one service but not pinned on another one.</p>
  
  <p>The best solution here (imo) is to utilize a Matrix field (or possibly a Table or SuperTable field, depends on your preference). So I would create a Matrix field for your service entries called <code>News Items</code> or whatever. Than each news item block would have several fields:</p>
  
  <ul>
  <li>the actual related entry field where you would pull in the news entry</li>
  <li>a lightswitch field for <code>pinned</code></li>
  <li>a lightswitch field for <code>alert</code></li>
  <li>a date field you could use to expire the news block</li>
  <li>etc...</li>
  </ul>
  
  <p>This would enable you to set these settings on each news block on the individual service entries, so you're not muddying up the news items themselves or contaminating other service pages where you may want a news item "pinned" or "alerted". And again, you could also use a SuperTable or maybe even a Table field instead of Matrix - just depends on what you prefer.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T01:15:07.580Z
Answers.Text: Thanks Jalen. That sounds promising. I'd expect the matrix blocks to be a bit cumbersome for the admin, considering the simplicity of the functional need. Lots of moving parts for a couple of small switches. I'm sure it'll work though. I've never used supertables and want to keep it first-party if possible.
Answers.UserDisplayName: Jim
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T01:53:43.067Z
Answers.Text: Yeah I don't think it will be that bad at all... You could also use a dropdown or radio button field instead of multiple lightswitches if only one should be "selected" at a time.
Answers.UserDisplayName: Jalen Davenport
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-20T14:30:54.863Z
Answers.LastActivityDate: 2019-05-20T14:30:54.863Z
Answers.UserDisplayName: Jalen Davenport
Body: <p>I have a Services section in which I keep a related entry field for News. (News by Service) The News items to be displayed for each service are selected in a "News" entries field in the Service entry. For each related news entry, I need to be able to include Lightswitch booleans for "alert" and "pinned", each with different behaviors on the front end. For instance, when an admin adds a related news entry to a service, they also should be able to determine if that new entry is either an <em>alert</em> or a <em>pinned</em> news item, but only for the current service.</p>
  
  <p>I'm able to included related news in each service template, but I'm unsure how to accomplish having a lightswitch that appears for each related news item in the services cp. So that, for instance, news entry A is only an <em>alert</em> in Service B. Or news entry C is only <em>pinned</em> for Service D.</p>
  
  <p>I guess I could create pinnedInService and alertInService entry fields in the News section, but this seems convoluted. Maybe this is best done in the News item, rather than in the Services entry? I'd also like to be able to expire or unpin the news entries based on a date field (also per service). </p>
  
  <p>Any direction on how to accomplish this? Thanks in advance!</p>
  
Tags: <craft3><relations><entries-field><relatedto><lightswitch>
Title: How to include a lightswitch for each related entry in the source element of a relationship
ThreadText: # How to include a lightswitch for each related entry in the source element of a relationship
  
  (Asked by: username_0 on 2019-05-18)
  
  I have a Services section in which I keep a related entry field for News. (News by Service) The News items to be displayed for each service are selected in a "News" entries field in the Service entry. For each related news entry, I need to be able to include Lightswitch booleans for "alert" and "pinned", each with different behaviors on the front end. For instance, when an admin adds a related news entry to a service, they also should be able to determine if that new entry is either an *alert* or a *pinned* news item, but only for the current service.
  
  I'm able to included related news in each service template, but I'm unsure how to accomplish having a lightswitch that appears for each related news item in the services cp. So that, for instance, news entry A is only an *alert* in Service B. Or news entry C is only *pinned* for Service D.
  
  I guess I could create pinnedInService and alertInService entry fields in the News section, but this seems convoluted. Maybe this is best done in the News item, rather than in the Services entry? I'd also like to be able to expire or unpin the news entries based on a date field (also per service).
  
  Any direction on how to accomplish this? Thanks in advance!
  
  **Tags:** craft3, relations, entries-field, relatedto, lightswitch
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-05-20. Score: 1 | Accepted answer
  
  You are correct, you would not want to add those fields to the news items directly. Like you said, it would cause problems if you wanted a News item pinned on one service but not pinned on another one.
  
  The best solution here (imo) is to utilize a Matrix field (or possibly a Table or SuperTable field, depends on your preference). So I would create a Matrix field for your service entries called `News Items` or whatever. Than each news item block would have several fields:
  
  * the actual related entry field where you would pull in the news entry
  * a lightswitch field for `pinned`
  * a lightswitch field for `alert`
  * a date field you could use to expire the news block
  * etc...
  
  This would enable you to set these settings on each news block on the individual service entries, so you're not muddying up the news items themselves or contaminating other service pages where you may want a news item "pinned" or "alerted". And again, you could also use a SuperTable or maybe even a Table field instead of Matrix - just depends on what you prefer.
  
  > **Comments:**
  > **username_0**: Thanks username_1. That sounds promising. I'd expect the matrix blocks to be a bit cumbersome for the admin, considering the simplicity of the functional need. Lots of moving parts for a couple of small switches. I'm sure it'll work though. I've never used supertables and want to keep it first-party if possible.  
  > **username_1**: Yeah I don't think it will be that bad at all... You could also use a dropdown or radio button field instead of multiple lightswitches if only one should be "selected" at a time.  
  
  ---
  
  