Cascading Custom Fields When Accepting Campaign Requests

Modified on Tue, 30 Jul at 11:35 AM

TABLE OF CONTENTS


Features described in this article are not included in all subscription plans. 
Interested in expanding your feature set? Please reach out to success[at]lytho[dot]com. Have a question about your current subscription? Contact our Support Team for further assistance.



Save time at request intake, prevent data entry errors, and make reporting even more useful by indicating which campaign custom fields' data should be inherited by the projects created when the request is accepted. If your stakeholders currently request work using a campaign request form, you can enable this setting for each custom field you'd like to cascade.


This feature does not apply to Campaigns and  rojects created ad hoc within the system.


Enable Cascading Custom Fields

To enable this feature, configure the following options in Account Settings > Custom Fields:


  • “Applicable to” enabled for both Campaigns and Projects (note: the cascade values feature is not available unless the field applies to both types of work)
  •  "Cascade Values When Accepting Campaign Requests” toggled on



Additionally, you must configure at least one of the following options:


  • Form Design: Mapping the custom field on the form allows requesters to provide the information directly into the campaign custom field. That information is inherited by all projects when the request is accepted. 
    • You’ll need to submit a request to our Support team for any changes needed on forms. 
    • Consider making this field required to ensure requesters can not submit a request without providing that necessary information.

  • Account Settings > Custom Field: “Required for” Campaigns: If you don't want to ask your requesters to provide this data, you can require your traffic team to populate the value(s) before accepting the request into a project. The Accept Request modal prompts the acceptor to populate the necessary custom fields, which then cascades down to the projects. 



Most commonly, the custom fields are mapped only on the campaign form (not on any project/deliverable forms). This chart below walks you through the possible configurations and the outcomes you can expect from each.  

 

Mapped on Campaign Form?
Required Form field?
Required For” Campaign Selected?
Outcome
Yes
Yes
Yes
  • Requester cannot submit the request without providing custom field information
  • Accept Request modal will prompt Acceptor to review/edit the custom field
Useful for information required to complete the work but needs the Acceptor to validate it before accepting the request. Example: GL Code, Primary Contact Info, Brand
Yes
Yes
No
  • Requester cannot submit the request without providing custom field information
  • Accept Request modal will not prompt Acceptor to review/edit the custom field
Useful for information that is required for the work to be completed, but does not need to be validated/reviewed by the request acceptor. Examples: Department, Region, Call to Action, Target Audience, Product
Yes
No
Yes
  • Requester can submit the request without providing custom field information
  • Accept Request modal will prompt Acceptor to review/edit the custom field
Useful for information that’s nice to have from the Requester and, if provided, needs to be reviewed/validated by the Acceptor. Examples: PO Number, Rush Status, Compliance Requirements
Yes 
No
No
  • Requester can submit the request without providing custom field information
  • Accept Request modal will not prompt Acceptor to review/edit the custom field
Useful for information that’s nice to have from the Requester, but not critical to completing the work. Examples: Secondary Messaging, Tone
No
n/a
Yes
  • Requester will not see the custom field and, therefore, cannot enter a value
  • Accept Request modal will prompt Acceptor to review/edit the custom field
Useful for information that is required to complete the work, but is internal to the team. Example: Project Owner, Sprint, SLA, Project Type, Priority



Additional Considerations


Custom Fields mapped on both campaign and deliverable forms

In some instances, Requesters may need to specify a unique value for custom fields on some deliverables. For example, a print deliverable may have a different point of contact than the digital deliverables being requested. You can still configure custom field values to cascade down from the campaign to projects but, to accommodate this workflow, the custom field for “point of contact” would need to be mapped on the print deliverable forms as well. The campaign custom field value only cascades down to projects where the deliverable field was not mapped on the deliverable form or where the Requester left it blank on the deliverable. In other words, any values entered at the deliverable custom field level are always retained. 


Custom field values and project templates

Default custom field values may be pre-populated within project templates.  Any custom field values entered in the request or the Accept Request modal are used instead of the default project template values.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article