Automation

The rules layer that reacts to record changes, routes work, enforces data quality and gates high-stakes actions. All of it is condition-driven and configured rather than coded.

What you can do

Workflow rules

• Trigger automation on create, update or create-or-update for one object — account, contact, deal, case or lead.
• Match records with entry criteria — nested condition groups (AND / OR / NOT) evaluated by the shared rules engine, including on custom fields.
• Run actions when a rule matches: set a field, change status, set priority, assign an owner, apply a lead score, create a task/activity, or send a notification.
• Workflow runs are non-blocking and fail-open — a rule never breaks the request that triggered it, and field-mutating actions do not re-fire workflows.

Those three triggers are the whole set. There is no delete trigger, and no scheduled trigger: the API still stores a cronExpression field left over from an earlier design, but nothing reads it, so setting one will not make a rule run on a timer.

Assignment rules

Automatically pick an owner for a new lead or case when none was set — see Choosing an assignee.

Validation rules

Enforce record-level data quality: a rule whose condition is met blocks the save and shows your error message — see When validation rules fire.

Duplicate rules

Detect likely duplicate leads, contacts and accounts as they are created, using matching criteria you define. There is also an explicit check you can call before saving, which is what the leads screen uses to warn you up front.

Approval processes

Route a record to named approvers before it can go further, and work the requests waiting on you — see How approvals run.

Building conditions

Workflow, assignment and validation rules are all authored with the same condition builder, so criteria look and behave identically wherever you meet them.

• Every group has three buttons — ALL, ANY and NOT — which read back as “Match all / any / none of the following”. Those are the AND, OR and NOT operators.
• Add Condition adds a row of field · operator · value. The operators on offer follow the field’s data type, so text fields get the text comparisons and numbers and dates get ranges.
• Add Group nests a group inside the current one, for criteria like “industry is Retail and (amount over 50,000 or rating is Hot)”. Two levels of nesting below the top group are allowed; the button stops appearing after that.
• Conditions can be dragged to reorder within their group.
• The field picker lists the chosen object’s standard fields followed by its active custom fields. Custom fields are matched on their field name and resolve identically in all three engines.
• View / Edit JSON swaps the builder for a raw JSON editor over the whole criteria block, and back again.

Leaving a workflow or assignment rule’s conditions empty means “always match” — the rule fires on every qualifying create or update. A validation rule’s conditions cannot be left empty: the editor refuses to save one, because an empty condition matches every record and would block every save on that object.

Approval processes use a different criteria format

The builder is not wired into approval processes. Their entry criteria is raw JSON in an older shape — a single { "field": …, "operator": …, "value": … } test, or { "all": [ … ] } / { "any": [ … ] } — matched against the record’s database column names rather than the field names used elsewhere, so a quote process gates on discount_percent or grand_total. A condition the evaluator does not recognise counts as a match, so a malformed criteria block makes its process apply to every record of that object.

What each engine runs on

Each engine runs on a fixed set of objects.

Engine	Objects it runs on
Workflow rules	Account, Contact, Deal, Case, Lead
Assignment rules	Lead, Case
Duplicate rules	Lead, Account, Contact
Validation rules	Account, Contact, Lead, Deal, Case, Campaign, Activity, Quote, and custom objects
Approval processes	Quote, Deal, Lead, Account, Contact, Case

Two editors offer a longer list than their engine covers. The workflow editor also lists Products and custom objects, and saving one is rejected with "objectType" must be one of [ACCOUNT, CONTACT, DEAL, CASE, LEAD]. The validation-rule editor also lists Products, and a rule saved there is stored and shown as active but never blocks a save, because nothing runs validation rules on a product write — custom objects do run them.

Choosing an assignee

An assignment rule runs when a lead or case is created without an owner; if the caller already set one, no rule runs. Rules are tried in sort order, and the first rule whose conditions match decides the owner — either the user it names, or the next user from its round-robin pool.

The other targets do not assign anyone yet, and they behave differently when they do not. Role and territory targets are skipped, so the run moves on and a later matching rule can still decide the owner. A queue target ends the run without setting one. Either way, if no rule resolves a user the record keeps its default owner, whoever created it. The run is fail-open too: if rule evaluation errors, the record keeps that default owner rather than the create failing.

Round-robin position is held in the API process’s memory rather than in the database. It restarts at the top of the pool whenever the API restarts, and each running instance keeps its own position — rotation spreads work across the pool, but it is not an exact, durable turn-by-turn queue.

