Automation Actions and Step Types

W11 draft / unreleased: The semantics and limits below are taken from the coordinated builder and action contract. A listed action is usable only when its adapter and executor are present in the build being reviewed. This page does not claim provider configuration, production deployment, or live delivery.

Guided action path

Guided Editor exposes the complete 16-action catalog. The card labels map to the canonical graph action types as follows:

• Send SMS (send_sms)
• Send email (send_email)
• Make call (make_call)
• Leave voicemail (voicemail_drop)
• Delay (delay)
• Change status (update_status)
• Add tag (add_tag)
• Remove tag (remove_tag)
• Assign user (assign_user)
• Create task (create_task)
• Update field (update_field)
• Send webhook (webhook)
• Internal note (internal_note)
• Start another workflow (enroll_in_workflow)
• Stop another workflow (remove_from_workflow)
• Award XP (award_xp)

Use the add, edit, reorder, remove, and save controls in Actions. Each card's bounded configuration is kept in the same draft graph revision, so a saved draft can be reopened with its selected action and values intact. A graph condition can branch to different action paths; the draft still fails closed when the build being reviewed has no matching adapter or executor.

Canonical W11 graph actions

The graph contract preserves the V1 action names and adds bounded, typed payloads for:

The older split and recurring-schedule types are excluded. Contract presence does not make an action available in every editor; use the palette and config panel in the build being reviewed.

Configuration and validation

Wait and delay

Choose minutes, hours, days, or weeks in Guided Editor. The graph delay payload accepts seconds, minutes, hours, or days from zero through 365 days. Business-hours waits use the workflow timezone and selected start/end window. The published revision owns the wake time for an enrolled run.

Email and SMS

Email subjects are limited to 300 characters and HTML bodies to 50,000. SMS and email templates accept only the merge fields exposed for the selected subject. Recipient, opt-out, workflow-state, and delivery checks happen again at execution time. A refused or failed provider operation is recorded as a step outcome; it is not marked successful by the editor.

When no sender override is saved, the default email name comes from the organization display name and the persisted messaging configuration. The action payload cannot invent a sender identity. Once a message is admitted, retries reuse the frozen recipient, sender, Reply-To when applicable, rendered content, and action identity; the current organization, location, member, channel, and messaging policy are checked again before provider work. If that current check is no longer valid, the retry waits or fails closed according to the run outcome instead of sending under stale authority.

If a message draft includes a mention of its owner, that mention is rendered only after the message-owner record commits. While that item is still pending, the workflow waits on it rather than guessing an owner from the current authorization context.

Calls and voicemail

make_call can target the contact or assigned representative, optionally ring an agent first, and define a bounded agent target, whisper, timeout, recording, fallback (voicemail, next, or retry), and one through three attempts. For a lead subject, choosing Assigned rep resolves the lead's stored assigned representative when the call context is prepared. Timeouts are limited to 30 through 900 seconds. voicemail_drop accepts bounded text-to-speech content and an optional approved voice or audio URL. These definitions do not prove that a calling provider is connected.

When a voice action is dispatched, the callback URL carries the organization token and the immutable run, node, and attempt identity. The callback must pass the provider signature and the same connected account that owns the pending call. A progress or terminal callback first adopts the provider call ID under the pending reservation lock. Terminal status is then checked against that durable reservation before the graph resumes, so an unverified callback stays pending and a no-answer follows its configured retry, voicemail, or next step path. The durable internal call ID remains the callback's anchor through credential or provider-account rotation; a provider SID or a stale credential alone cannot move the callback to another run.

Status, tags, users, and tasks

Status updates name one supported entity: job, estimate, invoice, or lead. Tag actions use durable tag references; they do not trust a typed label. User assignment accepts an in-scope user reference. Tasks have a bounded title and notes, a due time no more than one year away, a call/email/meeting/deadline/ todo type, a priority, and an optional explicit assignee.

V1 allowed a task trigger with no event member to remain unassigned. V2 task rows require assigned_to, so a graph task with no explicit assignee resolves the frozen triggering staff actor as its fallback. Users can instead choose Assigned rep, a specific member, or Current user. If the frozen triggering actor cannot be resolved, the action fails with Triggering user unavailable; it never silently assigns the publishing member. A due offset of 0 hours means due now, and 0.5 hours means thirty minutes.

For a planned task on a job, Assigned rep resolves the owner of the originating estimate or lead. It remains separate from crew assignment and does not change the explicit triggering-actor check above.

