Enable Rehire settings in Saviynt

[rahul_p]

Hello Team,

Hope you all are doing great.

We want to enable re-hire in system, Saviynt provides following settings:

1.REUSEINACTIVEACCOUNT => TRUE (As per this, Saviynt will check for inactive account present or not before creating new one)

2.ENABLEACCOUNTJSON => This setting not clear,

Document says like attached pic.

Below is not clear :

a. When ENABLEACCOUNTJSON settings will trigger?

b. We have Disabled OU(where user moved by disabled JSON) and General OU(Where user created/moved while creation/enable), which OU we need to give into this REUSEACCOUNTOU attribute?
Please comment.

Thank you in advance.

Regards,

Rahul

[BrandonLucas_BF]

Hi Rahul -

Enable Account JSON is for a user update rule with enable account as the action. When a user update occurs that triggers a user update rule with this action, it will execute whatever you have in the enable account JSON field. A lot of times this JSON is very similar to create account JSON in that you are going to use it to possibly re-activate a disabled account and place it into certain OU or perhaps update description on the account to show that you enabled it with Saviynt. Different connectors can do different things but with the AD connector you have the ability to move the account from a terminations/separations OU back to the correct org structure. Here is a sample of our JSON to give you an idea on how to accomplish this:

{

    "DISABLEACCOUNTCHECKRULE": [

        "employeeNumber=${user.username}"

    ],

    "USEDNFROMACCOUNT": "YES",

    "MOVEDN": "YES",

    "REMOVEGROUPS": "NO",

    "ENABLEACCOUNTOU": "${if(user?.statuskey==1 && user?.employeeclass.equals('Partner') && user?.customproperty14==null){'OU=Partner,OU=Users,DC=contoso,DC=net'}}",

    "AFTERMOVEACTIONS": {

        "description": "Enabled by Saviynt on ${(new java.text.SimpleDateFormat('yyyy-MM-dd HH:mm:ss').format(new Date()))} UTC",

        "userAccountControl": "512",

        "departmentNumber": "${user.costcenter}",

        "st": "${user.state}",

        "title": "${user.title}",

        "sn": "${if(user.customproperty1.equals('IsEmployee')) {user?.getCustomproperty30()} else {user?.getCustomproperty31()}}",

        "extensionAttribute6": "${user.lastname}",

        "mail": "${user.email}",

        "extensionAttribute10": "${user.email}",

        "givenName": "${user.preferedFirstName}",

        "extensionAttribute4": "${user.preferedFirstName}",

        "displayName": "${user.displayname}",

        "title": "${user.title}",

        "personalTitle": "${user.title}",

        "manager": "${managerAccount?.accountID}",

        "physicalDeliveryOfficeName": "${user.location}",

        "l": "${user.city}",

        "personalPager": "${user.customproperty11}",

        "st": "${user.state}",

        "department": "${user.departmentname}",

        "accountExpires": "${if(user.enddate != null){(10000*(user.enddate.getTime()+ 11644577999999))} else{'0'}}",

        "extensionAttribute15": "${user.regioncode}"

    }

}

As for the first part of your question, I'm not sure the use case and it depends on what you are trying to do, but we don't need to use REUSEINACTIVEACCOUNT for rehire. If you retain the users who have left the company and may be rehired in the system, Saviynt does not lose awareness of their accounts by default. They will stay associated to the user even if they are disabled and the user is inactive. We know what the data will look like coming into our user feed that indicates rehire, so we simply have a user update rule that enables their accounts and re-runs our birthright rules. The birthright rule will detect if they do not have an AD account and provision a new one.. otherwise, the enable account action is run for their associated AD account and the birthright has no work. 

We also do reset password action for AD when users are rehired. We can do this with a reliable flag from our HRIS that indicates a rehire condition. We make the assumption that when we see this indicator they may have forgotten their credentials (even if it was a week ago that they left), so we do a complete reset and re-onboarding.

[rahul_p]

Hello @BrandonLucas_BF ,

Thank you so much for the reply.

We have 2 scenarios in our case,

1.We disable user when user is leaving the company.
=>In this case we need to enable the inactive account as user joins back within 180 days post termination date.

2.After 181 days of starting from when we disabled the user, we deletes the account.

