Apply Assignment Rule taks in BPM does not respect "Multiple Assigned Users"

**yuri** · 02-17-2026, 01:29 PM

Hi,

Currently, multiple assigned users field is not covered by the Apply Assignment Rule action. There must be workarounds though.

**heint** · 02-17-2026, 03:58 PM

Greetings, p4zdy,

Since direct functionality is not covered properly yet, please attach the screenshot of your action where you are trying to apply the "assignment rule" to the target entity. Maybe I or someone else will suggest a temporary workaround based on that additional screenshot.

**p4zdy** · 2026-02-18T12:44:39+00:00

Hello,

yuri thanks for reassurement, I'll keep that in mind for future scenarios
heint I'm glad you're willing to help me out - the scenario is really simple -
we have a custom entity called "Internal requests" - it's meant as a request inside the company.

First gateway only sets the name to generated id when it's not filled manually - no problems with that, it works

Then there is an enum which specifies whether the request is targeted for a specific users or teams (this is handled by the second gateway) - when we select users (uživatelé), there's a link-multiple of Users and we just assign those users to assignedUsers - it works fine cause it's both multipleEnum type and we have it completely under control

The problem is with the second scenario - when we target the request to a team - the third gateway is for manual mapping of our enum field to teams - this gateway goes to tasks called "Obchodní oddělení", "IT oddělení", etc. - this is just a placeholder task. The task which follows is "Přiřazení" which is the Apply assignment rule - this is the part we have problems with, because it assignes the user via round-robit to the entity, but to a "wrong" field in our setup. We tried to add the additional task "Přiřazení linkMultiple" which copies the assignedUser to assignedUsers - but that's the part which sends the second unwanted email about assignment

There are the two scenarios - targeting to user / targeting to team:

We don't want to keep the entity unassigned - there's a need to always assign someone, who will either take care of the request, or delegates the request to someone else who is responsible for that specific request. I guess it's the same everywhere - when you assign a task to a team, everyone leaves it to "the other one" and nobody eventually solves the request. Or the second extreme - everyone starts solving it simultaniously

I don't think this is some extra feature requirement, it feels pretty basic. I guess we could come up with a formula which would replace the advanced pack task for assignment, it just didn't feel like a "clean" solution

**heint** · 2026-02-18T16:40:31+00:00

So, as one of the workarounds, I can suggest the following to recreate the logic of "Apply Assignment Rule" as round robin (if it were the other rule, I would have no clue how to simulate that logic, or it would be harder to implement).

)

So, you need to create the Auto-increment field for your entity (it's not necessary to post it on the layout). Let's call it CurrentAutoImplement.

Instead of your Apply Assignment Rule BPM action, please paste that snippet of the code as "Execute formula script":

Code:

$currentQueue = cCurrentAutoImplement % 3 + 1;

$userIdOne = '68d6b100b5139df66';
$userIdTwo = '68db83a54c11f1f5c';
$userIdThree = '6995dbe8c1f93f80b';

ifThen(
$currentQueue == 1, entity\addLinkMultipleId('assignedUsers', $userIdOne),
ifThen(
$currentQueue == 2, entity\addLinkMultipleId('assignedUsers', $userIdTwo),
entity\addLinkMultipleId('assignedUsers', $userIdThree)
)
);

Use IDs of your respective users instead of the value mentioned above. This example could be scalable depending on your number of users.

I hope this will help, and I don't forget about something that would break the logic.

**p4zdy** · 2026-02-19T07:38:25+00:00

Hello again heint, thanks for the workaround - it seems that it would work, but it felt easier to change the roundrobin.php itself, instead of changing all actions to formula. I always avoid changing core, but this time it felt right. If anyone'll face the same issue, I added a simple metadata check and slightly altered the assignment process in custom\Espo\Modules\Advanced\Business\Workflow\Ass ignmentRules\RoundRobin.php
yuri if it's correct, you might consider including this in the next release

Here's the change (approx from line 126):

Code:

 {REDACTED}

I've tested both scenarios - entities with multiple assigned users active and inactive - both seem to work fine without gimmicks. The core assignment mechanism is untouched, this only changes which attribute gets changed

Apply Assignment Rule taks in BPM does not respect "Multiple Assigned Users"

Apply Assignment Rule taks in BPM does not respect "Multiple Assigned Users"

Comment

Comment

Comment

Comment

Comment