Testing and operations

​

A practical release process

1. Create a draft or work on a separate inactive automation. Keep stable section IDs and step keys when updating an existing definition.
2. Validate configuration, referenced resources, input mappings, and credentials. Validation does not prove a remote API will accept a request.
3. Test one section with representative data: normal input, missing fields, empty results, duplicate events, external failure, and expired context.
4. Inspect the complete step report and the matched result. Section tests can execute the selected section even when its entry conditions do not match; they do not prove live routing by themselves.
5. Review the active trigger bindings and every destination. Editing an active definition affects subsequent requests.
6. Activate for a controlled real event only when real side effects are intended. Confirm external receipts and stored context, then observe live runs.

​

What test mode executes

​

Run states and step results

Persisted runs use QUEUED, RUNNING, SUCCEEDED, and FAILED. Step reports use succeeded, failed, and skipped, with input/output records and duration when available.

• onError: "stop": fail the section when the step fails, rather than executing later business steps.
• onError: "continue": record the error and continue. This is useful for optional diagnostics, but a successful run may then contain a failed callback.
• A false step condition records a skip.
• Return ends the section successfully, including an intentional no-op.

Always inspect steps when checking business success. SUCCEEDED alone does not prove a message was delivered, a callback succeeded, or a record was eligible for sending. Audit payloads may be truncated; the stored preview is not necessarily the full original request or output.

​

Idempotency, retries, and uncertainty

Use a stable X-Idempotency-Key for repeated delivery of the same webhook operation. Direct webhooks can otherwise derive their deduplication identity from the body. Channel statuses deduplicate by automation, provider message ID, and status. Deduplication is bounded in time and is not a permanent business rule. The worker retries errors classified as retryable and can checkpoint completed steps before resuming. Rate-limited sends can be deferred. Not every HTTP or connector failure is automatically retryable. Integrations receive stable per-step idempotency headers where supported; the receiving service must honor them. Exactly-once external effects are not guaranteed. A worker can fail after a remote service accepted a request but before local persistence completed. A retry or a manual replay must not assume that no effect occurred. Confirm receipts, message IDs, or the remote system’s idempotency record before repeating an uncertain operation. There is no automatic rollback across multiple services. Use a business idempotency key that reflects the intended operation. For example, a recipient and a campaign ID may be insufficient when the same campaign has multiple distinct sends. Document the delivery identifier explicitly, and test repeated delivery separately from a new authorized operation.

​

Execution limits

These are current validation/runtime limits, not throughput guarantees: Do not submit a large customer list as one loop and expect unlimited fan-out. Split work into independently identifiable events and respect admission and provider limits. A schedule or automation is not a replacement for capacity planning.

​

Diagnose a run

The Portal provides run and step inspection. MCP exposes the same information through list_automation_runs and get_automation_run. Platform monitoring can expose queue depth, terminal outcomes, step failures, retries, execution duration, worker health, and scaling. Queue job completion and business run success are different signals.

​

Pause, revert, and retain evidence

Pause to stop new admissions, not to cancel accepted executions. To revert definition changes, restore a reviewed prior definition and validate it. To restore a trigger’s agent destination, remove the relevant automation binding and separately inspect already queued work. Avoid enabling both paths for the same event. History retention is deployment-configurable (default 14 days). Export the evidence you need before retention removes it. Delete removes the automation and its history; it is not a pause operation. Keep credentials and token-bearing webhook URLs out of exported examples and source control.