Automation and business processes

Automation in CRM exists so that repeatable work is done the same way every time and without manual oversight: a new request immediately gets an owner, moving to a stage creates the right task, the customer gets an email from a template, and the required conditions are checked before closing. Good automation speeds up the process and makes it predictable; bad automation quietly changes data in ways that leave the team unsure of what happened.

Automation is managed in the CRM automation section (/crm/automation). This is process-admin work, not a manager's day-to-day action.

note

CRM automation is not limited to sales: the selected pipeline may serve commercial opportunities or service requests. In safe examples, use Delivery window — demo for a service request and Rebranding — demo for a commercial opportunity; do not use real records, identifiers, or amounts, and do not mutate data.

What automation is made of

CRM has several tools, and it is important not to confuse what they are for:

• Robot rules fire after an event (a deal is created, a stage changes, a field changes) and perform actions.
• Protective checks fire before an operation and stop it from completing until a condition is met.
• Business processes describe a multi-step scenario with conditions, waits, and assignments for people.
• Email templates store the text of external messages that robots and processes send.

Robot rules

A rule answers the question "what does the system do after an event."

• Event (trigger): a deal is created, a stage is entered, a field changes, a manual run, and also document-exchange events (see below).
• If the trigger list shows codes instead of readable names, do not enable the rule blindly. Confirm the event meaning with the process owner and wait for a clear, localized label.
• Conditions: the values under which the rule fires; conditions can be combined with "and"/"or."
• Actions: a chain of steps - assign an owner, move to a stage, change a field, create a task, send a notification, send an email to the customer, start a process, and others.
• If an action uses an amount or currency, verify the deal currency and expected result separately. Before enabling the rule, make sure it works with the monetary data and format your team expects to see.
• Branching: "if - else" inside a rule for different cases.
• Step scheduling: immediately, with a delay, or at an exact time.
• Error policy: continue or stop the chain when a step fails.

Every rule has a scope (the whole company, a pipeline, or a stage) and a priority. The broader the scope, the more carefully the rule must be checked before it is turned on. CRM access alone does not guarantee access to automation in the selected pipeline or stage. When a delegated scope denies access, the page shows the reason and does not load the rule list — this is not an empty list. Check the selected pipeline and stage and ask the policy owner for scoped access.

The run history shows what the rule actually did: the status of each run, the steps performed, and the delivery result of notifications. This is the main tool for investigation when automation behaves differently from what was expected.

Document-exchange triggers

Conceptual flow, not a UI screenshot or proof of portal data.

If document exchange is connected in the portal, rules can use the separate events of that flow:

• Counterparty linked (document exchange) - an incoming document has been matched to a customer in CRM;
• Document-exchange files imported - documents and signed copies have been loaded on the portal side;
• Document completed (document exchange) - the exchange for the document has reached its final state;
• Document-exchange import error - the load failed.

This lets you connect document exchange to people's work instead of watching it by hand: when a document completes, move the deal to the next stage or create a task for execution, and on an import error notify the owner right away. The import error especially deserves a rule: without a notification it is noticed only when the customer asks about a document they never received.

Protective checks

A protective check is a condition that must be met before an operation: for example, a required field is filled in, a checklist is complete, or a transition between stages is allowed. If the condition is not met, the operation is blocked, and the user sees a message and a hint about what to fix.

A protective check is not bureaucracy but protection of the result: it stops a deal from being closed without a reason or moved to a stage without the needed data.

What matters when configuring it:

• The block shows all the reasons at once. If an operation violates several checks, the user sees them as one list, each on its own line. Write the messages so that they read well next to one another: short, to the point, without vague wording like "not allowed".
• The message should name the fix, not the ban: "fill in the close reason", not "the transition is forbidden".
• The form scrolls to the offending field and highlights it when the check points at a specific field. Tie the check to a field where possible - that way the user finds the place to fix straight away.
• The known exception is the close reason: the highlight does not lead to it. If your check requires a close reason, say in the message where to fill it in.

Email templates

Email templates store recurring external messages to the customer. An active template becomes available for the "Email to customer" action in rules and processes. A template can pull in deal and customer data, so one email works for many situations.

