Phases and Transitions

Phases are the building blocks of every workflow. Each phase represents a step in your process, and transitions connect phases to define the order things happen. This guide covers every phase type Nembl supports, how to configure task templates, and how to wire phases together.

Phase Types

Nembl supports the following phase types, each designed for a specific purpose.

START

Every workflow begins with a Start phase. It is automatically added when you create a new workflow and cannot be deleted. You have exactly one per workflow, and it simply connects to the first real step.

PROCESS

A Process phase is where work happens — reviewing a request, completing tasks, calling an external system, running a data transformation. It's the most common phase type.

Configure in the property panel (right side of the editor):

• Name and Description
• Responsible parties via the Responsibility editor — users, agents, teams, or groups with RACI roles
• Task templates (see below) — pre-defined tasks that auto-create when the phase activates
• Automation type (optional) — if the work is system-driven instead of human-driven, pick one of the built-in automation types described under Automation Types
• Escalation deadline (optional) — if the phase isn't completed in time, the escalation cron notifies backup / accountable parties

APPROVAL

An Approval phase requires one or more assigned Approvers to click Approve or Reject. The worker view shows dedicated buttons; the phase advances along the approved or rejected transition based on the decision.

Configure:

• Name and Description
• Responsible parties — assign Approver engagement on this phase (Responsibility model)
• Require comments on reject (boolean) — forces a reason when rejecting
• Decision variable name — which instance variable records the decision (default: approval_decision)
• Comments variable name — which instance variable holds the reject reason (default: approval_comments)

Use an APPROVAL phase rather than a generic PROCESS phase whenever the step is specifically a go/no-go gate — the dedicated UI and explicit reject path keep the intent visible to reviewers and auditors.

DECISION

A Decision phase is an XOR gateway — exactly one outgoing path fires based on conditions evaluated against instance variables. Useful for "if this, then that" routing.

See Decisions and Parallel Paths for condition syntax.

Approval vs Decision — which one?

Both phases choose between branches, but they're for different things:

Common pattern: APPROVAL → DECISION. Human approves the request, then a Decision routes the approved request based on category, amount, or other variables.

PARALLEL

A Parallel phase splits work into multiple paths that run at the same time. The phase has a fork (where paths split) and a join (where paths come back together). The join waits for all activated branches before advancing.

See Decisions and Parallel Paths.

DATA

A Data phase transforms instance variables without requiring human action. Seven sub-types are available:

• Filter — remove array elements by condition
• Sort — sort an array by one or more columns
• Aggregate — min / max / sum / average over an array
• Transform — map and convert fields with 10 built-in functions (uppercase, lowercase, trim, number, boolean, json_parse, json_stringify, split, join, default)
• Enrich — compute values from a mathjs expression
• Validate — evaluate rules with pass/fail output or hard-fail
• Transpose — pivot an array of objects into a key-value map

See the DATA Phase Reference for every sub-type's config, operators, and examples. The built-in Data Test Panel lets you paste sample JSON and run the transformation without starting an instance.

Data phases advance automatically.

SUBPROCESS

A Subprocess phase runs another workflow as a nested child. The parent phase waits for the child to complete (or be cancelled), then continues. Use this for reusable sub-processes like background checks, access provisioning, or approval chains that appear in multiple workflows.

Configure:

• Linked workflow — pick any published workflow in your company
• Variable mapping — which parent-instance variables are passed to the child as inputs
• Output mapping — which child-instance variables surface back to the parent

Subprocess instances show a visible parent/child relationship in the instance viewer, and cancelling the parent cascades to active children.

CANCEL

A Cancel node is a dedicated handler for workflow cancellations. Instead of immediately terminating, a cancel request routes the instance to the Cancel node where you can run cleanup tasks, notify stakeholders, or even resume the workflow if the cancellation was a mistake.

