<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D54z00008jU8YRCA0Okta Classic EngineIntegrationsAnswered2023-02-22T22:47:33.000Z2023-01-29T22:50:15.000Z2023-02-22T22:47:32.000Z

MikeM.05092 (Customer) asked a question.

Workday as a master - avoiding admin account deactivation upon import

Okta admins,

So we have just implemented an integration with Workday. Generally, working well. But I have a potential issue with my own Okta superadmin account that I hope to get feedback/reassurances on. Current setup in Okta:

  • Workday is profile master (WDaaM)
  • When a user is deactivated in the app: Do nothing
  • Auto-confirm for matches & new users is OFF
  • Import matching is on employeeID/employeeNumber (WD/Okta)
  • in both WD and Okta, username = email
  • AD not present

 

A first manual import was done that generally went fine (a few unexpected deactivations among 500+ users, not a big problem).

 

The issue: I just transitioned from contractor to employee in WD. WD has two accounts for me: my contractor account, now deactivated ("contract ended") and my new employee account. Same username & email in both. This transition happened after the first import.

 

My Okta account is still linked to my contractor account in WD. The employeeNumber in Okta is the number associated with the WD contractor account. There is an "external ID" in my Workday app assignment in Okta.

 

My fear: The next import I try will result in deactivation of my Okta account. Or maybe a deactivation/reactivation cycle. Either will have very unfortunate downstream effects on various apps, which I am admin on too. A fellow admin can reinstate my Okta account, and the reactivation can flow downstream, but I know from past experience my admin status on many of these apps will not return automatically, I'll need my fellow admin to painstakingly reinstate my admin status in many places. I want to avoid this.

 

My goal: to establish a link between my existing Okta account and my new WD employee account, with no deactivation.

 

What I have done:

  • Unassigned myself from WD, thus clearing out the external ID in my WD app assignment;
  • Gained editing access to my employeeNumber (my import matching field) in Okta via attribute-level sourcing, and edited it to match my WD employeeID on my new employee account.

 

Should this be enough that when I do another import, I will get a match confirmation in the import pane and be able to link my existing Okta account to my incoming WD employee account?

 

(I know there is a configuration to accommodate these contractor-employee transitions more generally, involving establishing a universalID. Hoping to just get past my current concern and not go down that path for now.)


  • MikeM.05092 (Customer)

    Addendum - the attribute-level sourcing on employeeNumber, I realize now, is not needed since with WD unassigned I have full editing access to my Okta user profile.

    • DonF.81354 (Customer)

      Correct! Once disconnected from Workday, it is then an “Okta-mastered” account. Changing the attribute-level sourcing to Okta instead of Workday would allow you to control the attribute value for all users, whether they are sourced by Workday or not. I would recommend you allow this to remain “owned by” Workday so that it can be created/updated by the HR system that ultimately masters the value anyway. Hope that helps! Thanks!

      Expand Post
  • DonF.81354 (Customer)

    Hi! I would say a few things here, first I would be sure to create an Okta service account that is not tied to a directory or to a particular user. Keep this password in a safe location (Keepass, LastPass, etc.) and do not use for regular operations. This will ensure that even if you are to be locked out or deactivated, you can recover and continue operations in Okta.

     

    Second, for Workday you have a few settings that should be reconsidered given your particular wants/needs. First of these is “when a user is deactivated in the app: XXX”. For both security and licensing considerations, be aware that when users are terminated in Workday, this setting will not deactivate/suspend the user in Okta (and thus any of their downstream integrated applications). Second, even if there is a match with the workday version of you and the Okta version of you, they will not be auto confirmed and will be sitting on the import page for your manual review and confirmation.

     

    With that being said, you should be able to link the accounts at that page and not experience an issue. Furthermore, the account coming from Workday is the active one, as deactivated accounts will not flow over. And most definitely, configuring Workday as a master is definitely the right choice in your circumstance.

     

    Finally, I would really recommend that you enable the settings on both Okta and Workday side for optimized user conversions. There is a feature flag on Okta side that can be enabled as a result of support ticket and it is required to recognize these conversions. Without this, a user conversion will disable the account in Okta and create a bit of a mess for the user who is still employed and expects to be able to login. Of course, on next import/sync they will come back over, but it will still create downtime for the user in the event this flag is not enabled.

     

    I do hope this helps! This was a long-winded response, so please do let me know if you have any questions and/or concerns. Thanks again!

    Expand Post
  • MikeM.05092 (Customer)

    Really appreciate your feedback Don. The backup service account is a great idea to at least allow me to recover Okta access without bothering the other admin, in case of problems.

     

    The "When a user is deactivated in the app: Do nothing" setting (under Provisioning > To Okta > Profile & Lifecycle Sourcing) is intended to be temporary, just for this next import, to help ensure my account does not get deactivated. I will turn it back on after that import.

     

    I have asked support about enabling a feature flag related to my issue, and the one I have seen references to, profile_sync_user_reactivation, is apparently no longer available.

     

    But I think I will be ready to give the next import a try later today. Thanks again for the feedback.

    Expand Post
  • MikeM.05092 (Customer)

    Just did my next WD import with Okta support on the line. Went great, no account deactivation. My unassigning my account from Workday, and editing my employeeNumber in my Okta profile to match the number in my new WD account, did the trick to make a clean match in the Import pane in Okta. I confirmed the match, and was good to go.

    • DonF.81354 (Customer)

      Glad to hear everything worked out for you! Thanks and feel free to reach back out if you have any further questions! Thanks again!

This question is closed.
Loading
Workday as a master - avoiding admin account deactivation upon import