Workday Provisioning (2024)

Okta can import users and groups from Workday through its standard API. Okta only imports Workday Provisioning Groups. Workday Security Groups aren't imported.

Okta supports three types of imports:

• Full imports
• Incremental imports
• Real Time Sync imports

Full imports

Full imports bring in all workers and all base and custom attributes. While these imports are time-consuming, you must schedule them to perform reconciliation between the two systems. You must also schedule them to bring in attributes that aren't supported in the other import types. Typically, this task is performed once a week. The full import includes base attributes, non-future, and future effective dated custom attributes. It also includes any changes that incremental or Real Time Sync imports omitted.

Incremental imports

Incremental imports bring data for workers that Workday identifies as updated since the last incremental import. Make changes in the base, or non-effective future dated custom attributes, to include the worker. Changes to effective dated custom attributes alone don't trigger an incremental import. Included in the incremental import are base attributes, non-future, and future effective dated custom attributes. Schedule incremental imports at an interval that supports regular business processes. Typically, this would be at least once per day and can be scheduled as frequently as once an hour. See Incremental imports.

Real Time Sync imports

Real Time Sync (RTS) is used to trigger an update from Workday to Okta in real time. Use this for changes where timeliness is critical, such as immediate termination of a worker. Configure a business process in Workday to send the trigger to Okta to start this process. Included in the RTS import are base attributes, non-future, and future effective dated custom attributes. See Workday Real-Time Sync.

The optimal configuration of these import types ensures optimal data accuracy and timeliness of data moving from Workday to Okta. When you configure imports, consider the features and limitations of each import type.

Okta supports two typical scenarios: import from Workday and Workday-driven IT provisioning.

Import from Workday

Import from Workday to Okta includes users and groups. Okta users are created from imported Workday users, and then you can use imported Workday Provisioning Groups to assign apps. Workday no longer manages users after they've been imported into Okta. Updates made to the user in Workday don't affect the associated Okta user. Okta groups are created from imported Workday Provisioning Groups.

Workday-driven IT provisioning

Okta integrates with Workday to drive IT provisioning. When a Workday user is imported into Okta, Workday continues to manage them. Updates and terminations made in Workday are reflected in Okta and downstream apps. This arrangement enables Workday to manage employee and contractor access to apps. Workday-driven IT provisioning is a superset of the functionality provided by imports from Workday. Therefore, the instructions for configuring Workday-driven IT provisioning are also relevant to import from Workday scenarios.

With Workday-driven IT provisioning, Okta supports the following worker lifecycle events:

• New hire

  • A new Worker is hired in Workday
  • Okta imports the new Worker and creates an Okta user profile
  • Okta creates accounts in downstream apps (AD included)

• Updates

  • A Workday user's attribute is changed in Workday
  • Okta imports the attribute change
  • Okta updates the attribute in downstream apps (AD included)

• Termination

  • A Worker is terminated in Workday
  • Okta imports the status change
  • Okta deactivates the Okta user and accounts in downstream apps (AD included)

• Rehire

  • A terminated Worker is rehired in Workday
  • You manually reactivate the deactivated Okta user in Okta
  • Okta imports and links the rehired Worker with the reactivated Okta user

Prerequisites

Before you configure provisioning in Okta, ensure that these requirements are met:

• Add a Workday app instance and configure SSO
• Create an integration system user in Workday
• Grant permissions to an integration system user

Add a Workday app instance and configure SSO

You already added a Workday app instance in Okta and configured SSO. See How to Configure SAML 2.0 for Workday.

For general information about applications and adding applications, see Add existing app integrations.

Create an integration system user in Workday

Okta accesses the Workday APIs with a special type of Workday user known as an integration system user. To create one, enter create integration system user in the search box, and then click Create Integration System User in the search results. Follow the directions to create a username and password.

Select Do Not Allow UI Sessions to not allow signing in to Workday with the integration system password.

Grant permissions to an integration system user

Grant the integration system user the necessary permissions to access the web services needed for the Okta Workday integration through Workday Security Groups.

1. To create a Security Group, enter create security group in the search box, and then click Create Security Group in the search results.
2. Select Integration System Security Group (Constrained) or Integration System Security Group (Unconstrained) from the Type of Tenanted Security Group dropdown list.
3. Enter a name for the group, and then click OK.
4. Add your integration system user to the list under Integration System Users.

   To edit this group in the future, enter its name in the search box.

