Workflows · 1 of 10

The front door: request intake

Almost every marketing operations project starts here, because it is the problem everyone feels: work shows up by email, chat, and hallway conversation, with no brief, no deadline, and no way to say no.

Workfront gives you two front doors. Pick on purpose.

This is the fork most first-time setups get wrong, and it is worth two minutes before you build anything. Workfront can take in requests two different ways, and they produce two different things.

What happens after someone hits submit

Here is the whole path, from the person asking to the project that delivers the work. The dashed line at the bottom is the part that makes this worth building: the project Workfront creates comes back linked to the original request, so the plan and the work stay connected without anyone copying anything.

Press Play to walk a request through it, pick a different triage outcome to see where the other paths end, or select any box to jump straight to that step.

What to capture on the request

Keep the form short enough that people actually use it, and structured enough that you can triage without a follow-up email. These are the fields that earn their place. Field types in brackets are Planning’s own.

Setting it up

1. Build the form on the record type people are really asking for — usually Campaigns or Tactics, not a separate Requests record type. A request that becomes the campaign is one record with a history; a request that spawns a campaign is two records to keep in sync.
2. Add conditional fields by request type so a social post request does not ask for print specifications.
3. Set approval rules in the form’s settings for the thresholds that genuinely need a decision: spend above a number, a regulated product category, an executive audience.
4. Set the default permissions submitters get on their own requests, so people can see what they asked for without seeing the whole queue.
5. Add the automation: when triage status becomes Accepted, create a Workfront project from the template that matches the request type. If the form uses a multi-select for formats, the automation can create one project per selected choice.
6. Test it as a normal user, not as an administrator. See the warning below.

Working the queue

Once this is running, triage is a short, repeatable pass: pull everything marked New, classify it, set urgency and an owner, accept or send it back, and check that accepted requests actually produced a linked project. Then look at the queue itself — not just the requests — because queue health is what you bring to a capacity conversation.

# A triage pass, summarized the way it is worth reporting

Triaged 23 marketing requests
  8  accepted, projects created from the standard campaign template
  11 accepted, routed to the social tactic queue (no project needed)
  4  sent back as needs information — no audience, no needed-by date

Most urgent
  1. Launch communications support, Asia Pacific  — needed Aug 18
  2. Black Friday email series, 4 variants        — needed Sep 9
  3. Claim update for the fall campaign           — needed Aug 22

# Queue health is the part leadership actually needs
  6 requests older than 5 days, all with one triager
  Oldest: 11 days
  Decline rate this quarter: 11%, up from 4%

With AI in the loop

Planning has no field that fills itself in with AI. What works is the copilot pattern: a Fusion scenario watches new requests, sends the free-text description to a model, and writes a suggested request type, urgency, and owner into ordinary fields. The triager works a view sorted by those suggestions and commits them in bulk.

Don’t do this

Limits worth knowing here

Sources

• Adobe Workfront Planning documentation — terminology, request forms, automations, object limitations: Experience League article index
• Planning API reference, versions 1 and 2: developer.adobe.com/wf-planning
• Package contents and entitlements: Adobe Workfront product description