Cascading Custom Fields When Accepting Campaign Requests (Workflow)

Modified on Tue, 17 Dec at 2:07 PM

TABLE OF CONTENTS

Enable Cascading Custom Fields
Additional Considerations

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.