Orchestrated process to limit the amount of specified roles to one at a time from IT SHOP

Hi Fernando,

A few things;

Consider adding a step to your workflow to create an event. This should allow you to start a process when the workflow starts (as you say; 'during request') to cancel the old request.

You can even consider adding the step at the end of your workflow (as the final step) so that the revocation happens right before the assignment of the new resource (But after the approval).

Also, what you should do is call the method to cancel the previous order. That way the underlying item should be removed (with the XOrigin = 2). If you try and remove the record directly it'll fail or (if you update the XOrigin to 1 so it works, only doable with SQL) you'll create database inconsistencies :).

A final consideration... If possible consider using something other than UID's to find the orgs, as UID's for data objects (such as org's) are often not the same between environments. A marker in a customProperty of the Org's or some other way to identify them will give you a lot more flexibility.

Hi Fernando,

A few things;

Consider adding a step to your workflow to create an event. This should allow you to start a process when the workflow starts (as you say; 'during request') to cancel the old request.

You can even consider adding the step at the end of your workflow (as the final step) so that the revocation happens right before the assignment of the new resource (But after the approval).

Also, what you should do is call the method to cancel the previous order. That way the underlying item should be removed (with the XOrigin = 2). If you try and remove the record directly it'll fail or (if you update the XOrigin to 1 so it works, only doable with SQL) you'll create database inconsistencies :).

A final consideration... If possible consider using something other than UID's to find the orgs, as UID's for data objects (such as org's) are often not the same between environments. A marker in a customProperty of the Org's or some other way to identify them will give you a lot more flexibility.

HI Jos,

In my case i think there is no problem in using SQL for the XOrigin, cause it filters anyway the three orgs i want, and none of them will be a problem with the XOrigin set to 1
and i can't understand how to make a new event in the same orchestrated process, i add a new step and set it as ? i cant copy the trigger event (the first step) and make another, i will try to apply the something other than UID's for my Orgs.

Thank  you so much!

EDIT, i solved the issue, it was "Assigned by event" in the table, now it detects the orgs assigned by dynamic role and triggers my orchestrated process, now the last thing i need to solve is when my process remove an it shop or an dynamic role, in the web portal, the roles are still assigned, how can i syncronize that?

We've told you twice already, Fernando. I recommended removing the pwo's so the system would remove the personinorg records automatically .

Later Jos Groenewegen told you the same and warned about inconsistencies. But there you are: You've removed by updating xorigin but kept the corresponding records  in PersonWantsOrg (PWO), so the system still believes there are assignments for the user. These are called inconsistencies, yes. 

Hello Juan,

Sorry I didn't get back to you about the inconsistencies earlier. I understand you're trying to help, and I appreciate that.

From my tests, it seemed to be working fine. I also made sure it removes the assignment from the PWO, so theoretically, it should work as expected—right?

Let me know if there's anything I might have missed.

And also, just by removing all of that i can be sure that the active directory groups will automatically be deleted when the PersonInOrg and PersonWantsOrg registers are gone?