Workflows

A Workflow is a visual process that connects decisions, transformations, collections, external calls, and event systems. Nodes perform work; connections determine which step runs next; mappings determine which data each step receives.

Use a Workflow when a business outcome requires more than one decision or action. A single Decision Table should remain a table rather than being wrapped in a one-node workflow unless orchestration, mapping, or event behavior adds value.

Example: loan application workflow

The following process combines several HubItems:

Input
  ↓
Validate application (Ruleset)
  ↓
Application valid? (Condition)
  ├─ No  → Build validation response (Assign) → Output
  └─ Yes
       ↓
    Risk score (Scorecard)
       ↓
    Risk band (Decision Table)
       ↓
    Risk route (Condition)
       ├─ Low    → Create Salesforce record → Approved Output
       ├─ Medium → Publish review event      → Review Output
       └─ High   → Declined Output

This structure keeps validation, scoring, banding, and integrations independently testable and versioned.

Configure the workflow contract

In Settings, select input and output Data Models. The input model defines what an API call or trigger mapping must supply. The output model defines the response contract. Add a description that explains the business process, entry method, and expected terminal outcomes.

Example request:

{
  "applicationId": "APP-1042",
  "requestedAmount": 25000,
  "applicant": {
    "age": 34,
    "annualIncome": 78000,
    "existingDebt": 8500
  }
}

Example response:

{
  "applicationId": "APP-1042",
  "status": "Approved",
  "riskBand": "Low",
  "reference": "DH-78219"
}

Add and configure nodes

Open Workflow Elements and drag a node onto the canvas. Select it to open its configuration. Give every node a distinct, business-readable name. Calculate affordability produces much clearer traces than Rule 2.

The palette is controlled by your plan and permissions. Core nodes cover boundaries, rules, and conditions. Advanced capabilities include transformation, collections, reusable HTTP/Coding/Scorecard logic, Salesforce data, and event triggers/publishers.

Family	Nodes	Typical use
Boundary	Input, Output	Define request and response
Decisions	Rule, Condition, Scorecard	Evaluate policy and choose paths
Transformation	Assign, Coding, Local Variables	Shape data and hold working values
Collections	Foreach, Find, Filter	Process array entries
Integration	HTTP Client, Salesforce Data	Call external systems
Triggers	Salesforce Platform Event Trigger, Kafka Trigger	Start from an external event
Publishers	Salesforce Platform Event Publisher, Kafka Publisher	Send an event
Documentation	Sticky Note	Explain intent without affecting execution

Connect control flow

Drag from a source handle to a target handle. An ordinary connection means the target runs after the source. A Condition provides one outgoing path per configured group and a default path. A Foreach separates its per-item path from the continuation after iteration.

Every executable path should reach an intentional terminal result. Avoid orphan nodes, routes with no Output, and accidental cycles. Sticky Notes have no runtime behavior.

Map data between nodes

A connection controls sequence but does not automatically guarantee the target receives every needed field. Open the connection mapping and pair source paths with target paths.

For example:

Input.applicant.annualIncome → RiskScore.annualIncome
Input.applicant.existingDebt → RiskScore.existingDebt
RiskScore.FinalScore         → RiskBand.score
RiskBand.riskBand            → Output.riskBand
Input.applicationId          → Output.applicationId

Mappings are checked against node models. When a source model changes, revisit all affected connections. A common workflow failure is correct decision logic receiving an empty or incorrectly mapped field.

Choose dependency versions

Rule, Scorecard, HTTP Client, and Coding nodes refer to another HubItem and a version. The workflow is not automatically switched to the newest dependency version. This is intentional: a reviewed workflow should continue using the version it was tested with.

To upgrade a dependency:

1. Create and test the dependency version independently.
2. Select that version in the workflow node.
3. Review mappings for contract changes.
4. Run workflow tests with Debug enabled.
5. Create a workflow version and deploy both through the dependency-expanded request.

Trigger-based workflows

An Input node supports request-driven execution. A Salesforce or Kafka Trigger starts the deployed workflow when a subscribed event arrives. Configure the connector, topic/event, payload model, and mapping into the workflow's business fields.

Trigger delivery is asynchronous. Use workflow health to see subscription state and delivery counters, Integration Activity to inspect the adapter record, and Execution History to inspect the resulting workflow run.

Publisher behavior

A publisher sends an event during workflow execution. Model its payload explicitly and map only fields that consumers need. Delivery can continue outside the immediate business step, so monitor pending, retrying, failed, and dead-letter records rather than assuming a successful workflow node guarantees downstream processing.

Test a workflow

Start with one representative payload and Debug enabled. Inspect the trace node by node:

1. Did the correct branch run?
2. Did each node receive the expected mapped input?
3. Did it return the expected output?
4. Did assignments and variables change the intended paths?
5. Did the final Output satisfy the workflow model?

Then create saved tests for every branch, failure path, empty collection, and integration outcome. Node mocks isolate external dependencies and nested HubItems; keep at least one separate integration test for real connector behavior.

Deployment and runtime configuration

Deployments include selected workflows and referenced dependencies. Runtime configuration remains environment-specific:

• Global Variable values;
• connector credentials and endpoints;
• deployed dependency versions;
• trigger subscriptions;
• API keys and permissions.

A workflow can pass in Development and fail in Test if a connector or variable has not been configured there. Review the target environment as part of release approval.

Common design mistakes

Mistake	Better approach
One giant Coding node contains the whole process	Split business decisions into named, testable HubItems
Connections exist but mappings are incomplete	Review every target's required input paths
Condition has no default	Add an explicit route for unmatched data
Dependency silently expected to use latest	Select and test a specific version
External service called in every unit test	Use node mocks for isolation and separate integration tests
Environment credentials embedded in payloads	Use connectors and environment configuration
Node names are generic	Use names that appear meaningfully in debug traces

Release checklist

• All paths reach the intended terminal behavior.
• Required input mappings are complete and type-compatible.
• Branch, collection, and failure tests pass.
• External nodes have timeout/failure behavior understood by operators.
• Referenced versions are the ones reviewed.
• Target-environment variables and connectors are tested.
• Deployment preview includes all expected dependencies.
• Post-deployment smoke test and monitoring responsibilities are assigned.