CRM Automations

CRM automations connect a supported event, optional AND/OR conditions, and one or more supported actions. Conditions can use the same system and custom fields as CRM views. Automations never run workspace-provided code.

Use a dedicated workspace member as the run-as identity and grant only the permissions its actions need. Disabling or editing an automation affects new runs; an existing run keeps the action version it started with.

Each incoming event can carry an idempotency key. Repeating that key does not create duplicate runs. The Runs view exposes action attempts, approval waits, errors, and append-only logs. Failed resumable work keeps its completed action states, so a retry does not repeat successful actions.

Date triggers support a one-time date or a recurring interval. Entity-date triggers watch one configured CRM date field and can run before or after it. Due work is queued for its exact time, and far-future dates are carried forward until they enter the delivery window. Event filters can also restrict an automation to trigger keys, connector providers, or one Record Type.

Actions that call connectors, virtual coworkers, portal publishing, or Playbooks enter a durable invocation queue. The connected worker records its result there, so administrators can distinguish waiting, processing, completed, and failed work. Webhook actions select a managed connection; they do not accept an arbitrary destination URL.

Open Operations to inspect runs and their append-only logs, approve or reject waiting actions, and execute, retry, pause, resume, or cancel eligible runs. The Invocation outbox can be filtered by status and shows the exact configuration, attempt count, result, or failure retained for each external action.

Members with CRM management permission can use Submit event for controlled manual recovery and testing. Choose a registered trigger, optionally link a primary CRM subject and related entities, and provide JSON facts or payload. Correlation, causation, lineage, schedule, and idempotency fields should only be set when reproducing an existing event chain; reusing an idempotency key will not create duplicate runs.

Loop lineage, a maximum chain depth, and per-run fan-out limits stop runaway workflows. If a run stops for one of those limits, inspect its log before changing the automation or retrying it.