Workday Spoke: Resetting password to deactivated users, updating syncing and audit the process

[Briayan Hernand]

Hello fellow ServiceNow enthusiasts,

As someone who's relatively new to the ServiceNow platform, I'm in the process of learning and adapting to the responsibilities of my role. I've encountered a challenge that I'm hoping to get some guidance on.

Our company utilizes a Workday Spoke for synchronizing user data between Workday and ServiceNow that was setup by a previous Admin The setup is designed to automatically update ServiceNow when a user is either created or deactivated in Workday.

My focus is updating on the deactivation process. I've located the webhook connection and a subflow that handles user deactivation, as well as a Scripted REST Service. However, I'm uncertain about the best approach to tackle the following requirements:

1. Verification: Double check the user is deactivate. This may not be needed since the deactivating seems to be working as intended that was set up by the previous admin
2. Password Reset: For users who are getting deactivated, the system should generate a random password.
3. Synchronization Frequency: The current setup syncs once daily, but the requirement is to increase this to twice daily.
4. Audit Trail: It's essential to have a tracking mechanism in place for auditing purposes.

Given that we have a Workday DEV instance, I'm looking for advice on how to implement these enhancements effectively. If anyone has experience with similar integrations or can point me towards resources or best practices, I would greatly appreciate it.

Thank you in advance for your time and assistance!

[Mark Manders]

I never worked with the Workday integration, but I can at least help out with some questions:

1. Why? You mention that it is working. You could do a check to validate if the number of active users is the same in both systems, but why would you? If deactivation is going well, you should be covered.

2. Why? An inactive user can't log into the system anymore (assuming you are also locking them out). And if you are using SSO it will be completely impossible, because the user is inactive for SSO as well. But if this is some kind of requirement, you could add an update to the password as well in your 'update user' step. If you put in this script, it will generate random passwords (remove the logging before going live!!!):

(function() {
    function generateRandomString(length) {
        var result = '';
        var characters = 'ABCDEFGHIJKMLNOPQRSTUVWXYZabcdefghijkmlnopqrstuvwxyz0123456789_%$#@!^&*()';
        var charactersLength = characters.length;
        for (var i = 0; i < length; i++) {
            result += characters.charAt(Math.floor(Math.random() * charactersLength));
        }
        return result;
    }

    var randomString = generateRandomString(16);
    gs.info('Generated Random String: ' + randomString);

    // Return the random string as output of the script step
    return {
        'randomString': randomString
    };
})();

3. You will need to find the trigger. Is it in the flow? Or is the flow triggered by a scheduled job or is it something else? Just update that trigger to not once a day, but twice a day.

4. What do you need to track? Changes to the user record? Activate auditing on the user table if that's not done yet and all changes will be recorded.

[Briayan Hernand]

This helps a lot. I went over this with my manager and we figured to just have the trigger/sync up twice a day instead of once. That way it makes the sure the user can't log in after they have have been terminated and since the sync is on a certain time of the day they could still log in before the sync happens. They do have SSO but they still will want the the sync to be more frequent and a random password to be generated.

I am still unable to determine how this trigger is happening as the previous admin set it up somehow. My guess its either a subflow script or a scheduled job 

They still want the password generator so that script will be helpful!

For the audit tracking purposes. They want the records/history to be placed in the notes sections of the requested task that way it shows when they were deactivated and when the password was reset

Thank you for your help and advice on this!

[Mark Manders]

You will have to update the flow to look for the RITM that requested the deactivation, after the user has been deactivated. You can then add it to the notes in that RITM. Do check if that will work and you won't have any ACL's in the way (or trigger unwanted notification on updating). It could be that the RITM is already closed, depending on your proces:

* RITM submitted

* RITM handled on day of offboarding at 4PM -> inactivation in Workday, RITM gets closed

* Next integration run deactivates user in SN. 

There is a time in between, which could mean that you have ACL's preventing an closed RITM to be updated.

Another suggestion: since the RITM is in ServiceNow, why not update the user record on closing of the RITM? That way you don't need to worry about when the integration runs, because in theory, there could be 12 hours left before the next Workday integration locks out the user (even though SSO won't work anymore). 

Your deactivation from Workday will be just another validation, but if the user is already inactive (and password is changed), it just doesn't update anymore.

[Mark Manders]

I haven't worked with Workday, but here are my two cents:

1. Why? You write it yourself: it's going as it should. You could ask for an export of inactivated users on a weekly base and compare it, but why would you? A check on if the integration is running should be sufficient.

2. Why? An inactive, locked out user can't log in and if SSO is activated you are completely safe. But you could add a line to your 'update user' flow to update the password if it's a security requirement. Just use a script to generate a random string of characters to set the password.

3. Find the trigger. Is it a scheduled job? Is it pushed or pulled? Is it a scheduled flow? Just find that and update it to run more often.

4. What do you need to track? If it's just changes to the user record, activate the audit on the table if that's not already done. It will log every change.