Section 6 of 9

Build layers

Every build touches the same four layers. Knowing which piece belongs in which layer is what keeps a workspace usable a year after launch.

In plain terms

First you build the structure — the tables and how they link. Then the screens people use. The actual work stays in Workfront, and connections to other systems come last. Most stalled rollouts did those steps in the wrong order.

Four layers

Pick The layers to tour what belongs where, or The rollout order to see the sequence that sticks.

Figure 1. The four build layers. Blue is Planning, gold is Workfront Workflow, grey is the integration layer that crosses into other systems.

Four layers

Press Play, or select any box in the diagram, to walk through the layers one at a time.

Planning ships monthly and features arrive in preview before production, so treat this as a design split, not a permanent map of what can be done where. Check the current state before promising that something is an interface-only or API-only step.

1. Structure

Always built; everything goes through it. Three routes, in order of preference:

A workspace template — Basic, Advanced, or Enterprise: Marketing Management, or one of the other studios — then trim. Fastest, and the result is idiomatic.
The Workfront MCP server or the Planning API for anything beyond the template: more record types, custom fields, connections to Workfront objects and AEM, seed records. MCP runs under the user’s own permissions when it is configured; the REST API handles bulk work.
CSV or Excel import, which can create a record type from a file of up to 5 MB, 25,000 rows, and 500 columns. Useful because the taxonomy usually already lives in a spreadsheet. Import it, then add types and connections properly.

Spend the effort here: status values with meaningful names and colors, unique primary fields, connections with the right cardinality, and lookups that surface the two or three connected values people actually need.

Two decisions are effectively permanent. A record type cannot move between workspaces, and some field types cannot be changed once records exist.

2. The Planning experience

Views — the two or three each audience needs, grouped the way each audience thinks. Timeline and calendar need two date fields; deleting a field from a view deletes it everywhere.
Record page layout — field sections, set per record type. Worth doing on the one or two record types people open daily.
Request forms — conditional fields, approval rules, completion rules, default submitter permissions; an internal or a public link.
Automations — create connected records, projects (one, or one per choice of a select field, optionally from a template), programs, portfolios, or groups.
Sharing — workspace, record type, record, and view permissions are four separate grants. Light and Contributor users also need a layout template that exposes Planning.

3. Execution, in Workfront Workflow

What should not be rebuilt in Planning: projects and tasks from templates, with dependencies and assignments; request queues for execution-level tickets; proofing and approvals, the compliance-grade surface; documents on the project that produced them; resource management, timesheets, and utilization; reports and dashboards; and business rules.

The join between the layers is the connection field plus automations that create projects from templates. Build it deliberately: decide whether projects hang off Campaigns or Tactics — usually Tactics from mid-size up — and surface two or three project lookups on the Planning record.

4. Integration

Only when the workflow crosses a system boundary or runs on a schedule: Fusion scenarios for marketing platform and CRM sync, performance summaries, enrichment, cross-system approvals, scheduled digests, and AI modules; event triggers — record watchers and webhooks — for parallel-run migrations and notifications into Slack or Teams; AEM Assets and GenStudio connections, each with its own license; and the REST APIs for bulk work, migrations, and custom surfaces.

Confirm Fusion before designing around it. It is bundled at some tiers and an add-on at others. Check its current performance guardrails before building anything that runs often.

When someone outside needs in

Marketing operations always ends up needing someone outside the Workfront user base to see or submit something. Four options, in order of how often they are the right answer:

External access, most common first.
Option	Use it for	Watch out for
1. A publicly shared request form	Agency briefs, partner requests, field-team intake — anyone with the link submits, no account needed.	Forms with Workfront object connections cannot be public. And a public link is genuinely public.
2. An External user license	People who must take part in review: proof reviewers, client approvers, outside agencies. Usually what “client portal” really means.	They get the proofing surface and its audit trail — not your plan.
3. Scheduled reports and shared dashboards	Stakeholders who want to receive status rather than log in.	Low effort; low interactivity.
4. A custom surface on the Planning API	A branded portal, an embedded view, a self-serve tool, an anonymous public page.	Real work: OAuth 2.0 credentials, a server-side proxy — never ship credentials to a browser — and a budget inside 200 requests per minute.

Planning views are not an external surface. Sharing a workspace with a client means giving them a Workfront identity and permissions, which is rarely what anyone wants.

What a finished build hands over

Most builds are Planning plus Workfront, natively. End with what was built, a link, and the one to three configuration steps that matter most.

✅ Built
  Marketing workspace — 6 record types in 2 sections, fields, connections
  Campaigns ↔ Workfront projects · Deliverables ↔ Brands, Markets, Audiences
  Seed records, and a link to open it in Planning

🎨 Configure in Planning
  Timeline on Campaigns grouped by brand, filtered to FY26
  Request form on Campaigns, conditional by request type, approval rule over $50K
  Automation: Triage status = Accepted → project from “Campaign — standard”

🔧 Configure in Workfront
  The project templates the automation uses
  A dashboard for the leadership audience

When the workflow crosses systems, add an integration section: for example, Marketo program performance written to campaign summary fields nightly, AI triage suggestions written to suggested-owner and suggested-urgency fields, and a Teams notification when a deliverable changes status. A custom surface on the API is the third shape, only when none of the simpler external options fit.

Pick the one to three handoffs that matter. A workspace with forty views nobody owns is worse than one with three.

Don’t do this

Integration before intake

Running integration and AI before the taxonomy and the request form is the most common way a Planning rollout stalls.

Views nobody asked for

Build the views, forms, and automations someone needs. Scaffold the structure, then hand off the steps that matter.

A Planning view as a portal

Outsiders need a public form, an External user license, a report, or a custom surface — not a workspace share.

Credentials in the browser

A custom surface calls the Planning API from a server-side proxy. OAuth credentials never reach the page.

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