"Please give me access" arrives as one sentence and gets fixed five different ways: one person is missing a CRM role, another lost the Responsible field, a third simply is not a participant in the task. While the portal is small, permissions get handed out by request. At fifty employees that turns into a job of its own, and the question "who can actually see this deal" stops having a short answer.

How do access permissions work in Bitrix24?

There is no single permission system on the portal — there are three, and they do not reduce to each other. CRM runs a role model: a role plus an access level, set separately for reading, editing, deleting, exporting and importing. Tasks know nothing about roles; visibility comes from participation — creator, responsible person, participant, observer, project member. Groups, Drive and the activity stream form a third model with their own privacy settings. So "give access to the deal and to its task" in Bitrix24 (Alaio) means two different settings in two different places, and that is the first reason access gets granted and still does not work.

How to configure CRM permissions?

The matrix lives in CRM settings, under access permissions. A role is assigned not only to a person but to a department or a group — assigning by department is the version that survives, because a new hire inherits rights the moment they appear in the company structure. The levels are the familiar ones: no access, own, own and department, own and subdepartments, all. They are set per entity, and for deals and leads per stage as well, so you can allow edits while a deal is in progress and freeze it once it is won.

Two rules that save pain later. Keep the number of roles small — three to five, tied to departments rather than one role per person, or the matrix becomes unreadable within a year. And treat the export column as a separate decision: an "all" level with export enabled is how customer bases walk out of a CRM.

Why can an employee not see a deal or a contact?

Nine times out of ten the role is innocent and the Responsible field is the culprit. The "own" level literally means "records where I am the responsible person", so changing the responsible person takes the record away from the previous owner instantly. Second most common: linked entities carry their own permissions, so someone sees the deal but not the company attached to it, and the card looks half empty although the data is there. Third: the "available to everyone" flag on a card, which opens that one record around the entire matrix.

Check in this order — which role the user has, which level applies to that specific entity, who the responsible person is, which department the user sits in, and whether they are an extranet user. The first step where the answer differs from what you expected is the cause.

Who can see a task, and how do you grant access?

Tasks have neither roles nor levels. A task is visible to its creator, the responsible person, participants, observers, members of the project it belongs to, and to a supervisor for their subordinates' tasks. That is the whole list. Granting rights on a task is therefore not a thing you can do: the only way in is to add the person as a participant, usually as an observer. The Manage observers block does it as a workflow step — adding a department head as an observer when a deal reaches approval, and removing them once approval is done.

Why does automation see a record when a person cannot?

Because they act as different identities. Native automation rules and workflow actions run on behalf of a user — the person who created the rule, or the responsible person — and hit exactly that user's limits: if the human cannot see the item, the action fails too. Applications installed from the Market work differently: they talk to the portal with the token an administrator granted at install time, so Roboteka activities read and write the record regardless of who started the workflow.

That removes a whole class of silent failures, and it shifts one duty onto you: since permissions will not stop anything, the "is this person allowed" check belongs inside the workflow as a condition, not in the access matrix. If the workflow did not run at all, permissions are usually the wrong suspect — the diagnostic order is in automation rule did not run, and the REST side of the same story, including INVALID_CREDENTIALS, is in the error code reference.

How to keep access current automatically?

CRM roles themselves cannot be automated: the REST API exposes no methods for editing the permission matrix, so it stays a manual screen. What can be automated is everything access actually depends on — the responsible person, the department, and who participates.

  • Get employee manager returns the direct supervisor from the department tree, so an approval step can address a role rather than a hardcoded name.
  • Get employee department returns the responsible person's department, which lets one template branch by unit instead of spawning a template per team.
  • Change responsible on related moves the responsible person onto linked deals, contacts and companies when a client changes hands, so the new owner does not inherit half a card.

What next

Start with an audit: list the roles actually in use and their deal levels — half of them usually turn out to be duplicates. Then close export where it is not needed, and move role assignment from individuals to departments. Finally, add a step that keeps the responsible person accurate, because that single field carries most of CRM visibility. The rest of the blocks live in the robot catalog, and the wider picture is in the workflow automation guide. If the block you need is missing, describe the task: Roboteka builds missing activities for free and ships them to the shared library.