When task assignment uses a round-robin choice, automatic and event-triggered runs advance the same rotation as manual runs. The selected member is frozen for that run, so retrying it reuses the same choice instead of advancing the rotation a second time.

Field updates

The allowlist is intentionally narrow. Lead fields are status, notes, at_risk, and assigned_to; estimate fields are status, notes, follow_up_date, and expires_at; job fields are status, notes, and crew_notes; invoice fields are status and notes; client fields are notes, tags, and customer_type.

The V1 field distinctions remain explicit in the graph contract:

• lead.at_risk is a boolean risk flag separate from computed customer

health; changing it does not rewrite the health result.

• job.crew_notes stores crew-facing operational notes separately from

job.notes and from crew assignment. Updating it never assigns or reassigns a crew.

• estimate.notes stores estimate notes. estimate.follow_up_date accepts an

ISO date/time or the relative-day value supported by the editor. It is data only and does not create a reminder, task, or automatic follow-up.

• client.customer_type accepts only household or company. It changes the

classification while retaining account/site structure and parent or primary links. Replaying the already stored value is safe and does not rebuild or reparent the customer hierarchy.

Webhooks and internal notes

Webhook URLs must use HTTPS. The contract allows POST, PUT, or PATCH, up to 50 headers, and an optional JSON body template. Credentials are not accepted in the workflow payload, and delivery still applies server-side destination and SSRF checks. internal_note is limited to 10,000 characters and remains an internal record.

After a webhook is saved, the editor displays [saved securely] for the URL, secret headers, and secret body values. Opaque secret_ref references remain attached to the saved action for an unchanged save, but they are never shown as raw values. A placeholder without its matching saved reference cannot be saved as a literal secret. The round trip therefore preserves an unchanged destination while keeping the secret out of the browser projection.

If a teammate's Automations manage role is restored after the draft was loaded, retrying Save draft or Activate rechecks the current role and can complete while preserving the protected reference. A viewer still receives a permission error instead of a partial protected-webhook save or publish.

Inbound events use a separate endpoint, /api/automations/webhooks/inbound. It requires an external API key scoped to the organization with webhooks:write, checks the key's location scope, and accepts at most 256 KiB of UTF-8 JSON. A stable Idempotency-Key (or the payload's stable event ID) is required; replaying it returns the existing admission and does not create a second occurrence or outbox event.

Inbound message and phone-call triggers also require an existing canonical customer record in the same organization and location. The runtime resolves the subject from that record before it can enroll a workflow; concrete message or call data cannot create a synthetic customer fallback. A missing record, organization mismatch, location mismatch, or unverified source is rejected so a workflow cannot run against a guessed customer.

Workflow enrollment

Enrollment actions reference a workflow by durable ID. The receiving workflow still evaluates its own active revision, permissions, subject scope, and duplicate-run rules. Removing a subject is likewise scoped to the referenced workflow and does not erase historical run evidence.

Current V2 scope: A workflow can contain up to thirty ordered actions. Actions run linearly; this release does not support branches.

Current V2 Actions

Wait

Choose a whole number of minutes, hours, days, or weeks. Appointment, scheduled job, and seasonal-rebook recipes can instead wait until an authoritative date with an offset. If Respect business hours is on, a due message outside the selected start/end window waits for that window in the chosen timezone. The frozen wake time belongs to the run's published revision; later edits do not move it.

Send Email

Add Send email, then edit the subject and body. Only the safe merge fields shown in the editor are accepted. Immediately before delivery, the run checks the current subject, recipient, preferences, and workflow state. A refused or failed provider action is retained as a step outcome rather than called successful.

Send SMS

Add Send text message and edit the message. Current V2 limits editor copy to 480 characters. SMS permission, opt-out, recipient, and provider safeguards still apply at delivery time.

Add Tag and Remove Tag

Choose an existing customer tag. The action uses the tag's durable ID rather than trusting a typed label. Add skips an existing assignment; remove is safe when the tag is not present.

Notify the Team

Write a title and body and choose the active team members who should receive the internal notification. With no recipients selected, the safe default is the active owner/admin group.

Create Task

Create an internal task with a title, optional notes, priority, optional due delay, and optional explicit assignee. When no teammate is selected, the runtime uses the frozen triggering actor; it fails with Triggering user unavailable when that actor cannot be resolved. For a planned job task, choosing Assigned rep uses the owner of the originating estimate or lead.

Webhook

Add Webhook to send an approved workflow payload to an external HTTPS endpoint. The V1-compatible transport supports POST, PUT, and PATCH, custom headers, and a JSON Body template with the same merge fields shown in the builder. A POST without a body template sends the workflow's event payload; an explicit template is rendered once when the run admits the action so later workflow edits do not change a queued delivery.