=>If user joining after 181 days, then brand new account need to provision.

So considering your solution:

In user update rule, "Enable User Accounts" action will enable inactive account(if user join within 180 days) or create brand new account (if user joins after 180 days)?

Is my understanding correct?

Thanks,

Rahul

[BrandonLucas_BF · Accepted solution]

Test the scenario, of course, but I believe similar to what we do here would work for you. 

• For 180 days, the AD account is disabled but present in AD and attached to the user record as a disabled account.
• From day 181 and beyond, the AD account is deleted, but will still be attached to the user record as missing from import.

So, have a user update rule that first triggers an enable account action for AD whenever the rehire event is detected. If within 180 days, the account is still attached and disabled, so it should run your enable account json and place the AD account back into the OU structure you have configured.

Second step of the same user update rule will mostly have impact from day 181 and beyond, and it should be to call a technical rule for the purpose of establishing some type of birthright for the AD account in case it has been deleted. Sav should see that the associated AD account for the user has been removed from import because it no longer exists, and it will try a create account task on AD using your createaccountjson. Your technical rule just needs to be to assign an account on AD and apply any role you wish. When this runs for users who already have an AD account, it would just discontinue the task.

(Note: I haven't tested the behavior around what would happen if the account is showing as deleted from import,  but I believe this is how it should function. Currently we are not deleting AD accounts so this is not part of our scenario.)

Let me know if this design works for you!

[rahul_p]

Hello @BrandonLucas_BF ,

Thank you for your quick response.

We will create the user update rule which will detect the rehire event and will re-run the provisioning rules. We will test this and get back to you.

Thanks,

Rahul

[rahul_p]

Hi @BrandonLucas_BF ,

Hope you are doing great.

Thank you so much, user update rule is working as expected in case of re-hire.

Now only question is, AD account of user is disabled and we need to change the password during enable operation as part of re-hire.

I added change password action in user update rule, but I guess to trigger change password action, AD account should be active.

Can you please comment on this.

Regards,

Rahul

[BrandonLucas_BF]

Rahul -

Amazing! Good to hear. Your assumption is correct on the change password operation. I posted an idea around this very topic a while back. Please consider upvoting it: Change Password task generation for inactive | Saviynt Ideas Portal

In our environment, I had to implement logic to first enable the account, then change password after the provisioning cycle had executed and account was enabled. I do this with Sav4Sav job. The data indicating rehire comes from our HR system and populates a custom property. This triggers update rule to enable account. I have a Sav4Sav job that looks for the custom property that was populated with the rehire value, and if it sees that the rehire value is there and the account is enabled, then it creates a change password task by populating another CP.

I do this with a query like below. CP26 is set to 'Rehire' by our HRIS. SQL query looks for the username of the user and puts 'RehireReset' into CP33 field if the conditions match: user has an account on AD endpoint with an active account and CP33 is null.

The important point here is that with Sav4Sav it will look for only empty CP33 fields and in the process populate them with data if the 'Rehire' flag is set in CP26. Populating CP33 triggers another user update rule which generates the change password task.

SELECT

    username,

    'RehireReset' as customproperty33

FROM

    users

WHERE

    userkey IN (

        SELECT

            DISTINCT u.userkey

        FROM

            accounts a

            JOIN endpoints ep on a.endpointkey=ep.endpointkey

            JOIN user_accounts ua ON ua.accountkey = a.accountkey

            JOIN users u ON ua.userkey = u.userkey

            WHERE (

                a.status = 1

                OR a.status = 'Manually Provisioned'

            )

            AND ep.endpointname = "Active Directory"

    )

    AND statuskey = 1

    AND startdate <= ADDDATE(current_date(), INTERVAL 30 DAY)

    AND customproperty33 is null

    AND customproperty26 = 'Rehire';

One logic issue to consider is that if someone leaves your company a second time, and then is rehired a second time, this logic may not work a second time unless you clear CP26 and CP33 when they leave. For us this is a very rare scenario so we have not designed around it.

Please consider accepting my replies as solutions if this works for you! Have a great day.

[rahul_p]

@BrandonLucas_BF Thank you so much for your valuable inputs.

Regards,

Rahul