appbuilder-workfront

Files (13)

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

SKILL.md (first lines)

# 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`](references/troubleshooting.md). The full `aio` command catalog is in [`references/commands.md`](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.

From CatCorner22/Cursor_Skills, Apache-2.0.

More from CatCorner22/Cursor_Skills