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 |
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 |
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 |
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 |
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 |
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
Feedback sent
We appreciate your effort and will try to fix the article