Portal Community
Portal / Nodes / Stop Workflow / Configuration

Configuration Reference

All Stop Workflow properties: status, message, and message_expression.

Properties

PropertyTypeRequiredDefaultDescription
status string enum Yes — The terminal status of the workflow execution. One of: success (completed as intended), cancelled (intentionally stopped, no error), failed (could not complete due to an unrecoverable condition).
message string No — A human-readable explanation of why the workflow is stopping. Recorded in execution history. Visible in the BizFirst monitoring dashboard and accessible via the Execution API. Good messages are specific and actionable: include IDs, field names, and conditions. Maximum 1,000 characters.
message_expression string (BizFirst expression) No — A BizFirst expression that evaluates to the stop message string at runtime. Allows messages to include dynamic workflow data. Example: {@ "Invoice " + var.invoiceNumber + " generated and emailed to " + var.customerEmail }. Overrides message when both are set.

Status Selection Guidance

StatusThe right choice when...Monitoring Impact
successThe workflow completed all its intended steps, OR an early exit is a valid and expected business outcome (e.g., "nothing to do").Counted in success metrics. Does not trigger alerts.
cancelledA business condition made further processing inappropriate or unnecessary — not an error, but not a full completion either. The workflow did not complete its full path intentionally.Counted separately. May appear in audit logs as a notable event.
failedAn error, constraint violation, or unrecoverable condition prevented the workflow from completing. This outcome requires human attention or remediation.Increments failure counters. Can trigger alerts and escalation in BizFirst monitoring.
Write Useful Messages

The stop message is your primary debugging and audit tool for terminated workflows. Always include: the primary entity ID (order number, customer ID), the specific reason for stopping, and any relevant values. For failed status, include the error or constraint that was violated. A message of "Validation failed" is much less useful than "Validation failed: field 'email' value 'not-an-email' does not match RFC 5321 format".

JSON Configuration Examples

// Explicit success with dynamic summary
{
  "node_type": "StopWorkflow",
  "name": "CompletionSuccess",
  "config": {
    "status": "success",
    "message_expression": "{@ 'Invoice ' + var.invoiceNumber + ' generated and emailed to ' + var.customerEmail + '.' }"
  }
}

// Cancelled — business condition
{
  "node_type": "StopWorkflow",
  "name": "AlreadySubscribed",
  "config": {
    "status": "cancelled",
    "message": "Customer already has an active subscription. No renewal action required."
  }
}

// Failed — validation failure
{
  "node_type": "StopWorkflow",
  "name": "ValidationFailed",
  "config": {
    "status": "failed",
    "message_expression": "{@ 'Required field email is missing or invalid. Received: ' + var.submittedEmail }"
  }
}

// Failed — max retries
{
  "node_type": "StopWorkflow",
  "name": "MaxRetriesExceeded",
  "config": {
    "status": "failed",
    "message_expression": "{@ 'API call failed after ' + var.retryCount + ' retries. Last HTTP status: ' + var.lastHttpStatus }"
  }
}