Webhook delivery is asynchronous. Clean Estimate records one delivery identity and a separate attempt identity, retries responses that are safe to retry, and quarantines a request when the network acknowledgement is ambiguous. A claim that failed before an attempt started can be recovered automatically. The worker rechecks the run, exact published revision and node, the current subject location, active definition, actor, and publishing authority immediately before resolving the endpoint and again before each physical address attempt. Paused, canceled, moved, terminal, or unauthorized runs therefore fail closed without contacting the destination.

When no body template is configured, the request body contains the frozen V1 automation envelope: workflow_id, run_id, step_id, org_id, client_id, estimate_id, job_id, invoice_id, lead_id, and triggered_at. An explicit JSON body receives the same object under _automation at its root. Both forms are created from the accepted graph revision and are queued before network I/O; an exact run/node replay returns the existing delivery instead of sending a second request.

The graph step reservation and webhook delivery admission share one service transaction, including secret ownership checks and request snapshot insertion. If a protected value cannot be resolved or the delivery row cannot be inserted, the transaction rolls back so the run does not retain an orphaned running step.

If a worker crashes after recording a terminal delivery result but before the graph settlement is written, the same registered worker performs a bounded evidence-only reconciliation on its next wake. It selects only bound terminal deliveries whose exact graph step is still pending or running, then reuses the stored delivery and physical attempt identity. It never sends the HTTP request again; once the graph step is terminal, the row leaves the reconciliation scan.

Endpoint URLs, custom header values, and rendered bodies remain in the service-only delivery ledger. Workflow revisions, run history, and manager activity show the action and redacted delivery outcome without copying those values. Use only endpoints and credentials approved for the organization; Clean Estimate does not follow redirects and blocks private or metadata addresses.

At least one action is required. Preview and Test dry run render the configured actions with sample data only; neither contacts a provider nor creates a customer message, tag, notification, or task.

Broader Clean Estimate V1 Reference

Each step in a workflow performs one action. There are 17 step types currently available in the builders, organized into seven categories. This page explains what each one does and how to configure it.

Communication

Send SMS

Sends a text message to the customer. The message body supports merge fields for personalization.

Configuration:

• Template -- the message text with merge fields like [customer.first_name]
• From Number -- defaults to your organization's active telecom number, or pick a specific one

The system checks SMS opt-out status before every send. If the customer has texted STOP, the step is skipped automatically.

A character counter and segment calculator show whether your message fits in one SMS segment (160 characters) or will be split into multiple.

Send Email

Sends an email to the customer.

Configuration:

• Subject -- email subject line with merge field support
• Body -- HTML email body with merge field support
• From Name -- defaults to your organization name
• Reply-To -- optional override

Make Call

Places an outbound call through your workspace telecom number.

Configuration:

• Agent Target -- who should receive the first leg when the step is configured to ring an assigned rep
• Whisper Message -- TTS message played to the rep before the customer is connected
• Call Timeout -- how long to ring before giving up
• Record Call -- toggle call recording on or off
• If No Answer -- retry, continue to the next step, or drop a voicemail

When the step runs, CE Pro uses the assigned rep phone as the live bridge target and the workspace telecom number as the caller ID, so Make Call stays a real two-party call instead of falling back to a one-way robot message. CE Pro logs the call into the unified Messages thread and keeps the call outcome on the workflow run.

Voicemail Drop

Places an outbound voicemail drop through the same telecom number.

Configuration:

• TTS Message -- the text-to-speech message to leave
• Audio URL -- optional hosted audio file for Twilio voicemail-drop flows
• Voice -- select from available TTS voices when using text-to-speech

The voicemail event is logged into the unified Messages thread as a voicemail entry instead of a generic call note.

Esendex Phase 1 voicemail drop uses text-to-speech scripting. Custom uploaded audio playback remains a Twilio-only path.

Timing

Delay

Pauses the workflow for a specified duration before moving to the next step.

Configuration:

• Duration -- a number
• Unit -- seconds, minutes, hours, or days

If business hours are enabled on the workflow, the delay respects them. A 2-hour delay that lands at 5 PM will resume at 10 AM the next business day (if business hours are 8 AM to 6 PM). The same run is resumed from the waiting step, even for long delays or business-hours holds.

Logic

Condition

Evaluates a TRUE/FALSE expression and branches the workflow. The TRUE path continues down one branch and the FALSE path down another.

