BP error: Cannot acquire assignees array for dynamic approval

[Joanne]

hello,

 

i am seeing this on our live BPM processes - Cannot acquire assignees array for dynamic approval (global.flowcode.authAutoAssignees)

 

I cant see there is anything wrong with the processes and it hasn't been changes

 

Can this be looked at urgently please

 

Many Thanks

 

Jo

[Victor]

@Joanne - if you restart the process (screenshot below) does this resolve the issue?

The error occurred (from what I can see in the logs) because the user that progressed the process to this point, did not have enough rights to retrieve the list of users from the group. The group that is supposed to authorise the next step...

[Joanne]

Has any updates been made as we haven't made any changes.

Do you want access they would need to be granted so i can see they permissions have been changed

Thanks for looking at this

Jo

[Victor]

@Joanne - I explained above, this is not caused by an update or a change but by the fact that the user who progressed the process (the request) did not have rights to progress it to the authorisation point sucessfully... A possible reason why you see this error now, and not on other occasions, could be that the users who progressed other requests did have the required rights...

Have you tried restarting the process?

[Joanne]

Yes, i have restarted the processes.

 

Can you you let me know what rights they would need? is is a particular role

 

Many Thanks

Jo

[Joanne]

the next step in my BPM is to get a list of people and assigned a task to them to authorise

 

cheers

 

jo 

[Victor]

21 minutes ago, Joanne said:

the next step in my BPM is to get a list of people and assigned a task to them to authorise

Yes, I assumed so based on the APIs that are getting used... 

23 minutes ago, Joanne said:

Can you you let me know what rights they would need? is is a particular role

The issue is that the only role that would give the user the required rights to retrieve the list of authorisers from a group is the "Admin Role". I will come back to this below. The immediate solution would be:

• assign the "Admin Role" to users that progress these change requests (not quite recommended given the "Admin Role" is quite a powerful role);
• create a custom role that only has the "Manage Users" rights, as per screenshot (this is still quite a powerful right, not as much as "Admin Role", but it would be the best option available at the moment)

Custom Role Details tab:

Custom Role System Rights tab:

The role name is just an example, you can choose whatever name you like for the custom role. Assign the role to all users/analysts that usually progress change requests (users that do not have the "Admin Role" associated to them already).

 

Going back to the issue where the "Admin Role" is required to retrieve a list of users from a group. I would say that for such a simple operation, having such a  powerful role is not necessary and it should be doable with other roles. I will ask our dev team if they can include this particular right in lesser default roles or change the logic in the get authorisers list to require a lesser right (instead of "Manage Users").

[Joanne]

Hi Victor,

 

I'm very confused,  there has been no change to the processes and as of yesterday my users can raise call and the BPM would automatically get users from a group and create an activities, so i'm not trying to do anything different form yesterday.

When all of my IT staff create a change request the BPM is failing here, and i don't understand what has changed (it maybe something that we have changed here), but more important i do not know how to fix this issue

Is it possible to have a telephone conversation

Many Thanks

 

Jo 

[Victor]

@Joanne - is this affecting all users and all business processes ?!? I don't see how and it contradicts the events in the logs...

In today's logs, there are 29 occurrences of the "Get Authorisers List" action (this is responsible for the dynamic approval). This is invoked from within a business process associated to a change request. 24 of these are successful, 5 of them failed with the error you reported. As such I assume this does not affect all change requests and happens in some specific scenarios, which I described above. At this point, with the information I have so far, I cannot link these failures to any system update.

Do you have an example of a user that raised a change request yesterday, with no error, but raised a change request today and the error occurred?

I said above that based on the information I have so far this does not seem to be caused by any system update, however,  I am not ruling out any possible issue caused by an update but we would need more information that indicates this... such as "do you have an example of a user that raised a change request yesterday, with no error, but raised a change request today and the error occurred"

39 minutes ago, Joanne said:

i do not know how to fix this issue

I provided a solution above, have you tried it?

39 minutes ago, Joanne said:

Is it possible to have a telephone conversation

You can request a product specialist assistance via expert services but I'm afraid your current support plan does not give access to support directly.

[Victor]

@Joanne further to this:

2 hours ago, Victor said:

I will ask our dev team if they can include this particular right in lesser default roles or change the logic in the get authorisers list to require a lesser right (instead of "Manage Users")

Dev team confirmed they will implement a fix in the next platform update (which is approx 2 weeks away). This will fix the error for the users that currently do not have sufficient rights to progress the request. Meanwhile, I would advise implementing the custom role solution. If you need help implementing this please let me know and I will look in creating it in your instance.

[Joanne]

Sorry, I'm struggling to understand this, do you have 30 min free tomorrow morning to discuss, while i don't yet have a support contact i do have hours left in my SOW that we can dip into

 

Many Thanks

Jo 

[Victor]

@Joanne - I have asked our dev team if they can deploy the fix so you won't have to create and apply any custom roles.

I can ask one of my colleagues from the Customer Success team to have a chat with you tomorrow if you still want?

[Victor]

@Joanne - the fix I mentioned above has been deployed on your instance so the error will no longer occur on any new logged change requests. It is not necessary to create any custom roles or associate any roles to any user, you can continue to operate as usual.

[Ann-MarieHolloway]

Good Afternoon @Victor

I would like to advise that we also have the same issue on our instance of Service Manager 

I can see that update Build: 1422 is available and I am in the process of creating a Change Request to install this.  I cannot find the fix for this current error, so I'm assuming it will be in a subsequent release.  Therefore, would it be possible for you to install the fix on our instance and if so, would we need to restart the workflow to pick it up?

[Victor]

@Ann-MarieJones can you tell me the request reference for this, please? I need to see if this is a new error or not...

[Ann-MarieHolloway]

Hi @Victor

No problem.

    

Restarting the last step unfortunately returns the same error message and the variable picker appears to be correct

[Ann-MarieHolloway]

[Victor]

@Ann-MarieJones - we're looking into this, will come back with more info...

[Victor]

@Ann-MarieJones - we fixed the issue. Fix will apply to all new change requests. I am now looking to see how I can fix CH*18458

[Victor]

@Ann-MarieJones - good news, CH*18458 is also fixed now

[Ann-MarieHolloway]

Morning @Victor 

It would appear this issue is persisting.  Our analyst Abderrahmane Akalay created Change Request CH00019360 at 08:38 today and completed the initial review Activity, however now timeline is frozen with the following error message 

[Victor]

@Ann-MarieJones - looking into this now, please bear with me. Based on the latest updates, this definitely should not happen but I'll investigate...

[Victor]

@Ann-MarieJones - ok, the underlying issue is fixed, there was an issue accessing a system table (ones that store the users) which the node would need in order to retrieve the list of approvers. I will now look into having that CH fixed as simply restarting the process won't suffice. I'll also have a look to see if there are any other CH with the same issue and fixe them if they are...

[Ann-MarieHolloway]

That's brilliant @Victor thank you for your assistance with this matter.

Do you happen to have an understanding of what caused the node/table?

[Victor]

@Ann-MarieJones - yes, one of the "new" roles used by the BP engine to progress the workflow on requests was missing a right to access the table that stores the users in order to retrieve the list of users for the authorisation stage/node... I say "new" because in the latest platform update we made some improvements in the process engine but sadly we overlooked this particular right for the particular node (Retrieve List of Authorisers).

I have fixed CH00019360  but looking through other change requests I can see a few others having the same issue. I am working to have them all fixed, please bear with me...