CRM robots
A CRM robot is automation on the sales pipeline: "when an event happens to a deal and the conditions are met, run an action chain in order." Unlike a task rule, where there is a single action, a robot runs several actions in a row, can branch, and can work with timing. Robots remove a manager's manual routine: assign an owner, create a task, change a stage, send an email, create related entities.
Robots are configured in CRM automation at /crm/automation (the robots section).
When you need CRM robots
A robot is worth setting up wherever a deal event requires several related actions:
- when a deal is created, assign an owner in turn (round-robin) and create a first-contact task;
- when a deal enters the "Contract" stage, send an email from a template and create a task for the lawyer;
- when a deal's amount changes, route large and ordinary deals into different scenarios;
- when a deal is won, create a project and a payment.
If there is a single action and it is about a task, not a deal, that is a task rule. If the process is long, with waits and manual steps, that is a workflow.
Where to configure
Open /crm/automation and go to the robots. A robot has a scope: the whole company, a specific pipeline, or an individual stage. The scope determines which deals the robot even looks at. Creating and editing require CRM automation rights in the corresponding scope; without them, robots are read-only.
What a robot consists of
A robot is assembled from three parts:
- Trigger — the deal event that starts the robot.
- Conditions — for which deals the robot fires.
- Action chain — what the portal will do and in what order.
First describe the scenario in words: "when… and if… — then in order…", and only then assemble the robot.
Triggers
A robot's trigger is chosen from deal events:
- deal created;
- deal entered a stage;
- a deal field changed;
- manual launch;
- a document-exchange event.
The "entered a stage" trigger is the most common: it ties automation to the movement of a deal through the pipeline.
Conditions
Conditions determine which deals the robot fires on. They are gathered into groups with "and/or" logic, and each condition compares a deal field with an operator: equals, not equals, in list, greater/less than, contains/does not contain, filled/not filled. This lets you build a precise selection: "only deals from this pipeline with an amount above the threshold and a filled-in client."
The more precise the conditions, the fewer unnecessary firings and the clearer the run history.
Action chain
A robot runs actions in order, top to bottom. Available actions include, in particular:
- assign an owner;
- change the stage;
- create a task;
- send an email from a template (see message templates);
- fill in or increase a deal field;
- create a note or activity;
- create a related project, payment, or budget;
- create a related deal;
- notify participants;
- start a workflow.
Order matters: for example, first assign an owner, then create a task for them. Steps can be reordered.
Branching and timing
The chain can be split with a branching step: if a condition is met, follow one branch, otherwise follow another. This lets a single robot route different scenarios (for example, large and ordinary deals).
A step has timing: an action can be performed immediately, with a delay for a set time, or at a scheduled moment. This is how delayed reminders and multi-step scenarios are built without a separate process.
Owner assignment
The "assign an owner" action supports distribution modes: in turn (round-robin) or to the least loaded. This automates fair distribution of incoming deals among managers without manual assignment.
Check that only the right employees are included in the distribution: the robot will assign whoever is available in the rule, even if they are not currently on this direction.
Behavior on step error
A robot has a policy for when a chain step fails: stop or continue further. Choose deliberately: for critical chains (for example, "create a payment") it is safer to stop, so as not to run half the scenario blindly.
Preview and enabling
Before enabling, run the robot through a preview: the portal will show which deals it would apply to and what it would do, without changing data. A robot starts working only after it is enabled, and it must have an owner responsible for the scenario.
Do not enable a robot with an action chain on a live pipeline without a preview — broad conditions change deals in bulk, and rolling back is expensive.
States and limitations
- robot disabled — does not fire;
- preview found no matching deals — the conditions are too narrow or incorrect;
- step blocked by an operation guard — the chain was stopped or continued per the error policy;
- chain ran partially — check the run history step by step;
- no management rights in the scope — the robot is read-only.
Good practices
- Describe the scenario in words and the order of steps before assembling the robot.
- Narrow the conditions and scope to the needed slice of deals.
- Set a deliberate error policy for critical chains.
- Run a preview before enabling.
- Assign an owner and check the run history step by step.
- Build long processes with waits and manual steps as a workflow, not as a giant robot.
Common mistakes
Building a huge robot instead of a process. When a chain has dozens of steps and waits, it cannot be maintained — that is a workflow.
Enabling without a preview. A robot on "entered a stage" with broad conditions touches deals in bulk.
Ignoring the error policy. Part of the chain ran, part did not, and the deal is left in an inconsistent state.
Distributing to the wrong employees. Round-robin will assign anyone from the list, even if they are not on this direction.
How to verify the result
- the run history shows the robot firing on the right deal step by step;
- the deal received the expected owner, stage, task, email, or related entities;
- branching routed the deal down the correct branch;
- blocked or skipped steps are explainable (operation guard, error policy, rights).