Visual: red circle with a Ban icon (no connection handles — it's a sink).

Adding one: drag Cancel from the phase palette onto the canvas. A workflow can have zero or one Cancel node.

Configure:

• Task templates — cleanup tasks that auto-create when cancellation starts (e.g. "Notify requester", "Release resources", "Document reason")
• Information banner — the property panel lists the variables available to tasks: cancellation_reason, cancelled_from_phase, completed_phases

Runtime:

• When a running instance is cancelled, Nembl checks for a Cancel node. If present, the instance routes to it and creates the template tasks. If absent, the instance terminates immediately with status CANCELLED.
• Completing all tasks on the Cancel node finalizes the cancellation.
• A Resume Workflow button appears on the instance viewer while on the Cancel node. Clicking it reverts the instance to the phase it was cancelled from, clears the cancellation variables, and cancels (as TODO → CANCELLED) any cleanup tasks that hadn't been completed.
• Subprocesses of a cancelled parent are cancelled alongside the parent at finalization.

END

Every workflow ends with one or more End phases. When a request reaches an End phase, the workflow moves to the Completed state and the requester is notified. You can have multiple End phases (success, rejection, etc.) to tag different outcomes.

Automation Types for PROCESS Phases

A PROCESS phase can run a built-in automation instead of (or alongside) human responsibilities. Pick from the automation-type dropdown in the property panel:

Webhook Callout

Sends an HTTP request to an external URL when the phase activates, waits for the response, and advances.

Configure:

• URL — destination. Supports {{variable}} interpolation from instance variables.
• Method — POST (default) or PUT
• Headers (optional) — custom headers; values also support {{variable}} interpolation
• Timeout (optional, milliseconds) — clamped to 1000–60000; default 30000
• Output variable — where the response body is stored on the instance (default: webhookResponse)
• Include variables (optional) — restrict which instance variables are sent in the request body; defaults to all

Request body sent to the URL:

{
  "instanceId": "…",
  "phaseId": "…",
  "phaseName": "…",
  "variables": {
    /* selected instance variables */
  }
}

Response handling: the full response body is stored in the output variable. If the response is a JSON object with a top-level variables object, those keys are also merged into the instance variables so subsequent phases can reference them directly.

Test button: the property panel includes a Test Webhook Callout button that fires the request with sample data so you can validate URL interpolation, headers, and response parsing before publishing.

Retries: not built-in at the handler level. For retry semantics use the phase's separate retry-config section.

Timer

Pauses the phase for a fixed duration or until a specific datetime, then advances.

Configure:

• Duration type — duration (relative) or datetime (absolute)
• Duration — if duration mode: value (number) + unit (minutes, hours, or days)
• Datetime — if datetime mode: ISO 8601 string (supports {{variable}} interpolation from instance variables)

When the phase activates, Nembl schedules a callback at the target time. When it fires, the callback advances the phase and sets _timerCompleted: true and _timerTargetTime on the instance variables.

Validation: past datetimes are rejected at save time; durations must be > 0.

Misfire behavior: the callback fires at the target time (sub-second accuracy) or not at all — there is no catch-up window for missed firings. Cleanup of completed timers is automatic.

Typical uses:

• SLA escalation timers — wait N hours, then advance to a reviewer
• Cool-down periods — delay 24 hours after approval before executing a sensitive action
• Scheduled reminders — relative delay from an upstream phase's completion
• Absolute scheduling — "advance at 9am local time on the trigger date" via a datetime variable

Cancelling the instance while paused on a Timer phase deletes the schedule so the callback won't fire. If the Cancel node resumes the workflow before the timer fires, a new schedule is created with the remaining duration (for datetime mode) or the full duration restarted (for duration mode).

Script

Computes a value from existing instance variables using a sandboxed mathjs expression. No JavaScript runs — only the mathjs expression language, which is deterministic and safe by default. Good for math, string manipulation, conditional values, and small lookups.

Configure:

• Script Expression — mathjs syntax (e.g. quantity * unitPrice, round(total * 0.08, 2))
• Output Variable — where the computed value is stored on the instance

Variables are referenced by name. The expression engine blocks file system, network, and arbitrary code execution.

API Call

Calls an authenticated REST API. Like Webhook Callout but adds support for connectors (stored credentials in a Nembl Vault) and richer auth flows.

Configure (Use Connector):

• Pick a pre-configured connector that holds the auth credentials. See Connectors.

Configure (Manual Config):

• URL / Method / Headers (JSON) / Body — provided inline
• Output Variable — where the response is merged

Data Transform

Applies a built-in data operation to a variable: filter, sort, sum, average, validate, transpose, or run a mathjs expression.

Configure:

• Sub-type — picks the operation (filter, sort, enrich, sum, average, min, max, validate, transpose)
• Source Array / Field — for aggregate and filter operations
• Expression — for the enrich sub-type (mathjs)
• Output Variable — where the result is stored

Task Templates

Task templates are pre-defined tasks that Nembl auto-creates when a phase activates. They're ideal for checklists and repeatable manual work.

Supported phase types: PROCESS, APPROVAL, CANCEL.

Template fields:

• Title (required)
• Description (optional)
• Sort order (auto-managed; drag to reorder)

Adding templates

Two UIs, same data:

1. Phase Quick-Edit dialog — double-click a phase on the canvas, or right-click → Edit Phase. The dialog shows Name, Description, and an inline task-templates editor (add / edit / delete / reorder). Great for fast edits without opening the full property panel.
2. Full property panel — open the phase's property panel and scroll to Task Templates. Same editor, plus access to all other phase settings.

Canvas display

Toggle Show tasks on node in the canvas toolbar to reveal task templates as child rows under each phase, showing titles and status icons (planned vs in-progress vs completed). Useful when reviewing a workflow's end-to-end checklist at a glance.

The toolbar toggle overrides per-node settings. Individual phases can also have a Show tasks boolean in their config to control the default for that node.

Runtime behavior

• When a phase activates, Nembl creates one Task per template on the linked Request, each tied to this phase (phaseId) and the Request's Inbox.
• Completing all tasks does not auto-advance PROCESS / APPROVAL phases (a human or agent with advance permission still controls when to move on). It does finalize a CANCEL phase's cancellation.
• Loop-back: if a workflow loops back to a phase that already has running instance tasks, Nembl skips re-creating templates for the same phase instance (no duplicates).

Working with Transitions

Transitions are arrows connecting phases — they define the path a request follows.

Creating a transition

There are two ways:

1. Drag a handle — hover over the source phase until connection handles appear on all four sides; click and drag from a handle to the target phase; release to create the transition. Arrows default to a clean orthogonal route; right-click to Add Bend Point if you need to steer around other nodes.
2. Snap-to-connector (zero-length edge) — place two phases directly adjacent so their edges touch (right-to-left horizontally or bottom-to-top vertically). Nembl auto-creates the transition and renders a small directional chevron at the shared connector. Great for compact sequential chains. See Builder Overview → Snap-to-Connector.

Adding labels

Labels describe when a path is taken — essential on DECISION branches and anywhere the outcome isn't obvious from context. Click a transition to edit its label.

Examples:

• "Approved" / "Rejected" leaving an APPROVAL phase
• "Under $500" / "$500 and above" leaving a budget-check DECISION

Conditions

Conditions on outgoing transitions from a PROCESS or DECISION phase evaluate instance variables at runtime. See Decisions and Parallel Paths.

Backward edges

Transitions that loop back to an earlier phase are drawn as orange dashed lines so the intent — retry, revision, rework — is visually obvious.

Removing a transition

Click the transition and press Delete, or use the context menu's Delete.

Organizing Your Canvas

As workflows grow, keeping the canvas readable matters:

• Arrange phases left to right to mirror the natural flow of the process. Use Auto Layout to tidy up after heavy editing.
• Space phases evenly so transitions are easy to follow.
• Group related phases visually (e.g. "all approval steps near the top").
• Use descriptive names — the canvas should read like a process map without needing the worker view.
• Enable the grid-snap button for consistent 15px alignment.

Next Steps

• Learn how to set up DECISION branches and PARALLEL paths — Decisions and Parallel Paths
• Understand how workflows run once published — Workflow Execution
• Configure who acts on each phase — Responsibilities