5. If you are using a constrained security group, select which organizations should be applied to it.
6. Choose whether to apply access rights to only the current organization or the current organization and all its subordinates.
7. Click OK, and then click Done.
8. Enter view security group in the search box, and then click the View Security Group report in the search results.
9. Search for and select your security group, and then click OK.
10. From the Actions (...) menu, choose Security GroupMaintain Domain Permissions for Security Group.
11. Grant the following business domain security policy permissions to your security group:
    • External Account Provisioning (permissions: Get and Put)
    • Person Data: Work Contact Information (permissions: Get and Put)
    • Worker Data: Public Worker Reports (permissions: Get and Put)
    • Worker Data: Current Staffing Information (permissions: Get)
    • Worker Data: All Positions (permissions: Get)
    • Worker Data: Business Title on Worker Profile (permissions: Get)
    • Manage: Location (permissions: Get) (If unavailable, use Worker Data: Manage Locations instead.)
12. If you're creating a constrained security group, grant the following business domain security policy permission to your group:
    • Worker Data: Workers (permissions: Get)

13. Click OK to update the domain permissions for your security group, and then click Done.

    Verify with Workday to ensure that all required permissions are configured for the security group.

14. If you're creating a constrained security group, all users should be removed from Worker Data: Workers.
15. Workday might alert you to activate the security policy changes. If you don't activate the changes, the integration user account isn't granted the necessary permissions. Do the following to activate the changes:
1. Search for Activate Pending Security Policy Changes, and then click the resulting task.
2. Enter a comment (required), and then click OK.
3. Verify the changes that need to be activated.

Procedures

• Configure Workday provisioning
• Enable Workday provisioning features in Okta
• Manage Workday Provisioning Groups
• Map Attributes
• Custom expressions
• Workday custom attributes
• Workday Field Override Service

Configure Workday provisioning

To set up the API integration, go to the Okta Provisioning tab in your Workday instance:

Select Enable API Integration, and then configure the other fields, as required.

Configure values for API Username, API Password, and WebServices Endpoint. The remaining settings are optional.

• API Username: The format is [integration system username]@[tenant]. For example: wd_integration@oktademo. Find the tenant name in your Workday URL.
• API Password: The password for the integration system user.
• WebServices Endpoint: Find the tenant name in your Workday URL. To obtain the web services endpoint, look up the WSDL of any of the web services in your org:
  1. Search for public web services.
  2. Under Reports, select Public Web Services.
  3. From the Public Web Services list, select a service, open its dropdown menu, and then select Web ServiceView WSDL. This displays the full WSDL in a separate window.
  4. Search the WSDL page for soapbind:address to see the web services endpoint corresponding to the web service that you chose.
  5. For the Okta configuration, you only need the URL up to the tenant name. For example, if the value in the WSDL window is https://implcc.workday.com/ccx/service/okta_pt1/Human_Resources/v19, then enter https://impl-cc.workday.com/ccx/service/okta_pt1.
• Integration System Id (optional): See Workday Custom Attributes.
• Department Field (optional): This value determines which worker attribute to use for the department attribute of the user in Okta. By default, the value is Business Unit.
• Pre-Start Interval (optional): This value determines how many days before the hire date you should have the user imported and activated in Okta. See Pre-Start Interval Details.
• Sync Personal Phones (optional): With this option, Okta can use personal phone numbers accessed from Workday if work phone numbers are otherwise unavailable.
• Only Import Workers with Workday (optional): This option allows you to import only Workday workers who have Workday accounts and automatically filter out workers who don't. By clicking this option, your next import includes only valid Workday workers.
• Immediate Termination Reasons (optional): If you use the Real Time Sync feature, use this to match the Termination_Subcategory_ID for each termination reason, as identified in the Workday Integration IDs. This entry must be a Regex expression. See Workday Real-Time Sync.
• Deactivate on Last Day of Work (optional): With this option, users are deactivated based on the last day of work instead of the termination date. The user deactivation takes place when their Last Day of Work matches the current date.
• Timezone aware terminations (optional): With this option, users are deactivated based on the current time in their time zone or location. See Timezone aware terminations.

Enable Workday provisioning features in Okta

Select To Okta in the left panel, enable Profile Source, and set up import rules:

