https://xxxx/services/data/v61.0/query?q=SELECT Id, Email, FirstName, LastName, LastLoginDate, Service_Generic_Account__c, UserType FROM User WHERE IsActive = true AND Service_Generic_Account__c = false AND UserType = ‘standard’ AND LastLoginDate < LAST_N_DAYS:81
This query returns the Salesforce user ID for users who meet the dormancy criteria, and we proceed to disable those accounts accordingly.
Now we need to pull the below attributes as well.
The above query pulls the email which is users identity attribute as well.
1)Pulling the identityId of the user from SailPoint.
2)Retrieving the user’s manager details from SailPoint.
3)Extracting the manager’s email address.
4)Sending a notification email to the manager regarding the impending deactivation.
Please let us know if you have any suggestions for above scenario.
In my opinion, here you can create an identity attribute which will set value as DISABLE_IN_SAILESFORCE the users for disabling when this critieria is met.
IsActive = true AND Service_Generic_Account__c = false AND UserType = ‘standard’ AND LastLoginDate < LAST_N_DAYS:81
Then you can schdule a workflow on daily basis which will capture the users who have this attribute set in ISC and send the notification.
I believe there will be scheduled aggregation for this source so when the end users disable the account, this attribute will automatically become blank as the above criteria defined will fail and thus the notifications from workflow will stop.
This seems to be an easier approach to meet this requirement in my opinion. Later on when you have more such sources where you want to disable these users then you can enhance this transform and add multivalue and set the value like “DISABLE_IN_SALESFORCE”|“DISABLE_IN_AD” And then this workflow can still be used.
I have already developed a workflow configured to disable the dormant accounts, but here the challenge is to send an information email to his manager as well. Here the manager is a dynamic attribute and need to be pulled from the sailpoint internally.
It has worked fine for me in the past, but i must mention that i used it in the body of the html template along with vtl and not in the recipient field. For recipient then you might need to check first if the manager exists for the user or not and not sure if that will work.
For your information this is what i have used in my requirement to get the email of the manager of the user
$__util.getUser($!{identity.manager.id}).email //here $identity is the template variable and mainly containing the json payload from get identity API.
Also, do note that for your requirement if you are triggering the email based on search then please make sure if you include limited number of users in the search using limit parameter as last when i checked there is limitation on the size of search result in workflows so if during search if number of users found exceeds that limit the workflow will fail.
For that i would suggest you can try using the scheduled search as the trigger if necessary.
Hi Jesvin, i tried this method in postman and it gave the desired result. Now am struck what authorization i need to use to make the intenal API calls.
i getting only 3 options in the HTTP request in the workflow.
If you limit the number of search results then you will need to use recursion to loop over all the results from the search so you can send the multiple emails in batches like 10 users per email.
But you can check with scheduled search trigger, i think that does not have this size limitation but please do double check in you non-prod tenant to include mass number of users.
