WUG Central Recap - Building a Connected Marketing System with Workfront Planning, Core, & Fusion

Curious what actually goes on inside a Workfront user group session? Here's a taste. In a recent Workfront Central session, Deborah Baker (Marketing Workflow Leader) and Megan Lehman (Workfront Developer) walked through how they built a fully connected marketing system of record using Workfront Planning, Core, and Fusion, the kind of hands-on, behind-the-curtain walkthrough you won't find in the docs. This recap is the technical companion to their Perspectives article, Designing Workfront adoption for the long haul, which covers the strategy behind the build: people first, process second, system third. Here's how it comes together in practice.

The challenge

The team set out to build an end-to-end template environment for a marketing-heavy organization, a major consolidation effort that condensed multiple separate intake requests into one streamlined flow. A request now comes in through Planning, spins out a program, a hero deliverable, and a request queue for one-off derivatives tied back to that hero, all visible in both environments through dashboards, reports, and boards. The goal: simpler intake, cleaner execution, and real leadership visibility across the organization.

Start with your form fields, not the build

Before touching Workfront, figure out what data you actually need to collect. Planning is organized into taxonomies and operational records. The team held a heavy stakeholder meeting to define the bare minimum needed to spin an environment up into Core, then mapped every connection in Lucid Charts first. A useful reminder: you don't need a lot of taxonomies, or any at all. Add them only when other teams in the enterprise genuinely need shared connected fields.

The trigger that connects Planning to Core

The link between the two channels is a custom “Ready for Program” field. Set it to Yes and Fusion begins the build. Keeping it a form field was intentional. Campaign managers who aren't ready can populate their Planning record first and trigger the build later. One caution to build governance around: because it's a single field, removing the Yes and re-adding it can fire a second build.

Building the Core side

Moving a request into Core means copying it as a new request there, which requires a mirror form: every Planning field needs a place to land (so field changes must be governed in both places). The clever part solves a real usability problem: when a request converts to a project, intake fields lock at the project level, but board users can only see task-level fields on their cards. So Fusion copies the fields each role needs down to the task description, so design sees only design fields and editorial sees only editorial fields, with no hunting through project details.

Drop a pin: store the Planning record ID

One of the most useful takeaways. When derivatives are requested later from Core, matching them back to the right Planning record by name is unreliable. People rename things. So when Fusion first creates the program, it grabs the Planning record ID and stores it on a program-level field in Core, like dropping a pin when you park your car. Future scenarios find the exact record instantly. That pinned ID doubles as a checks-and-balances signal: if a Core record is missing it, something went wrong.

Governance and user adoption

When heroes could be requested directly from Core, some requests weren't calling back to Planning, creating records on one side with nothing on the other. The fix was forced change management right in the intake form: a simple image reminder asking “are you sure you're in the right location?” that closes the wrong door while explaining why. Within 24 hours, three of four stakeholders who typically struggled started using the system as intended, cutting significant PMO rework.

They paired this with a one-sheeter. A seven-page manual only gets read by admins. The one-pager instead gives users exactly what they need: what each request type is, and direct links to submit a program, a program plus hero, or a derivative.

The two Fusion scenarios

Scenario 1: New program (and optional hero).

• Program only: creates the program, closes the request, updates Planning links. The record is easy to find here; it's what triggered the scenario.
• Program + hero: converts the request to a project, sets PM / sponsor / owner from intake, trickles fields down to marketing, editorial, and design tasks, notifies the PM to review and turn it on, then reconnects everything in Planning.

Scenario 2: Derivatives / one-offs.

These originate in Core and watch for “Ready for Project” status. Much of the scenario just resolves which program field to use, since programs are filtered per portfolio. It then splits on where the request came from: the front door (menu → Requests) asks for far more detail, while requests made out of the hero project already inherit program and hero context. All paths then trickle fields to tasks, notify the PM, and reconnect to Planning via the pinned record ID.

The trickiest gotcha: Fusion overwrites connected records

By default, when Fusion adds a connected Planning record, it overwrites what's there rather than appending, a problem when derivatives are added over time, leaving you with only the most recent connection. The workaround: build a formula that reads the currently connected records, combines them with the new project's ID, and writes the whole array back. If you're building something similar, plan for this from the start.

What's on the horizon

• Native Planning automation to move portions of these scenarios out of Fusion and manage operational cost.
• A derivatives operational record, making Planning “true north” so everyone works the same way.
• Bulk uploads: Deb built a macro-enabled Excel doc to mass-upload programs into Planning, and is happy to run a follow-up session if there's interest.
• Prepping for AI as it comes into the Workfront universe, keeping governance and future agents in mind.

The bigger takeaway: meet users where they are

The through-line was adoption. Designers who were used to working at the task level didn't want to drill up into projects, so rather than force a change, the team built a solution that met them where they were and gave project managers their time back from manual setup. None of it happened overnight: a three-and-a-half-month stakeholder conversation whittled a first-draft intake of hundreds of questions down to 15, guided by one question: is this needed to start the work, or something that surfaces during it?

Sessions like this are exactly what the Workfront user groups are for: practitioners sharing real builds, hard-won lessons, and the workarounds you can't find in the documentation. If you're not already part of one, come join us: workfront-augs.adobe.com. You'll find a whole host of chapters and leaders, and the sharing is the best part.