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.
In CRM, a guard can protect either a commercial opportunity or a service request: the selected pipeline purpose determines the available operations. The deal, amount, and won examples below are commercial scenarios; for a service scenario use synthetic Delivery window — demo and do not insert real records or amounts.
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.
| Tool | Stops the operation? | When to use |
|---|---|---|
| Operation guard | Yes, blocks until the condition is met | The step is mandatory and cannot be skipped |
| Hint | No, only reminds | The step is desirable, but the business allows exceptions |
| Task rule | No, performs the action itself | You need to trigger something automatically on an event, not forbid it |
What a guard consists of
A guard is built from three parts:
- Operation — what exactly we are protecting (a stage/status transition or an action).
- Condition — what must be met for the operation to go through.
- 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 can protect a transition, related-entity action, creation, archiving, or field change:
- transition — changing a deal stage or a task status;
- action — a button or operation on an entity (task, deal, project).
- creation — creating a CRM entity;
- archiving — moving a CRM entity to the archive;
- field change — changing a selected field or value.
The CRM label follows the pipeline purpose: a commercial scenario may say deal, while a service scenario may say request. Amount and won examples are commercial only; use synthetic Delivery window — demo for service, with no real records or amounts.
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.
Related scenarios
Conceptual guidance, not a UI screenshot or state evidence.