I have built out a process to send Managers an email within 24 hours of the users Cube being created. Based on everything I have tried it was determined to build this process outside of IdN Workflows. I spent 120 hours trying to get a workflow that would meet our needs. This in turn had my leadership pivot and have me build an in house script to send these emails.
I have built out a working script to send the manager an email for Cubes created in the last 24 hours. When reviewing this we discovered a blind spot where a Manager will not always get an email. The root cause of this varies depending on the user.
Below are the top 4 reasons that a Cube would not have a Manager populated on it. Looking at this from a programing prospective I have the challenge of addressing each of these cases. At a high level my script does a search in ISC and then pulls back all the needed information. When doing the Manger lookup I am pulling the ID from ManagerRef object in the search response. Most of the users in question do not have a ManagerRef on their cube. Any ideas on how to address this so that emails go out to the proper person?
Manager uses his email address on multiple worker records in NERM.
Manager is termed
Worker has a termed WD account on his cube with a termed manager
Manger was original created in NERM and then was hired into Workday
So without knowing a ton about your environment or each situation, from a programming perspective it seems you need to add error handling (try/catch or something comparable) to account for these cases. For example, add a check to see if the manager is termed, and if so, send it elsewhere (a fallback email or perhaps the manager of the manager). I don’t know much about NERM so I’m sorry I can’t be more specifically helpful to that, but either way I’d advise finding a way to catch these situations and account for them with your script.
Hey @mpotti
So here’s my idea on the above scenario you discussed.
Calling search api to get identities created in last [24] hours. And include the attributes Manager, created date, lifecycle state, Source and any other information that you may require.
Manager → Reportee is One to Many mapping. And ideally we should not send like n number of emails for that one now as you have a custom script in place, this can be handled.
When you do a ISC search make sure that whatever that search returns, you are creating a map of some sort a data structure like String->[String] would help.
So you create a map, and manage the Manager->Reportee mapping so in one email you can send for all the reportees of that manager.
Now here one point to make sure is that you can create a map such t that you don’t include termed reportees if you do not want to include them in email sent to manager.
Now when Sending the email to manager now we want to make sure that [it is not termed and is a valid manager meaning has a managerRefID].
So if it the manager is termed maybe you can send that email to lets say the manager’s manager or maybe to a IAM distribution list so anyone can take that up and send to appropriate person.
I assume the use case here is to make sure that if the manager is in NERM, you want the manager from Workday eventually if that has been hired in Workday.
So for this one ideally you would have a correlation logic to correlate both accounts so this can help if you have user in workday you can get the information from the Workday source using get account attribute API and use that email from Workday to be used to send email.
But lets say if the accounts are not being correlated, then there would be some unique identifier determining that both [ NERM, Workday ] the accounts belong to same person. You can search the identity and use that identity information to be used to search the identity and get the Workday identity information.
I know you would have brainstormed through this design already but just putting it out there in case if this helps.
Thank you both for the replies. The main issue around this is our transforms. When the transform were built it was never considered to do the calculation to see if the workday account is active.
In order to fully fix this we would need to update all our transforms to check if WD account is actually active and if not then pull the data from NERM.