| name | appbuilder-workfront |
| description | Use when orienting, onboarding, or planning before a concrete task — the entry point for building a customized Workfront UI on Adobe App Builder. Reach for this whenever the user is: brand new to Workfront UI extensions and asking where to start or what the process looks like; describing a Workfront customization idea and asking how to build it; asking for the end-to-end roadmap (set up → scaffold → build → test → deploy → publish); or asking how the React/Spectrum SPA, the serverless Runtime actions, and the Workfront extension points fit together. This umbrella routes each stage to its skill: workfront-ui-extension (front-end SPA + extension points), workfront-actions (Runtime actions + Workfront Public API v21), workfront-local-testing (previewing a build inside Workfront); machine setup and aio app init live in appbuilder-project-init. Skip it and go straight to the matching sub-skill when the user already has one specific task. |
| license | Apache-2.0 |
Workfront UI extensions on App Builder
A customized Workfront UI, built as an App Builder app. It has two halves:
- a front end — the screens the user sees. Built with React/Spectrum (Adobe's UI toolkit); in App Builder terms it's the SPA ("single-page app"). →
workfront-ui-extension
- a back end — small functions that run in Adobe's cloud (Runtime actions; "serverless" = you write the function, Adobe runs it, no server to manage). They hold the credentials and call the Workfront / Planning / Adobe APIs. →
workfront-actions
The front end plugs into Workfront at fixed spots called extension points: a Main Menu button, an item in an object's left panel, or a widget embedded inside a custom form.
End-to-end flow → which skill
| Step | What you do | Skill |
|---|
| 0–1. Set up + create project | Node 20, install @adobe/aio-cli, aio login, pick IMS org, stage vs prod, create the project (Developer Console or aio console project create) | appbuilder-project-init |
| 2. Scaffold | aio app init with template @adobe/workfront-ui-ext-tpl; pick extension points | appbuilder-project-init + this skill's references/commands.md |
| 3. Build front end | Extension points (Main Menu, secondaryNav, widgets), routing, shared context, actionWebInvoke | workfront-ui-extension |
| 4. Build back end | Action anatomy, config, auth, inputs; call Workfront (Public API v21) / Planning / services | workfront-actions |
| 5. Run + test in Workfront | aio app dev, then extensionOverride (local build) or Extension Manager / BYO (deployed app, no publish) | workfront-local-testing |
| 6. Deploy | aio app deploy | references/commands.md |
| 7. Publish (org-wide) | Submit for approval from the Production workspace; make sure Production has every API/service your actions need. Not required for BYO/override testing. | — (see below) |
Publishing makes the app available to everyone in the IMS org without an extensionOverride. Deploy from the Production workspace (aio app deploy), then submit for approval in the Developer Console / App Builder distribution UI (guide: https://developer.adobe.com/uix/docs/guides/publication/). To use a deployed app in one org without approval, register its URL in Workfront's Extension Manager (Bring Your Own extension) instead — see workfront-local-testing. After deploy, the app's direct link is the Experience Cloud shell URL …/workfront/custom-applications/<extensionId>/<menuRoute> (not the bare CDN) — build and hand it over per workfront-local-testing.
Hit a wall? A symptom → cause → fix table of the real gotchas (Node/aio errors, the Main Menu id trap, 401 Org Id undefined, BYO testing, and more) is in references/troubleshooting.md. The full aio command catalog is in references/commands.md.
Plain-language glossary
| Term | In plain words |
|---|
| SPA / front end | The app screens the user sees inside Workfront. |
| Runtime action / "serverless" | A small function in Adobe's cloud that does the real work (fetching/saving data) and keeps credentials off the user's browser. |
| Extension point | A spot where your app appears in Workfront: the Main Menu, an object's left panel, or a custom-form widget. |
| Shared context | Info Workfront hands the app automatically — who's signed in, which object they're on, the instance URL. |
actionWebInvoke | How the front end calls a back-end action. |
| IMS org | Your Adobe organization (identity / login). |
| Developer Console / workspace | Adobe's web admin where the project and its Production / Stage environments live. |
| Layout template | The Workfront admin setting that decides where an app actually shows up for users. |
Invariants for the whole family
- Auth comes from
sharedContext (imsToken, hostname) — Workfront hands the app the signed-in user and instance, so never build a custom login.
- The browser never calls Workfront/Adobe APIs directly — always through a Runtime action via
actionWebInvoke, so login tokens stay on the server. (The IMS org id is already in sharedContext at auth.imsOrgID — no WF call needed.)
- Actions are CommonJS (
exports.main; not ESM); secrets/inputs flow .env → action inputs → params, and are never read from process.env at runtime.
- Node 20. The default environment is prod (live); targeting stage (test) needs
AIO_CLI_ENV=stage plus a re-login.
- Workfront Public API is v21.0; custom
DE: fields need {field}_Mod=notblank on search/count.
