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:

1. Do I have the rights to this object and this action?
2. Did someone else change the data while I was working?
3. 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.

Several conditions can be violated at once. The block message lists every unmet condition - each on its own line. This is deliberate: otherwise fixing them would take one round per cause.

• Read the message in full, not just the first line.
• Meet all the listed conditions: fill in the required fields, complete the necessary steps, add data.
• Repeat the move.

If the block persists after your fix, compare the new message with the old one: you may have cleared some causes while one remains, or a new condition from the next check has appeared.

The form points to where to fix it. When a condition concerns a specific field of the card, the card scrolls to that field and highlights it. The exception is the close reason: it is filled in the stage-change block, and the card does not scroll there - look for it yourself.

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 or clients) 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:

1. Look at which objects the action applied to.
2. Open separately the ones where it did not work.
3. Fix the cause and repeat only for the remaining ones, not for the whole set blindly.

For clients, the confirmation dialog shows the breakdown before anything runs: how many records will be processed, how many are already in the target state, and how many are unavailable. Read it before confirming - that is cheaper than untangling a partial result afterwards.

A separate case is what stays active. Archiving clients does not close their work groups and client projects; the portal warns about this directly in the confirmation dialog. Formally the action went through in full, but work on a "closed" client keeps running. Close such work groups and projects separately, or no one will notice the discrepancy.

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. Every connection in the Integrations hub has a state: active, warning, error, draft, archived, or disabled. A channel in error or with a warning means potentially lost submissions and messages. Run the connection check: it shows a clear cause (a configuration problem or an external-system problem), then fix it.
• A message to the client was not sent (messengers). Messenger channels have a resend queue: stuck messages can be sent again instead of being lost. Clear it regularly.
• A REST integration rejects calls. The external system can be denied because of a request limit, an IP outside the allowlist, or because the method is not in the permitted set. Check the limits, the IP allowlist, and the connection's set of permitted actions. The access key is shown once - if it is lost, reissue it by going through the wizard again.
• Not enough rights to configure integrations. Without the right to write communications, the Integrations hub opens read-only: you can see the connections, but the wizard, the check, and the toggles are unavailable. The configuration is done by the administrator.
• 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.

If a refusal code appears

The server may return a technical reasonCode, but the interface translates it into a clear message and does not expose the raw code to users. Treat the message meaning, action, and object as the diagnosis—not the internal code.

Message meaning	What to do	Who can help
Access denied or a person cannot be assigned	Check role, scope, and participant; do not move data outside CRM	Administrator, project or pipeline owner
Data changed by another user	Refresh, keep only the current change, and retry	Author of the current change if unclear
Invalid condition, field, or relation	Fix the indicated item and retry	Process owner
Validation service, request, or integration unavailable	Do not duplicate or blindly repeat a bulk action; wait and retry once	Integration owner or administrator

For support, provide the exact on-screen message, screen and action, object type, time, and retry result. Do not attach raw JSON, tokens, personal data, or private links: a refusal code alone does not explain the required fix.

Good practices

• First check rights, changes, and process conditions, then treat it as an error.
• Read the block message in full: it may list several causes at once.
• Before a bulk action, read the breakdown in the confirmation dialog, not just the summary afterwards.
• 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.

Fixing the block causes one at a time. The message lists them all at once; repeating the operation after each edit means extra rounds and the feeling that "the error will not go away".

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.

Related scenarios

• CRM: overview
• Deals and inquiries
• Pipelines and stages
• Clients, companies, and contacts
• Automation and business processes