mcpField
A
appbuilder-workfront

appbuilder-workfront

github.com/adobeDevelopment316196 installsUpdated today
Repository

About appbuilder-workfront

appbuilder-workfront is a skill for developing Workfront UI extensions with an App Builder front end and cloud Runtime actions. It covers project setup, extension points, testing, deployment, and publishing, with API calls routed through the back end.

Key features

  1. 01Build a React/Spectrum front end
  2. 02Handle back-end logic with Runtime actions
  3. 03Integrate Workfront extension points
  4. 04Test locally and deploy the app
  5. 05Manage authentication and API calls

Use cases

  1. 01Create a Workfront Main Menu extension
  2. 02Embed a UI in an object panel or custom form
  3. 03Test and deploy a Workfront UI extension

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/adobe/skills --skill appbuilder-workfront

After installing, type/appbuilder-workfrontin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

evals/
evals.json
references/
commands.md
troubleshooting.md
workfront-actions/assets/
action-boilerplate.js
workfront-actions/evals/
evals.json
workfront-actions/references/
integrations.md
workfront-local-testing/evals/
evals.json
workfront-ui-extension/assets/
ExtensionRegistration.example.js
workfront-ui-extension/evals/
evals.json

Details

From the project README

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

StepWhat you doSkill
0–1. Set up + create projectNode 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. Scaffoldaio app init with template @adobe/workfront-ui-ext-tpl; pick extension pointsappbuilder-project-init + this skill's references/commands.md
3. Build front endExtension points (Main Menu, secondaryNav, widgets), routing, shared context, actionWebInvokeworkfront-ui-extension
4. Build back endAction anatomy, config, auth, inputs; call Workfront (Public API v21) / Planning / servicesworkfront-actions
5. Run + test in Workfrontaio app dev, then extensionOverride (local build) or Extension Manager / BYO (deployed app, no publish)workfront-local-testing
6. Deployaio app deployreferences/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

TermIn plain words
SPA / front endThe 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 pointA spot where your app appears in Workfront: the Main Menu, an object's left panel, or a custom-form widget.
Shared contextInfo Workfront hands the app automatically — who's signed in, which object they're on, the instance URL.
actionWebInvokeHow the front end calls a back-end action.
IMS orgYour Adobe organization (identity / login).
Developer Console / workspaceAdobe's web admin where the project and its Production / Stage environments live.
Layout templateThe 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.

Comments

Markdown supported