The responsible person is the central field of every entity in Bitrix24 (Alaio): reports and KPIs are calculated on it, the "own/others" permissions are tied to it, notifications and tasks land on it. That is why the question "how do I change the responsible person" comes up every day: a new lead has to go to an available rep, a departing employee's deals must be handed to a successor, a stuck approval needs to be raised to the supervisor. Let's go through every level — manual change, bulk change, automatic change — and three robots that cover the scenarios the stock tools can't reach. At the end, the reverse question: how to stop people from changing the responsible person when Bitrix24 has no separate permission for it.

Responsible person or assignee: who is who

In the CRM, a lead, deal, contact, and company each have a single responsible person — the "Responsible person" field in the card. Tasks have more roles: the creator, the assignee, participants, and observers. In tasks, the "responsible" one is precisely the assignee — the person who does the work and whose counters light up; the creator only accepts the result. If a process is supposed to "change the person responsible for a task", it is the assignee that changes. More about task roles and fields in the article on robots in tasks.

How to change the responsible person manually

In the card: the "Responsible person" field → pick an employee. In the list: tick the records you need → the "Change responsible person" group action — that is how dozens of records are handed over at once; the filter "Responsible person = Smith" plus "select all" covers hundreds too. Two pitfalls. First — permissions: anyone whose CRM role has the "Edit" permission on the record can change the responsible person; there is no separate permission for it — how to lock it anyway is covered below. Second — when a record is handed over, the previous owner can lose sight of it: "read own only" permissions cut off access the moment the change happens, which is why a customer-base handover is planned together with the role setup.

Automatic change: the stock robot and conditions

The workflow designer has a stock "Change responsible person" action — it sets a specific employee or a value from a field. Combined with "if — then" conditions you get routing: the deal amount is above a threshold — a senior rep becomes responsible; the source is "partner program" — records go to the partner manager. The weak spot of the stock action is that it only knows what is hardwired into its settings: a specific person or a field. Who is "available", who is "from the right department", who is "the current responsible person's supervisor" — the designer can't figure that out on its own, and this is where Roboteka robots come in.

Distributing leads and deals between reps

A classic: incoming leads should be distributed across the sales department evenly instead of piling up on one person on duty. The Random employee from list or department robot picks a random active employee of the specified department — or from an explicit list of IDs — and can exclude one person, for example the current responsible person. It returns the ID, name, email, and a "found" flag (Y/N); in the next step, a stock action writes the ID into the "Responsible person" field. Over time, random selection gives an even workload with no queue-tracking spreadsheets. If distribution has to depend on the author's department or on territory, the Get employee department robot first determines the department, then a condition branches the route. The full pipeline for handling incoming inquiries is in the article on leads.

A rep leaves: hand over everything related

The most painful scenario. A group action in the list will hand over the deals — but it won't touch the related records: the company keeps contacts with the old responsible person, the contacts keep their deals. The Change responsible on related robot solves exactly that: launched on a company, it reassigns all of its deals or all of its contacts; on a contact — its deals or companies; on a deal — its contacts or company. One run processes up to 500 related records, and the robot returns the number of updated ones and a success flag. The handover process comes together in a couple of steps: change the company's responsible person with the stock action → have the robot carry the new responsible person over to all deals and contacts of that company. The same technique works when a key account is handed to a new account manager — no departures involved.

Escalation: don't change, bring in the supervisor

Sometimes changing the responsible person is a mistake: the same rep must stay accountable for an overdue task, but their supervisor has to learn about the delay. The Get employee manager robot returns the direct supervisor based on the department structure — the process then assigns them a task or sends a notification. The responsible person doesn't change, but oversight appears. For escalation to work, the company structure must be filled in honestly — how to set it up is covered in the article on the company structure.

Can you stop reps from changing the responsible person?

With stock tools, only together with everything else. CRM roles have no separate "change responsible person" permission: anyone with the "Edit" permission on a record can change the "Responsible person" field. Taking "Edit" away means the rep can't edit the card at all — phone, amount, comments. What the role model actually offers:

  • Stage permissions. For leads, deals, and smart processes, permissions can be set per stage: on final stages and on "Approval" editing can be closed. The responsible person gets locked together with the other fields, which on those stages is usually what you want.
  • The "Own" level. It's a brake, not a ban: once a rep hands a deal to a colleague, they lose access to it immediately, and they can't take someone else's deal because they can't see it. How access levels depend on the responsible person is covered in the article on access permissions and robots.
  • Tasks. Here the permission exists: task roles have separate "Change assignee" and "Delegate task" rights. But task roles can only be configured on the Professional and Enterprise plans, and a supervisor can always delegate a task to their subordinates regardless of the settings.

The CRM role model is not available on every plan either. If "Edit" can't be taken away but control is needed, the lock is built with a process: the change isn't blocked, it's rolled back.

How to restore the previous responsible person automatically

You need a reference custom field — say, "Assigned owner" of the "Employee" type — and a business process that starts automatically on change. The setup:

  1. When a deal is created, the process writes the current responsible person into the reference field.
  2. Every time the deal changes, a check runs. The Get employee manager robot takes the ID from the reference field and finds the previous owner's supervisor.
  3. The Compound condition robot checks three things in one step: the responsible person is not equal to the reference field, "Modified by" is not that supervisor, and it is not the CRM administrator. AND logic, the result is Y or N.
  4. Y means an unapproved change: the stock "Change responsible person" action puts back the value from the reference field, and the supervisor gets a notification about who tried to hand the deal over.
  5. The responsible person differs from the reference field, but the condition returned N — the supervisor or the administrator made the change. The process writes the new responsible person into the reference field, and from now on they are the assigned owner.

The rollback itself triggers the on-change process again, but by then the responsible person matches the reference field, so the check ends without doing anything — there is no loop. One rule: processes that assign the responsible person legitimately — lead distribution, handing over a base when someone leaves — must also write the new owner into the reference field, or the check will roll them back too. How automation reacts to field changes is covered in the article on triggers, and what else to reassign when an employee leaves is in the offboarding checklist.

Frequently asked questions

Can reps be forbidden to change the responsible person? CRM roles have no separate permission for it: either take away "Edit" entirely or on specific stages, or roll the change back with a process, as described above. Does the task creator change? Not with stock tools — recreate the task with a process or change the assignee. Is the new responsible person notified? Yes, with a standard notification; an extra one with context can be sent from the process — how to set it up is in the article on notifications from business processes. What happens to active processes when the responsible person changes? They keep running; if the route depends on the responsible person, re-read the field at the moment of use, not at the start of the process.

In summary

A manual change covers one-off cases, group actions — occasional handovers, robots — the stream: even distribution of new inquiries, handover of the related base when someone leaves, escalation up the structure, and rollback of a change nobody approved. The Random employee, Change responsible on related, Get employee manager, Get employee department, and Compound condition robots are in the Roboteka catalog, free to install from Bitrix24 Market. If the scenario you need isn't there, describe the task and we'll build the robot.