Check substitution with a selected synthetic CRM request, not a live record: preview requires the selected synthetic CRM entity ID and its object context. Use Delivery window — demo for a service request or Rebranding — demo for a commercial opportunity; keep the check read-only:

• the "Variables" button opens the catalog of available substitutions, grouped by meaning; the chosen variable is inserted into the text;
• the "Check" button appears once the text contains variables, and shows a "Preview" block: what the message will turn into, plus any substitution errors and warnings.

Use the preview before turning the rule on. It catches exactly what makes emails go out looking wrong: a typo in a variable name, a substitution that does not exist in this context, and blank spots where the data is not filled in.

Business processes

A business process describes a multi-step scenario: action steps, conditions, waits for an event, assignments for people, loops, and parallel branches. Processes are built in a visual editor where steps are connected into a diagram.

Before launch, a process should be reviewed and run in test mode to make sure it follows the expected path. A running process has a state and a step history; a stuck process can be stopped. The assignments for people that a process generates are collected into a separate list and completed manually.

What matters for control

• Every rule, process, and template should have a meaning that is clear from its name and an owner.
• Before turning on an important rule, check the expected result and test it on safe data.
• Automation should not silently change the owner, due date, or status: if an action could raise a question, add a clear record or notification.
• Periodically review unused and overly broad rules.
• Investigate the run history when the result differs from expectations.

How to investigate a rule run

When a rule fires differently from what you expected, do not turn it off right away - read the run history first. It shows exactly what happened and saves hours of guesswork.

For each run, the history shows:

• the run status: success, partial, failed, skipped, or in progress;
• which steps ran and at which step the chain stopped;
• the delivery result of notifications and emails: who received them, who did not, and why;
• the origin: which event and which deal triggered the rule.

If run history shows only a service identifier without a readable deal title and outcome, do not treat the run as verified. Check the title, status, and result that participants can understand.

How to investigate:

1. Find the run you need by deal and time.
2. Check whether the chain ran to the end or stopped at a step.
3. If a step failed, read the reason - most often it is missing data, permissions, or an unreachable recipient.
4. Fix the cause (data, permissions, template, scope) and run the rule manually again if needed.
5. If a rule fires too often or in the wrong place, narrow its condition and scope rather than turning the whole automation off.

A partial result is not necessarily a breakdown: some actions may have been deliberately skipped because of conditions. What matters is telling an expected skip apart from a real error, and the run history is enough to do that.

States you may see

• no permission to view or change automation;
• the rule is turned off;
• the expected result shows that the run is not possible;
• a manual run is in progress;
• the history shows an error or a partial run result;
• a protective check blocked the operation and listed every unmet condition;
• the template preview showed a substitution error or warning;
• the process is stopped or completed.

note

Some automation and business-process screens are currently not localized for every interface language. This is a known product limitation: before demonstrating a workflow, check that action names and messages are clear to your team.

Good practices

• Give rules and processes clear names and an owner.
• Check the expected result and test before turning anything on.
• Do not let automation silently change the owner, due date, or status.
• Make protective-check messages clear: what to fix, not just "not allowed", and remember they may appear as a list alongside others.
• Check the substitution in a template with the preview before turning the rule on.
• Review rules regularly and turn off the unnecessary ones.

Common mistakes

Turning on a rule with a broad scope without checking it. It fires where it should not and creates unnecessary actions.

Silently changing the owner or due date with automation. The team loses track of who is responsible for what.

Making a protective check with an unclear message. The user sees a block but does not know what to fix.

Using an email template without checking the substitution. The preview in the template field shows the result and the errors in seconds - without it the customer receives an email with empty placeholders or someone else's data.

Writing a protective check message as if it were the only one. The user may see several messages at once; vague wording in a shared list gives no clue about what exactly to fix.

Launching a process without a test run. It follows an unexpected path, and dealing with the consequences costs more than checking in advance.

How to verify the result

• the rule has a clear name, scope, condition, actions, and owner;
• the run history confirms that the rule did what was expected;
• the protective check blocks only what it should and explains the fix;
• the template preview shows the finished text with no substitution errors or blank spots;
• the business process passed a test run and follows the expected path.

Related scenarios

Conceptual map, not a UI screenshot or proof of portal data.

• CRM: overview
• Pipelines and stages
• Deals and inquiries
• Tasks
• Workflows
• Automation