• Scheduled Imports
• Workday as Profile Source
• Pre-Start Interval Details

Scheduled Imports

The User Import provisioning feature is automatically enabled when provisioning is enabled. Edit the settings for this feature as required.

For the Workday-driven IT Provisioning scenario, Okta recommends setting up scheduled import and automatic confirmation so that worker lifecycle events in Workday are periodically propagated to Okta without manual intervention. The number of workers in Workday can slow the import, so don't schedule them too frequently.

The Workday integration supports incremental imports as part of Scheduled Imports. For details, see Incremental imports.

A recommended best practice is to first import your users manually. After doing this, schedule your imports based on the results of your manual import. If the import takes too long, adjust the schedule.

Workday as Profile Source

Enable Workday as a Profile Source in the Workday-driven IT provisioning scenario so that Workday manages the Okta users. Make sure that Workday is listed as the highest priority Profile Source, specifically above the Active Directory (AD) instance where it creates users.

Pre-Start Interval Details

The Pre-Start Interval is an optional field for early provisioning of Workday users. It allows you to onboard a user account into Okta before the official Worker/Employee Date (the employee's actual start date). The interval shows how many days before a Workday user's Worker/Employee Date Okta evaluates the user for early import. If the feature is enabled, Okta evaluates the Workday PreHire Date. If it falls within the set interval, Okta imports the user.

For example, if you set the Pre-Start Interval in Okta to 7 days, and the PreHire Date of a Workday account is set to 7 days before the Worker/Employee Date, Okta imports the account. In this same scenario, if the PreHire Date is greater than the 7 day interval configured in Okta, Okta doesn't consider it for import until the beginning of the window defined by the Pre-Start Interval.

Note the following points:

• If the Pre-Start Interval is non-zero, future-dated Workday user updates are imported ahead of time by the number of days specified. For example, suppose you have a Workday provisioning group membership change scheduled with an effective date of two days in the future. If the Pre-Start Interval value is set to three, this change is reflected in Okta immediately after the next import.
• The Pre-Start Interval is ignored for termination date and attribute values imported through Custom Reports. You may need to set a Pre-Start Interval for new hires, but don't want other updates to occur ahead of time. To accomplish this, create and import attributes from Custom Reports into Okta instead of using the base Workday profile attributes in Okta. You can also use group membership rules based on the Custom Report attributes for group assignment in Okta.
• You must have Profile Sourcing enabled to use the Pre-Start Interval option.
• Set the interval to the time you need foronboarding.
• The interval defines when a user is eligible to be imported ahead of their actual start date. It doesn't define when to import the user.

Manage Workday Provisioning Groups

With Workday Provisioning Groups, you can import workers into Okta in an organized way. Like Active Directory Security Groups, you can see imported Workday Provisioning Groupsunder DirectoryGroups. Use these groups like any other Okta group: for app assignments and multi­factor authentication (MFA) policy assignments. You can also use the groups to drive provisioning into Active Directory and other applications. Create provisioning groups manually inside Workday. After you create them, the groups and associated memberships become part of the import into Okta.

• Grant Provisioning Group Admin privileges to a Workday Administrator
• Assign Workday Workers to Provisioning Groups
• Provision Users to Active Directory with Provisioning Groups
• Change Provisioning Groups
• Considerations

Grant Provisioning Group Admin privileges to a Workday Administrator

Before a Workday admin can manage Provisioning Groups, ensure that they have the correct privileges. If you search forprovisioning groups and don't see options to create, delete, or edit Provisioning Groups, then the admin doesn't have the required privileges.

To add Provisioning Group access, follow these steps:

1. Enter domain security in the Search bar and select Domain Security Policies for Functional Area.
2. Enter System, and then click OK.
3. In the left pane, scroll down and expand the Security Administration folder. Then click Provisioning Group Administration.
4. Next to Provisioning Group Administration in the right pane, click the ellipsis to reveal a dropdown and select Domain Security Policy.
   • If the second item is Enable, the policy is currently disabled. To enable it, click Enable and confirm your selection.
   • If the second item is Disable, the policy is currently enabled. Move to the next step.
5. Under the Report/Task Permissions list, ensure that the admin is a member of one of the Security Groups with view and modify permissions. If not, click the dropdown menu next to Domain Security Policy, and then select Domain Security PolicyEdit Permissions to add the right Security Group to the list. Ensure that both view and modify permissions are configured.

Assign Workday Workers to Provisioning Groups

Workday workers can be manually assigned to provisioning groups within Workday; however, provisioning groups are most effective when configured to have automated assignments based on conditional rules as defined in a business process within Workday. Because it involves modifying a business process inside Workday, a Workday HR administrator should perform this step. Contact Workday Support for more details.

Provision Users to Active Directory with Provisioning Groups

Okta can automate the creation, update, and deactivation of users from Workday to Active Directory (AD). Okta drives provisioning through Workday provisioning groups. In short, a Workday provisioning group is tied to one (or more) AD organization unit (OU) within Okta. When a user is created in Workday and assigned to a properly configured provisioning group, Okta imports that user from Workday and creates a user in AD under the corresponding OU.

Users can also be deactivated based on the time zone of their location, see Timezone aware terminations for more details.

To provision users to AD with provisioning groups:

1. Sign in to Okta.
2. Find the desired Workday provisioning group under DirectoryGroups.
3. Click the group.
4. Click Manage Directories.
5. Select the AD domains to associate with the Workday provisioning group.
6. Select the AD OU within which you wish to provision accounts.
7. Click Done.
8. In the Okta AD Settings tab, enable Provision new Active Directory accounts from Okta.

Change Provisioning Groups

Adding an existing Worker to a different provisioning group in Workday results in a membership change in the associated group in Okta. However, the OU location of the associated AD user does not change. This is because Okta only adds AD users to a particular OU during AD user creation, updates do not apply.

Considerations

Group Addition: Newly created Workday groups are synchronized into Okta only in the following scenarios:

• Full Import: This brings in any new Workday Provisioning groups and creates them in Okta.
• Incremental Import: This brings in any new Workday Provisioning groups and creates them in Okta
• RTS: The creation of a Workday Provisioning group alone doesn't trigger an RTS event to create the group in Okta. However, after the Workday Provisioning groups have been created in Workday, any other RTS event that is triggered will also include the group information and create the new groups in Okta.

Group Removal: Groups deleted from Workday are removed from Okta only during a full import:

• Full Import: This removes any group from Okta that is linked to a Workday group that no longer exists.
• Incremental imports and RTS do NOT remove deleted Workday groups from Okta.

Group Name Changes: The following behaviors occur in Okta when a group name is changed from within Workday.

• Any RTS event picks up the Workday group name change, and writes the new name into Okta as a new and separate group within Okta.
• With RTS, when any user who's a member of the group is updated, they're removed from the original group in Okta and added to the newly created Okta group. If that user got application assignments from the original group (with the old name), they will lose them.
• Any new user who is added to the Workday Provisioning group (with the new name), causes the group to be written to Okta. However, this new user won't be assigned to an application or removed from one, because the group (with the new name) in Okta has never had an application associated.
• If an incremental import runs, the results are the same as the preceding RTS scenarios. The group (with the old name) isn't removed, but users who have been updated since the last import are moved from the group (with the old name) to group (with the new name). This results in application unassignment or deprovisioning.
• If a full import runs, the group (with the old name) is removed, causing everyone in it to be unassigned or deprovisioned from any associated apps accordingly. The group (with the new name) is imported, and associated users are added to it. No applications are associated.

If you have to rename a group in Workday, create a new group instead.

Workday Group name changes can result in unwanted behavior downstream in Okta. To work around this issue, create a group with the desired name in Workday and assign users to it. Wait for an import or an RTS job to create the new group in Okta.

After the newly created group is brought into Okta, set it up the same as the group that you wanted to rename. When the user memberships, group rules, and application assignments are the same for both groups, you can remove the old group (with the original name) from Workday and update Okta by running a full import.

Since all users, rules, and application assignments have been duplicated to the new group, no one should lose access to any applications or assignments.

Map Attributes

• Map Attributes from Workday to an Okta User Profile
• Map attributes to an AD user profile

Map Attributes from Workday to an Okta User Profile

As shown in the Universal Directory (UD) Profile Editor, the base profile that Okta imports from Workday consists of 20 attributes. Some of the attribute mappings from the Workday user to the Okta user exist by default, but others need to be created manually. The table below contains the recommended mappings for typical use cases.

When Workday is configured to write to AD (and UD is enabled), the Okta admin must manually map some attributes between the Workday app user profile and the Okta user profile and the Okta user profile and the AD user profile. This allows attributes to flow from Workday to Okta and then to AD.

Map attributes to an AD user profile

Workday as a Source typically involves creating AD users. Some of the attribute mappings from Okta user to AD user exist by default, but others need to be created manually. The following table contains the recommended mappings for typical use cases.

Custom expressions

UD supports the use of custom expressions in profile mappings to transform attributes. As shown in the table above, custom expressions are used to populate the SAM Account Name and Manager (UPN).

The Manager (UPN) attribute is important for linking managers in AD. This is the full custom expression for Manager (UPN):

hasWorkdayUser()?(findWorkdayUser().managerUserName + "@" + target_app.namingContext):null

The custom expression triggers this action: If the Workday profile exists for this Okta user, then find the managerUserName attribute of the Workday profile that was imported into Okta and append @[AD domain] to populate the Manager (UPN) attribute.

Okta uses the Manager (UPN) attribute to find the Active Directory user in AD that is this Okta user's manager, and links the two AD users together. This custom expression can be modified to construct the Manager (UPN) attribute differently to suit special AD environments.

Two other situations can result in additional custom expressions appearing in the Provision to AD profile mappings. The first is when UD is turned on for a pre-existing Workday as a Source deployment. The second is when the Workday integration is added to Okta first, before AD is added. In both cases, the Workday attributes of Business Title, Location, Supervisory Organization, Business Unit, and Employee ID are mapped directly to their corresponding AD attributes directly through custom expressions.

Workday custom attributes

Custom attributes can be imported by using Field Overrides, which are described in the following section.

In older instances, a custom report endpoint could be used to import attributes. This functionality has been deprecated. Existing custom report configurations aren't affected, but new app instances must use field overrides. If you have an instance that uses custom reports to import attributes from Workday, see Import with custom reports.

Workday Field Override Service

Workday's Field Override Service is a method to pull custom attribute information from Workday.

Using the Field Override Service simplifies the import process and improves performance over past methods, such as using custom reports.

• Configuration
• Field Override property types
• Configure Workday to use field overrides in Okta

Configuration

To use Field Overrides, Workday administrators must create a new Field Override Integration System within Workday, add the desired custom attributes to it, and configure Okta to use this Integration System when fetching worker data.

To create a Field Override Integration:

1. Sign in to your Workday account as an admin, search for Integration System in the search bar, and then click Create Integration System.
2. Enter the following:
   • System Name: Enter a name for your system integration.
   • Comment: Optionally add a comment.
   • Template: Select Core Connector: Worker from the New using template dropdown menu.
3. Click OK.
4. From the list of results, select Core Connector: Worker, then click OK.
5. On the Configure Integration Services page, scroll down to the Custom Integration Services section, and click + (plus).
6. Click Create.
7. Select Create Integration Field Override Service from the list of services.
8. Enter a Name for the Field Override Service, and select Worker as the Business Object.

   Property types are based on the property name. Every field is treated as a string unless you specify its type using a prefix. See Field Override property types for more information about property types and naming conventions.

9. Click OK to finish creating your integration system.
10. Click OK to return to the View Integration System page.
11. Configure the field mappings for your system. Go to ActionsIntegration SystemConfigure Integration Field Overrides.
12. Select your Integration Service from the list on the left, and configure the mappings for your fields. Search for any desired fields and ensure that the property types match.
13. When you're done mapping the properties, click OK and then click Done.
14. Search for your integration system in Workday, then go to ActionsIntegration IDsView IDs.
15. Copy and save the value of Integration_System_ID. You need this value to set up and update your provisioning settings.

Field Override property types

With field overrides, there's no way to get attribute types from the setup of the integration system. This means that all custom properties are treated as strings. If you want to have a custom property be treated as another type by Okta (for example, Boolean or number), you need to add a prefix to the property name when you configure its mapping in the integration system. Okta detects this prefix, transforms it to a property type, and then removes the prefix (that is, the prefix doesn't appear in the Okta Profile Editor).

