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

Operation guards

An operation guard is a rule that prevents an operation from running until a condition is met. For example: you cannot move a deal to the "Contract" stage until the amount is filled; you cannot close a task until the checklist is completed. The guard fires at the moment of the operation, shows a clear message, and points out exactly what needs to be fixed.

Operation guards are the "circuit breaker" of a process: they turn a procedure from a verbal agreement into a rule that the portal applies the same way to everyone.

They are configured at /automation/operation-guards, and also from CRM automation in the guards section.

When operation guards are needed​

It is worth setting up a guard wherever employees regularly "skip past" a mandatory step:

  • close a task with an unfinished checklist;
  • move a deal further along the pipeline without the required fields filled;
  • win a deal without an amount or a client;
  • run an action without specifying a mandatory reason.

If a step is desirable but not mandatory, it is better to use a hint or a task rule rather than a hard block.

What a guard consists of​

A guard is built from three parts:

  1. Operation — what exactly we are protecting (a stage/status transition or an action).
  2. Condition — what must be met for the operation to go through.
  3. Message — what the user sees if the condition is not met.

First state the rule in words: "you cannot do X until Y is met", and only then configure the guard.

Which operations can be protected​

A guard is attached to one of two types of operations:

  • transition — changing a deal stage or a task status;
  • action — a button or operation on an entity (task, deal, project).

This lets you close the riskiest points: "you cannot win the deal", "you cannot close the task", "you cannot move to the stage".

Scope​

A guard has a scope: the whole company or a specific pipeline. The scope determines where the rule applies. A targeted guard on one pipeline does not interfere with the work of other directions, while a company-level guard sets a common mandatory standard.

Guard conditions​

A condition compares a field or the state of an entity. Available conditions include, in particular:

  • field filled / not filled;
  • checklist completed;
  • field value is in a list / is not in a list;
  • numeric comparison (for example, amount greater than zero).

Several conditions can be combined so that the operation only goes through when all the required requirements are met.

Blocking message and hint​

If the condition is not met, the operation does not go through, and the user sees a blocking message. A good message explains not "you can't", but what to do: "Fill in the deal amount before moving to the 'Contract' stage". The guard can highlight the relevant field or open the relevant section so the user immediately understands where to go to fix it.

The message is the interface of the procedure. A vague "Operation forbidden" is irritating; a clear hint saves time.

Enabling and ownership​

A guard takes effect only after it is enabled. Each guard should have an owner responsible for the procedure: guards directly get in the way of people's work, so a forgotten or overly strict guard blocks the process. The list shows who changed the rule and when.

States and limitations​

  • guard disabled — the operation goes through without restriction;
  • condition met — the operation goes through as usual;
  • condition not met — the operation is blocked, the message is shown;
  • guard too broad — it blocks operations that it should not;
  • no rights to manage in the scope — the guard is read-only.

Good practices​

  • Protect only truly mandatory steps, not everything in sight.
  • Phrase the message as an instruction: what to fill in or complete.
  • Use field or section highlighting to guide the user.
  • Limit the guard scope to the relevant pipeline if the rule is not company-wide.
  • Assign an owner and review guards when the process changes.

Common mistakes​

Blocking a non-mandatory step. A hard guard where a hint would suffice slows down work and creates workarounds.

A vague message. "Operation forbidden" does not explain what to do and provokes support requests.

Too broad a scope. A company-wide guard breaks the work of directions it was not intended for.

A guard without an owner. When the rule gets in the way, it is unclear whom to approach for a change.

How to verify the result​

  • when the condition is not met, the operation is actually blocked;
  • the message clearly explains what needs to be fixed;
  • the highlight leads to the relevant field or section;
  • when the condition is met, the operation goes through without obstacles;
  • the guard does not affect operations outside its scope.