Workflow for Super User Access - ID determins WF path

[Rich_Turnquist]

Hi.  We are live GRC 10.1 for Access Control and we have a workflow in place for our super user requests.

We have three types of Super User ids available for the team to request.  Each ID "type" follows a different workflow path.

I created a request type for each of the super user id types.  My decision table uses the request type to determine the workflow path.

The issue I found was that someone can select a request type, but then select a super user ID that does not relate to the request type.  The result is that the request workflows down the wrong path.  So I need to update the workflow to use the super user ID being selected in addition to the request type.

Do I need to create a loop rule to go through the super user id(s) requested?  I created a loop for user defaults because we have different defaults based on the connectors in the access request.  Thinking about this it sounds like this is what I need to do for the access request workflow too.

I was hoping someone else has implemented a workflow where it's based on the super user ID being requested.  Actually if anyone implemented a workflow that is determined by any object requested in the ALV section (role, system, pd profile, etc..) it would probably be the same thing in BRF+.

Looking for feedback.

Thanks,

Rich

[patrick_weyers]

Hi Richard,

If you are going to need a loop (rather than a BRF+ flat rule) will depend on the following question:

Will the path be determined for each Firefighter ID individually or will a path be determined for the entire request?

In the first case, you can use a BRF+ flat rule with a decision table based on the line item and the name of the firefighter ID. If an access requests contains multiple firefighter IDs that will route to a different workflow, you are going to have multiple paths within the same request (which is absolutely fine, so long as you desire it to be that way!). This is rather straight forward and I've done this many times for example for role names.

In the second case, you are going to have to define a loop. In this case, you would need to define the conditions that trigger the workflow for the entire request. Specifically, you are going to have to tell the system what should happen if the user requests different firefighter IDs. This is the more complex scenario but from how I understand you, the first scenario will be applicable.

Hope this helps and do let me know if you have further questions!

[former_member251105]

Hello,

can any body say me please with which context data object in the decision table I can find the firefighter ID?

Thank you.

Regards

[FilipGRC]

Hi Richard,

how does those 3 different super user ID types are differentiated?  I would try with adding another criteria to your initiator rule, for example user group or other specific criteria which differentiate this different superuser type.

How to do this?

Please look at this article:

in point 4.1 it is described how initiator rule is updated with request type, if you follow the same logic and add another criteria for initiator rule.

I think user group would be the best (requires FF account assignment to user group) but in the worst case scenario (hard to maintain) you could different path based on USER ID.

Filip