If required condition data is unavailable, the step reports a visible, retryable unavailable outcome. It does not treat missing data as FALSE or silently continue down the FALSE branch.

Configuration:

• Conditions -- one or more field/operator/value rules
• Logic -- ALL conditions must be true (AND) or ANY can be true (OR)

Available condition fields include customer data, estimate totals, job status, tags, and behavioral signals like whether the contact replied or a call connected.

In the visual builder, condition nodes have two output handles. Connect the green TRUE handle to the steps that run when the condition passes, and the red FALSE handle to the alternative path.

CRM

Update Status

Changes the status of a lead, estimate, or job. Invoice status automation is a retained V1 reference and is not connected to the current V2 invoice workspace.

Configuration:

• Entity -- which record type to update
• New Status -- the target status value

Add Tag

Adds a tag to the customer record. Tags are useful for segmentation and as condition inputs in later steps or other workflows.

Configuration:

• Tag Name -- the tag to add (case-insensitive, skips duplicates)

Remove Tag

Removes a tag from the customer record.

Configuration:

• Tag Name -- the tag to remove (no error if it does not exist)

Assign User

Assigns a team member to the lead, estimate, or job.

Configuration:

• Assignment Mode -- choose a specific user, use Round Robin to rotate through eligible owners/managers/sales reps, or use Least Loaded to compare each teammate's active assigned estimates, jobs, and leads before picking the lightest queue

Create Task

Creates an internal follow-up item and assigns it to a team member.

Configuration:

• Title -- task title with merge field support
• Assign To -- the triggering user, assigned sales rep, or Round Robin

to rotate through active owners, managers, and sales reps

• Due In -- hours until the task is due

Automation tasks are logged into the unified Messages inbox as internal items with assignment and due-date metadata so reps can work the handoff from the same conversation thread.

Update Field

Updates a specific field on a record. Only fields on the allowed list can be updated for safety.

Configuration:

• Entity -- lead, estimate, job, or client. Invoice field updates are a

retained V1 automation reference and are not available for current V2 invoices.

• Field -- the field name
• Value -- the new value

Integrations

Webhook

Sends an HTTP request to an external URL. Use this to push data to Zapier, Make, your own API, or any third-party service.

Configuration:

• URL -- the endpoint (HTTPS only)
• Method -- POST, PUT, or PATCH
• Headers -- optional custom request headers; sensitive values are kept in

the service-only delivery ledger

• Body Template -- JSON body with merge field support

The webhook includes SSRF protection. Private IPs, localhost, and cloud metadata endpoints are blocked.

Internal Note

Adds a note to the customer's conversation thread. The note is visible to your team but not to the customer.

Configuration:

• Note -- the text to add, with merge field support

Internal notes created by automations are written directly into the unified Messages inbox thread for that customer or estimate.

Gamification

Award XP

award_xp accepts a target reference, a positive integer amount up to 1,000,000, and a reason up to 500 characters. A target can be the direct active member, assigned_rep, crew_lead, current_user, or the publishing member. current_user means the active member that owns the immutable published revision. assigned_rep follows the subject's V2 assignment (lead, estimate, invoice, payment, or a job's linked estimate). For a job, crew_lead comes only from the exact scheduled-date and truck row in truck_day_assignments; an absent or inactive lead fails closed.

The reusable XP service follows the V1 behavior: XP is disabled by default, the current active multiplier is applied once when enabled, and a replay uses the same result instead of writing a second award. The award identity is scoped by UUID organization, automation run, graph node, and target member. The target and publishing member must be active and organization/location scoped. A disabled award writes no XP ledger event, and totals are an aggregate of recorded event points rather than a mutable profile balance.

The customer portal review surface follows the V1 form: a signed customer portal session selects a service property, gives a 1–5 rating, and may add a plain-text comment. New reviews are stored unpublished until the office moderates them. Customer Reviews is a portal setting that defaults on for organizations that have never changed Portal settings.

Execution safety

The server checks that the publishing member and target are active members in the current automation location scope before writing the award. A disabled workspace records a skipped step without creating an XP event. Retries reuse the workflow run, node, and target identity, so a committed award is replayed instead of added twice. Invalid or out-of-scope targets fail safely and remain visible in the automation run history.

Graph nodes are identified by UUID. Payloads cannot supply an alternate node key, and bounded schemas reject unknown or oversized values before execution. The executor rechecks the workflow revision, organization, location, member scope, subject, and idempotency key. Preview and Test are provider-free and do not send messages, make calls, post webhooks, award XP, or write external records.