To make Okta honor types from a field override, you need to name the property with property type and property name separated by colon as follows: <property_type>:<property_name>. For example, string:homePhoneNumber.

The following types are supported:

• string
• boolean
• integer
• number
• decimal

The following table demonstrates how the property names are transformed.

Configure Workday to use field overrides in Okta

1. In the Admin Console, go to ApplicationsApplications.
2. Search for and select your Workday app instance.
3. Go to ProvisioningIntegration. You will see the new configuration property: Integration System Id.
4. Click Edit. Paste the Integration_System_ID value that you copied earlier into Integration System Id. Click Save.

5. In the Admin Console, go to DirectoryProfile Editor.

6. Find and select your Workday app instance.

7. Click Add Attribute. Check if the new properties from your Integration System appear in the list of attributes. If they're missing, click Refresh Attribute List and select the attributes that you want to add. Click Save.

8. Click Mappings in the Profile Editor and map the attributes.

Known limitations

• Okta does not display Arabic characters imported from Workday correctly.
• Removing a custom attribute in Workday, then importing into Okta, does not erase the custom attribute value that was previously imported.
• If you receive the following error message during profile updates (phone device values) to Workday:

Then your Workday tenant is configured with custom Phone_Device_Type_Id values. You need to reset them to use the Workday-configured factory default values as follows:

