Errors, limits, and unavailable actions
Not every disabled button or error message means a failure. Often it is a deliberate limit: you lack the rights, a condition has not been met, the data has changed, or a guard check will not let you proceed. This page helps you understand exactly what happened and what to do, without wasting time and without bypassing limits in unsafe ways.
Quick diagnosis
Before treating it as an error, ask three questions:
- Do I have the rights to this object and this action?
- Did someone else change the data while I was working?
- Is the action blocked by a process condition (a required field, a reason, a stage)?
The answers to these questions usually explain 90% of "errors" in the CRM.
Access denied
- No access to the CRM module. The section is hidden or reports a denial - your role has no rights to the CRM. Contact the administrator.
- No access to a deal or client. The object is outside your scope of visibility. Request access to the pipeline or record you need.
- Insufficient management rights. Viewing is allowed, but editing or configuration is not. These are separate rights; they are granted by the owner or the administrator.
Do not work around an access limit by forwarding data outside the CRM: that way the work history for the client drifts apart, and control is lost.
Visible, but you are not a member
Sometimes an object is visible but the action is unavailable because you are not a member of the related work group. In that case, ask the owner to add you as a member - this is the right path, not a workaround. Some actions are available only to the owner; then they are performed by the owner, or ownership is transferred first.
Data hidden by access policy
Some fields, especially personal data and legal-entity details, may be shown as "Hidden by access policy." This is not empty data but an access limit: you can see the record, but you do not have access to these fields. If a field is genuinely needed for your work, request access to it rather than looking for it through a workaround.
Version conflict and stale data
- Another user changed the data. Refresh the card and apply your change again so you do not overwrite someone else's edit.
- The context is stale. If rights or visibility scope have changed since the page loaded, refresh it.
Stage or status block
Moving a deal to a stage or changing its status can be blocked by a guard check. This is not a failure: the process requires a condition to be met.
- Read the check message - it explains what is wrong.
- Meet the condition: fill in the required field, complete the necessary step, add data.
- Repeat the move.
A special case is closing a deal: the final stage may require an outcome (won or lost) and a close reason. Without them the move will not go through. State the real reason: it later reveals the true loss rate.
Partial result of a bulk action
A bulk action (for example, archiving several deals) may not apply to all the selected ones. The causes are rights, status, a guard check, or a change to the object by another user. What to do:
- Look at which deals the action applied to.
- Open separately the ones where it did not work.
- Fix the cause and repeat only for the remaining ones, not for the whole set blindly.
Incoming flow and integrations
- A form submission did not reach the CRM. The submissions list lets you resend - use it after checking the form's routing.
- An integration channel is in error. Check the configuration and the health of the connection; the message usually points to a configuration problem or an external system.
- An external-access invitation is invalid (expired, used, revoked). Issue a new invitation.
Automation behaved unexpectedly
If a rule did not fire, or fired differently than expected:
- check whether the rule is enabled and whether its scope and condition match the case;
- open the run history - it shows what the rule did and where it stopped;
- if automation is unavailable to configure, it may be limited by rights or temporarily stopped in the module settings.
Who should act
| Situation | Who helps |
|---|---|
| No access to the module, pipeline, or field | The administrator or the space owner |
| Not a member of the work group | The work group owner |
| Stage or status block | The performer meets the check condition |
| Submission did not arrive / channel in error | The process administrator or the integrations owner |
| An automation rule works incorrectly | The rule owner |
How to describe the problem so it gets solved quickly
If you cannot figure out a limit or error on your own, describe the problem so the administrator or process owner understands it without follow-up questions. State:
- where: on which screen and in which pipeline it happened;
- what you were doing: which action you were trying to perform;
- what you saw: the exact message text or which button is unavailable;
- for which object: the deal, client, or pipeline (without private data - a link or number is enough);
- whether it repeats: whether the problem remains after you refresh the page.
Do not forward the client's personal data or private links in your request - describe the situation in words. A precise description saves one or two rounds of back-and-forth and speeds up the fix: it immediately shows whether this is rights, a process condition, or a real failure.
Good practices
- First check rights, changes, and process conditions, then treat it as an error.
- Read the block message: it almost always explains what to fix.
- On a conflict, refresh the data rather than overwriting someone else's edit.
- Work through a partial result by cause, instead of repeating the bulk action blindly.
- Do not bypass access limits by forwarding data outside the CRM.
Common mistakes
Treating a rights limit as a failure. Time is spent "fixing" something that works as intended; you just need to request access.
Ignoring the guard check message. It already says what to fix.
Repeating a bulk action after a partial result. Some deals will fail again, and the cause will remain unresolved.
Bypassing access by forwarding data outside. This risks a leak and the loss of control over the client's history.
Creating a new record instead of updating on a conflict. A duplicate appears, and the data drifts apart.
How to check the result
- it is clear what exactly happened: rights, a conflict, or a process condition;
- the block message has been read and the condition met;
- the partial result has been worked through for the remaining objects;
- the submission that did not arrive has been resent, and the integration channel checked;
- access was requested through the proper channel, without workarounds.