Workflow Logic issues - separating new account and add access flow

[BrandonLucas_BF]

I have a situation where most application roles have role owners and need approval, but some of them do not and can be auto approved. On the auto approve application roles, I have set customproperty1 to equal 'AutoApprove'.

I need to design my workflow logic such that for add access requests, it looks for whether or not there is a role owner, and if there is then assign for approval. If there is not, check to see if it is an auto approve CP1 value. If so, grant access. If not, send to a group for an evaluation check/approval.

This workflow is working great for add access request, but when it is part of a new account request, the logic is not making sense. In the screenshot, the red box is the logic followed during add access.  The green box is followed during new account request. However, if the new account request has one of the auto approve roles as part of the request, it always gets assigned to the usergroup custom assignment step. It should instead be completely auto approved end to end and access granted. It seems that when it is a new account request, the variable for entitlement.customproperty1 is showing up as null or something. How can I achieve this use case?

[sudeshjaiswal]

Hello @BrandonLucas_BF,

You can use entitlement!=null block to differentiate new account and add access items or keep SecuritySystem as entitlementsOnly if it is not an issue for you.

Thanks

[sk · Accepted solution]

@BrandonLucas_BF : You can use below condition to detect new account and send it for seperate block

ars_requests.requesttype == 3 and entitlement.entitlement_value == null

[BrandonLucas_BF]

@sk This logic works, but I need help understanding it. Here is the adjustment I made to the 'Is it a new account request' IfElse step:

Now I am seeing the correct behavior:

• New account request with application role where CP1 = 'AutoApprove' gets provisioned without approval. In other words, it follows the False condition, but the entitlement.customproperty1 evaluation occurs correctly for the submitted application role.
• New account request with app role with an entitlement owner is routed to owner for approval. In other words, it follows the False condition, but the entitlement.ownerRank1 evaluation occurs correctly for the submitted application role.
• New account request without any app role submitted will auto approve. In other words, it follows the true condition and goes straight to 'Grant Access' step.

But what is the logic here and how can this be that the simply adjustment to the IfElse condition I can now suddenly evaluate entitlement properties correctly?

[rushikeshvartak]

In workflow

• Entitlement object is used to store role as well as entitlement metadata. 
• hence role & entitlement metatdata cp1 will be found as same column in both object.
• In case of role /Entitlement - Entitlement_value column is only exists for entitlement hence it fails and consider as new account as new account object does not have any property similr to role/ent

[BrandonLucas_BF]

@rushikeshvartak Using a new account request with included entitlements as the example request, are there multiple threads running within the add access workflow at runtime? Example - thread 1 is new account, thread2 is entitlement. How else are the entitlement metadata able to be evaluated by the workflow engine in this way?

[rushikeshvartak]

in parallel workflow each line item consider as separate for approval

[BrandonLucas_BF]

Thank you both @rushikeshvartak and @sk for the helpful info