Name	Value
MOBILE	Mobile
FAX	Fax
TELEPHONE	Telephone
PAGER	Pager

Features

Contractor to Full-Time Employee Conversion

• In order to be able to use Workday Contractor to Full-Time Employee conversion support, you must modify your Workday tenant setup to configure Universal ID for workers first. Once configured, Universal ID only applies to newly created workers of the tenant. In order to back port it to existing workers you must manually update these Workday profiles usingWorkday's API. Without a Universal ID, Okta will be unable to detect that a contractor has been converted to full-time. This may lead to duplicate workers in some cases.
• Mapping Universal ID from Workday to Okta is optional and is not required for this feature to work.

Universal ID

What is Universal ID?

On the Workday side, Contractor and Full-Time workers are two separate entities with two separate Workday IDs. Universal ID configuration allows you to link these together by setting the same secondary ID for both (Universal ID).

Why is Universal ID needed:

If your Workday Provisioning integration is configured with pre-hire interval, but Universal ID isn't configured, Okta pulls in the Contractor worker and the future Full-Time user (pre-hire). As a result, Okta creates a duplicate entry in the Import tab. This happens because those two workers in Workday have different Workday IDs, and Okta can't detect that they are the same user.

How does it work:

When Universal ID is configured in Workday, as part of the Contractor to Full-Time conversion feature, Okta detects if there are any workers coming in as pre-hires that have the same Universal ID as the currently active and existing workers. If there are such pre-hires, we filter them out while the currently existing workers with the same Universal ID are present.

