We have a requirement where if an identity is not having a manager, then we need to set a default manager as a static value for that identity. We have the manager correlation logic in place for the authoritative source(Delimited source is the auth source) and it’s working fine, but if in case no manager is there then add ‘Tom Mike’ as the manager by default.
Could someone please let me know if for this scenario, do I need to configure a manager correlation rule or is there any other way to do so.
Thank you in advance for any possible solutions.
You could apply a transform with this primitive when the manager attribute is mapped in the identity profile. If the manager input is null, it would choose the next item in the values array, which can be the string “Tom Mike”.
Thank you for your reply and suggestion. But there is a change in the requirement as below:
Pre-Condition: Access Profile is having 2 approvers, 1st-Line Manager and 2nd-Governance groupA.
Current Functionality: When access request is made by a user for the above access profile and the user is not having a manager then manager level approval is skipped, and it goes to 2nd level i.e. Governance groupA approval. Two more approvals are added- App Owner and Source Owner as manager approval is skipped. PFB Screenshot of the real time scenario:
Requirement: When access request is made by a user for the above access profile and the user is not having a manager then don’t need to skip the 1st level approval(manager) instead have a governance groupB approval as the 1st level when manager is not there.
And then the corresponding approvals will flow as per expected. Example: In the above scenario, approval workflow will be like:
Governance GroupB -1st level approval (instead of manager)
Governance GroupA -2nd level approval
We also need to stop the functionality where app owner and source owner approvals are triggered in place of manager as we need to configure the Governance Group instead.
Can you please help me with this. Thank you in advance.
Hi @ayeshashahu At this time, we do not have a way to override the backend “reassignment” processes that occur when identities do not have a manager identified in Identity Security Cloud.
As you pointed out in the supporting documentation, the behavior you are seeing is how the product is designed.
The only way to prevent the manager approval level from getting “skipped” (which isn’t 100% accurate because the manager level gets reassigned to the app and source owner then added after the prescribed 2nd approver) is to ensure that all identities have a manager assigned. This is obviously not possible 100% of the time because some identities may, indeed, not have a manager, and some non-human identities may not, by configuration, have an assigned manager either.
In summary, the only known workaround we know of at this time is to assign a manager to identities whose access will be requested via the request center.
The only other suggestion I have is to submit a new idea to the SailPoint Ideas Portal. I already researched and did NOT find a matching one in my search - you may want to search different words to make sure this idea doesn’t exist yet. You will be asked to provide a use case for why this new behavior is desirable. Feel free to paste the link back in this forum topic, so others can vote on it if they wish to.
I do know the Product Manager for the Request Center and she is responsive and is truly focused on improving the product.
Hi @ayeshashahu Great! I thought of 1 possible angle for the idea:
Using the REST API, we have a way to update some of the configuration around Access Requests: change the frequency of reminders, set the number of reminder email notifications, and set an escalation path (for unresponsive approver situations):
What if this Access Request configuration definition also contained a section for us to set a reassignment path, to support the case of an identity without a manager?
Just a final thought, in case you might want to mention that also. Have a great day!
Hi Tom,
Thank you for your reply. We also have this requirement, so I tried to implement your idea with the below transform logic:
{
“id”: “de5418b1-XXXXX”,
“name”: “Default Manager Transform”,
“type”: “firstValid”,
“attributes”: {
“values”: [
{
“attributes”: {
“sourceName”: “Workday Delimited - Employees”,
“attributeName”: “supervisor_wdid”
},
“type”: “accountAttribute”
},
{
“attributes”: {
“value”: “659817”
},
“type”: “static”
}
]
},
“internal”: false
}
I tried the same above logic on a different/random attribute and it was populating/working for that. Is it because the manager attribute is also the correlating attribute and the transform logic is implemented before/after the correlation logic is implemented or vice versa? (PFA screenshots for your reference). Thank you.
Hi @ayeshashahu You are correct. The fallbackApproverRef object can ONLY be of "type: “IDENTITY”.
The only way I can think of to get around that is to:
a.) create an identity that represents a group
b.) the email address for this “identity” is a group email account that they all watch.
Not sure if that is an alternate configuration that might be helpful to you in the case of the fallback approver? It’s not something I think would be a “best practice” for all governance groups. Simply a suggestion I just thought of…
Hi Amy, thank you for your valuable reply and a great solution but the idea is not to set a fallback approver, the idea is to not skip the manager approval (for which we’re setting a default manager now, so if in case identities don’t have managers then a default manager will be assigned. I’ve requested @TomNimmo to enlighten me more on this topic). Though, we will also be having fallback approver for escalation/reminder purposes.
Thank you again for your continued support.
Of course, totally understand. Sometimes 1 creative solution spurs another. I see you are investigating transform logic with Tom to set the manager. Fingers crossed you’re able to identify a solution that will work for your situation!
Hi @TomNimmo ,
Yes, I applied the changes to the Identity Profile too. I also tried re-aggregating the identity and doing the identity refresh, still it doesn’t reflect. I tried creating a new user with the transform already in place too, unfortunately no luck. Can you please help me on this, it would be really helpful.
