Adobe Workfront Fusion Developer Professional cheat sheet

A scenario is a saved workflow of modules; each execution is an execution, and each module run within it is an operation.

Operations are the billing unit: one bundle processed by one module equals one operation; filtering a bundle out before a module still consumes the prior module's operation.

Bundle = a single item of data passed between modules; a module can emit zero, one, or many bundles per execution.

Data flows sequentially from trigger to the last module; modules do not run in parallel within a scenario, but separate scenarios run independently.

Execution history is retained per the organization's plan window; historical executions are read-only and cannot be re-run in place.

Cycles in a scenario (a module feeding back to an earlier point) must be explicitly closed with a terminating condition or the execution can loop indefinitely.

The scenario blueprint is JSON; cloning a scenario copies modules, mappings, and settings but not execution history or webhook URLs unless the hook is reused.

Teams and folders organize scenarios; a scenario belongs to exactly one team, and access is granted at team and folder level.

Instant (webhook) scenarios and scheduled scenarios share the same module model; only the trigger differs.

A scenario requires exactly one trigger-capable module as its first module (webhook, schedule, or polling trigger); later modules run once per incoming bundle.

Place a router to branch into parallel paths; each path receives a copy of the bundle, and filters on each path decide whether a branch executes.

Aggregate after a router to collapse multiple bundles back into one; use a numeric aggregator for sums/counts and a text aggregator for joined strings.

Use an iterator to explode an array into separate bundles; use an array aggregator to rebuild an array from bundles.

Module order determines dependency: a later module can only reference output of modules positioned before it on the same path.

Set a module's 'Limit' to cap bundles processed; set scenario-level 'Sequential processing' when order matters or when hitting API rate limits.

A filter between two modules stops bundles that fail the condition; the fallback route on a router handles bundles that no filtered path accepted.

Use 'Ignore errors' on a module to let execution continue when that module fails; the bundle continues with empty output.

Naming modules descriptively and using notes documents intent; notes do not affect execution and are not billed as operations.

A connection stores credentials and scopes for an app; modules reference a connection, and one connection can serve many modules and scenarios.

OAuth connections refresh tokens automatically; if the refresh token is revoked, every module using that connection fails until reauthorized.

Universal connectors (HTTP, Webhooks) require no app-specific connection and are used for APIs without a dedicated app.

Search modules return multiple bundles (one per match); action modules typically return one bundle; trigger modules poll on a schedule.

Pagination in search modules is handled by the module's limit and by iterating with page/offset parameters where the app exposes them.

API rate limits are enforced per app and per connection; exceeding them returns HTTP 429 and the module errors unless retried or throttled.

Custom apps and custom API calls let you reach endpoints not covered by built-in modules; authentication is supplied by the selected connection.

A module's output structure is defined by its interface; changing the interface (e.g., new field) can break downstream mappings until remapped.

Mapping syntax references prior output with the module number and field path, e.g., {{1.data.id}}; the panel inserts these tokens for you.

if(condition; value_if_true; value_if_false) returns one of two values; arguments are separated by semicolons.

Use {{ }} only around expressions; literal text outside braces is passed through unchanged.

Common text functions: lower(), upper(), trim(), replace(), split(), substring(), length().

Common numeric functions: round(), floor(), ceil(), formatNumber(); parseNumber() converts formatted strings to numbers.

Array functions: map() extracts a field from an array, join() concatenates, merge() combines, and get()/first()/last() index elements.

Date functions: formatDate(date; format; timezone), parseDate(), addDays(), and now; ISO 8601 strings are the safest interchange format.

Type coercion is implicit in many functions; convert explicitly with toString(), toNumber(), or parseJSON() to avoid silent mismatches.

Null and empty values propagate: check with ifempty() or a conditional before using a field that may be absent.

Error handlers attach to a module: 'Break' stops the execution and marks it failed; 'Resume' supplies fallback output and continues; 'Ignore' continues with empty output; 'Rollback' undoes prior module effects where supported; 'Commit' finalizes.

A filter evaluates a condition per bundle; false bundles are dropped and do not reach the next module, but the producing module's operation is already counted.

Set a scenario's error handler (scenario-level) to catch unhandled module errors and route them to a notification or logging path.

Retry logic belongs in the error handler or in a repeated module; naive retries on non-idempotent actions can duplicate records.

Use 'Allow storing of incomplete executions' to preserve a failed execution's state for later inspection and manual resume.

Idempotency: check for an existing record before creating one when the trigger may deliver the same bundle twice.

Alerts and notifications on failed executions are configured per scenario or per team; silent failures are the most common reliability gap.

Break directives can be conditional, letting only certain error types halt execution while others resume.

A webhook trigger exposes a unique URL; the external app POSTs data and the scenario runs immediately with the payload as the first bundle.

Webhook payloads can be parsed as JSON, form data, or multipart; the payload structure defines the output fields available downstream.

Webhook responses can be configured (e.g., immediate 200 or a custom body) so the caller is not left waiting on the full scenario.

Scheduled triggers run at intervals (minutes, hours, days) or on a cron-like schedule; the minimum interval depends on the plan.

Polling triggers check the source app on the schedule and emit only new items since the last run, tracked by a stored watermark.

A webhook can be 'reused' or 'cloned'; reusing shares the URL, cloning issues a new URL so the old caller no longer reaches the clone.

Webhook data can be locked to a sample structure to stabilize mappings, or left dynamic to accept varying fields.

Manual 'Run once' executes the scenario immediately regardless of schedule; it is the standard way to test a trigger before enabling it.

Disabling a scenario stops scheduled and webhook execution; queued webhook calls during downtime are not replayed unless the sender retries.

Roles (e.g., Owner, Admin, Member, restricted roles) govern what a user can create and configure; team membership governs which scenarios they can see and edit.

Connections hold credentials; restrict who can create connections and audit which scenarios share a connection to limit blast radius.

Least privilege: request only the OAuth scopes a scenario needs; broad scopes grant write access the scenario may never use.

Scenario blueprints can contain hardcoded secrets if a developer pastes them into a module; prefer connections and environment-specific variables.

Version history and scenario versioning let you restore a prior blueprint; changes are attributed to the editing user.

Execution history and audit logs record who ran what and when; retention depends on the plan and is the primary forensic source.

Team-level and folder-level permissions control read vs. edit; moving a scenario between teams changes who can access it.

Data residency and processing region are set at the organization level; verify before sending regulated data through a scenario.

API keys and personal tokens should be rotated on a schedule and revoked immediately when a user leaves.

Run once with a known input and inspect each module's input and output bundles in the execution inspector to localize a failure.

The most common mapping error is referencing a field that is null or absent on the current bundle; guard with ifempty() or a filter.

Check the execution's operation count and bundle counts per module to find where volume or cost is concentrated.

Reduce operations by filtering as early as possible, limiting search results, and avoiding unnecessary aggregations.

Use 'Sequential processing' when parallel bundle handling causes race conditions or rate-limit errors.

Reproduce failures with a small, fixed sample; a scenario that works on one bundle may fail on a batch due to ordering or rate limits.

Inspect HTTP status and response body on failing API calls; 401/403 point to connection/scope, 404 to endpoint, 429 to rate limits, 5xx to the remote app.

Version history supports safe iteration: snapshot a working scenario before making structural changes so you can roll back.

Remove or disable unused modules and paths; dead branches still cost design complexity and can hide errors.