When the Contractor worker is deactivated and the import from Workday is running, a Full-Time user will be the one we select, as the Contractor is no longer an option.

Upon conversion, the Okta user is deactivated and then reactivated. This is expected behavior, from Okta's perspective, the Contractor worker is terminated and new Full-Time worker is hired.

This was implemented to support cases when a Contractor worker is terminated, but the hire date of the Full-Time user is not the same day.

For example: A Contractor was converted to Full-Time, but they wanted to take a week off before the start date as Full-Time worker. The Full-Time worker will not be imported until their actual start date.

For the conversion to work automatically, you need to enable the minimum set of configuration options on ProvisioningTo Okta tab, as follows:

User Creation & Matching:

Auto-confirm exact matches

Auto-confirm new users

Profile & Lifecycle Sourcing:

Reactivate suspended Okta users (optional, depends on your setup)

Reactivate deactivated Okta user

There might be a gap between Contractor user deactivation and Full-Time user reactivation. This is usually caused by the timezone difference between Workday's termination/hire dates for user and the time zone that Workday tenant is operating. Currently, Okta supports only Time Zone-Aware terminations, but doesn't consider the time zone when importing new hires.

To learn how to configure Universal ID for your Workday tenant (note that you need a Workday Community account to access these articles) see:

• Create ID Definitions and Sequence Generators.
• Set Up Workday IDs.

Deactivation

During imports (Scheduled, RTS, and Incremental), Okta performs a query to determine if any workers have been terminated in the last 24 hours or will be terminated within the next 24 hours. Workers that fall into this category will have the following rules applied to determine:

• Immediate deactivation reasons: If the termination reason of the worker matches one of the configured immediate termination reasons within Okta, the worker is deactivated immediately.

