Join the LadVen OS testing programRequest a demo
Skip to main content

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.

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, or a manual run.
  • 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.
  • 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.

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.

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 clear 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. The check's message should explain exactly what needs to be done.

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.

Before using a template, test it on a test deal: whether the data is substituted correctly and whether any unfilled placeholders remain.

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.

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 with a clear message;
  • the process is stopped or completed.
note

Some automation and business-process screens are currently not localized for every interface language, and a few service screens show technical information. This is a known product limitation. It does not affect the meaning of this article, but localized screenshots of these screens are not published until it is fixed.

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."
  • Test email templates on a test deal before using them at scale.
  • 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 customer receives an email with empty placeholders or someone else's data.

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 email template substitutes data correctly on a test deal;
  • the business process passed a test run and follows the expected path.