When validation rules fire

• Rules run on create and on update, before the record is written.
• A rule fires when its condition evaluates to true. The save is rejected and your error message is what the user sees; the optional error field attaches that message to a named field.
• If several rules fire on one save, the first rule’s message is shown and every violation is returned alongside it.
• Rules are cached briefly, so adding, editing or deactivating one takes effect within about 30 seconds.
• Enforcement is fail-open: if the rules cannot be read, the save proceeds rather than a metadata outage blocking all writes.

How approvals run

An approval process belongs to one object and holds an ordered list of steps. Each step names its approver — a specific user, a role (the first active user holding it), the submitter’s manager, or the record owner — along with a timeout in hours, 7 days by default.

Processes are created and edited through the API only — there is no approval-process admin screen in the web app yet.

This is CRM’s approval engine, not CPQ’s

The quotes, processes and requests described here are CRM’s own. If you also run CPQ, that product has a separate quoting and approval engine — different quote statuses, different rules about who may decide, and different numbering defaults. The two do not share configuration, so set each one up on its own terms.

Submitting and deciding

• In the web app, quotes are the only object with approval buttons. Everything else is submitted through the API.
• On submit, the object’s active processes are checked in turn and the first whose entry criteria match is used. If none match and no approver was named, approval is treated as not required and nothing is created. If an approver is named but the object has no process at all, a single-step process is created for it automatically.
• Each approver gets a high-priority task, and that is the only signal: submitting raises no notification in the bell, and the accompanying email does not send in this release — see Email.
• Approving a multi-step request advances it to the next step; the request stays pending until the final step is approved. A rejection ends it immediately.
• A step with several approvers runs as any one approver decides. A step configured to require all of them is rejected at decision time, so use the any-one mode.
• An integration can ask in advance whether a record would need approval before submitting it. There is no screen for this.

The pending inbox

The Approvals page — in the navigation, and behind the Pending Approvals button on the Quotes list — shows the requests waiting on you: the record type (linked through to the record), who submitted it, which step it is on out of how many, when it was submitted and its status. From each row you can approve, reject (a comment is required) or delegate to another user, and open a decision history of every step decided so far.

Timeouts, reminders and escalation

A background worker in the API reviews pending requests every minute.

Point	What the worker does
~24 hours before the step deadline	Sends the current approver a reminder notification
At the deadline	Escalates to the approver’s manager, notifies the manager and restarts the clock
After 3 escalations, or when there is no manager to escalate to	Marks the request expired and notifies the submitter

When an expired request belongs to a quote, the quote is also returned to Draft so it can be resubmitted.

The worker also tries to open a follow-up task at each of those points — for the manager on escalation, for the submitter on expiry — and that write fails today, which is also why the original approver is not told a request has left their queue. Expect the notification, not the task: see Background processing.

Quotes

Quote status is owned by the approval workflow rather than by editing.

Action	Requires	Result
Submit for approval	Quote is Draft or Rejected and has at least one line item	Quote moves to Needs review
Approve	You are the pending approver, and it is the final step	Quote moves to Approved; the owner gets a task to present it
Reject	You are the pending approver	Quote moves to Rejected; the owner gets a task to revise it
Recall	You submitted it	Quote returns to Draft

If no approval process matches the quote and no approver was named, submitting reports that approval isn’t required and leaves the quote where it is — it is not parked in Needs review.

Editing a quote cannot move it into Needs review, Approved, Rejected or Converted directly, and cannot set an approval outcome by hand. Those transitions belong to the actions above, and a plain edit attempting one is rejected with an explanatory error.

Admin-configurable

Workflow, assignment, validation and duplicate rules each have their own editor under Customize, and are created and maintained by administrators — creating, updating and deleting them is gated on the customization permission.

Approvals split into two things that are governed differently:

• The decision on a record. Approving or rejecting a quote from the quote itself is an action on a guarded resource, so it needs the approve right on quotes in the permission matrix. But whichever way a request is decided, only the approver named on the current step can decide it, and the pending-approvals inbox shows each user only the requests they are an approver on — that named-approver rule, rather than the matrix, is what actually decides who signs off.
• The process definition. Approval processes themselves sit outside the matrix — they are gated on sign-in alone, whatever a role says — so treat them as an area you control by convention rather than by permission, and give accounts on the tenant only to people you would trust with them.

Connects to

• Sales and Service & cases — the objects these rules act on.
• Customization — rules can read and write custom fields.
• Notifications — the notify action and approval events raise notifications.