• Timezone aware terminations: If the termination reasons are not matched, then the termination/last day worked date of the worker are compared to the current time. Okta relies on the timezone provided by Workday within the termination date when determining if the deactivation time has come to pass. Typically Workday returns the termination date as midnight PST. If the current time is after that date, then the worker is deactivated.

• Workers with a future termination date and a matching immediate termination reason will be terminated one day early. For example, if termination Date is 2022/10/22 and current Date is 2022/10/21, and the Immediate Termination reason matches; the user will be terminated as part of the import on 2022/10/21 - one day prior to their termination date.

• Workers still only terminate at midnight UTC unless Time Zone Aware Deactivation is enabled.

  • See Timezone aware terminations for a workaround.

Immediate deactivation reasons

By default, Okta waits until the end of the day to process a terminated Worker in Workday. Such actions might include un-assigning them from the Workday app or deactivating them. However, if the termination reasons for the Worker match those specified in Immediate Termination Reasons and the termination date is set to the current date, Okta takes action immediately after receiving the event from Workday.

Configure Immediate Deactivation Reasons

1. In Okta, select the  Provisioning tab for the Workday app.

2. Enter some immediate termination reasons with the required termination subcategory, as described in Workday. You can list the termination subcategories in Workday by searching for Integration IDs, and then searching for and selecting the Termination Subcategory business object. A termination reason is the combination of its termination subcategory and its corresponding ID (for example, Terminate_Employee_Involuntary_RIF). When you define these immediate deactivation reasons, you can also use regular expressions (regex) to specify them.

   You can use the OR (|) operator to list multiple deactivation reasons. The following regex defines multiple possible immediate deactivation reasons. Here, all deactivated workers with any of the following termination reasons are immediately unassigned from the Workday app and deactivated in Okta:

   Terminate_Employee_Voluntary_DissatisfiedPay|Terminate_Employee_Involuntary_Harassment|Terminate_EmployeeImmediateTerm_ImmediateTerm|Terminate_Employee_Voluntary_Commute

   Use ^.*<TerminationReason>$ to match termination reasons that end with the specified expression. For example, the following expression matches any reasons that end with DissatisfiedPay:

   ^.*DissatisfiedPay$

   Use ^<TerminationReason>.* to match termination reasons that start with the specified expression. For example, the following expression matches any reasons that begin with Terminate_Employee_Voluntary:

   ^Terminate_Employee_Voluntary.*

   You use a combination of these methods, as demonstrated by the following example:

   ^.*DissatisfiedPay$|^.*Involuntary_Harassment$|^.*ImmediateTerm$|^Terminate_Employee_Voluntary.*

   Be careful when creating these expressions and make sure they're strictly applied to the correct workers and not anyone else.

Notes:

• There can be no default value for this text box.

• Select termination reasons in Workday under Reason and Secondary Reasons:

The following chart illustrates various outcomes based on termination variables:

Timezone aware terminations

The date of a worker's termination may not align with a standard time of day to deactivate their account. The Workday integration supports deactivating a worker based on their time zone as defined in Workday.

Enable this feature by selecting Timezone aware terminations on the Provisioning tab. Your security group must have permission to manage locations. See Grant permissions to an integration system user.

There's no support for worker reactivation based on time zone.

The Termination Date or Last Day of Work for a worker determines their scheduled termination. Okta detects the location of the worker and processes their scheduled termination, based on the associated time zone of that location. This worker is deactivated on the next scheduled import after midnight in the time zone of that worker.

If the worker has set a preferred time zone in Workday, then that takes precedence over their detected location's time zone. The order of precedence for determining a worker's time zone is as follows:

1. Preferred time zone of the worker
2. Time zone of the worker's location
3. Pacific Standard Time (PST)

For example, Cathy is based in Sydney, Australia, whose time zone in Workday is GMT+10.

Cathy is scheduled to be terminated on July 4. If Timezone aware terminations isn't enabled, Cathy's termination is processed on the next import after midnight UTC. This is because all deactivations are fixed on the UTC time zone (GMT+0). If Timezone aware terminations is enabled, Cathy is deactivated in Okta on the next import after midnight in Sydney time (GMT+10). Effectively, Cathy is deactivated 10 hours before she would have been deactivated in the past.

Related topics

Incremental imports

Workday Real-Time Sync

Workday Email and Phone writeback

Configure Workday writeback for home and work contacts

Import with custom reports

Best practices and FAQ