Inbound Provisioning from Workday

You can provision user data from specified external systems (for example, a web-based Human Capital Management system) to supported directory services using inbound provisioning. The external system is considered the data source, while a directory source known to CyberArk Identity is the target. The following table indicates support for data sources and targets.

Source Target
Workday

AD

CyberArk Cloud Directory

You can define synchronization schedules to synchronize user data from those systems. It's also possible to edit certain user attributes in AD and write those values back to the external systems.

Before you start configuring inbound provisioning to AD targets, confirm that you have done the following:

  • Installed the CyberArk Identity Connector.

    The CyberArk Identity Connector is required to provision users to AD target directories.

    See Install the CyberArk Identity Connector.

  • Stored the domain administrator account to CyberArk Identity.

    This step is only required if the CyberArk Identity Connector is not run by a domain administrator. See Manage domain administrative accounts.

  • Populated the relevant user data in your data source.

Enable access to Workday APIs

Provisioning users from Workday to a supported target directory requires API access to the related worker data.

Perform the steps in this section in the Workday Workbench.

To configure Workday to allow access to worker data APIs

Step 1: Create an integration system user.

The integration system user you create here must have staffing and human resources web services privilege. This privilege is necessary for CyberArk Identity to call the Workday API to pull the user data. You will need the integration system user name and password when adding the Workday source in the Admin Portal.

  1. In the Workday Workbench, enter “create user” in the search box, and then click the Create Integration System User link.

  2. Provide a user name and password for a new Integration System User.

    Make note of the user name and password because you will need this information to configure the source in the Admin Portal.

  3. Leave the Require New Password at Next Sign In option unchecked, because this user will be logging on programmatically.

  4. Leave the Session Timeout Minutes with its default value of 0, which will prevent the user’s sessions from timing out prematurely.

  5. Click OK.

Step 2: Create a security group and add your integration security user to it.

This procedure helps you to create an unconstrained integration system security group.

  1. Enter “create security group” in the search box, and then click the Create Security Group link.

  2. Select Integration System Security Group—Unconstrained from the Type of Tenanted Security Group drop-down list, to create a security group to which members will be explicitly added.

  3. Enter a name for the security group, then click OK.

    The Edit Integration System Security Group (Unconstrained) page appears.

  4. Add your integration system user in the Integration System Users field, then click OK.

  5. Review the summary of your integration system security group, then click Done.

Step 3: Configure security group options

This procedure allows the systems administrator to grant the new security group permissions for Get operations on the objects secured by the following domain security policies:

  • Manage: Organization Integration

  • External Account Provisioning

  • Worker Data: Public Worker Reports

  • Worker Data: All Positions

  • Worker Data: Current Staffing Information

  • Worker Data: Business Title on Worker Profile

  • Worker Data: Organization Information

  1. Enter “domain security policies” in the search box, then click the Domain Security Policies for Functional Area link.

Step 4: Activate the security policy changes.

  1. Search for "activate security policy", then click Activate Pending Security Policy Changes in the list of results.

  2. Add a comment describing the changes, then click OK.

  3. Review your changes, then select the Confirm option and click OK.

    The View Security Timestamp page appears, showing the results.

Add Workday as a data source

The next step in provisioning users from Workday to a supported target directory is adding Workday as a data source in the Admin Portal.

Perform the steps in this section in the Admin Portal.

To add Workday as a data source

Step 1: Verify your credentials to add Workday as a data source.

  1. Go to Settings > Users > Inbound Provisioning.

  2. Click Add Source (on the Sources tab) to define the Workday service information.

    The Provisioning Source window opens.

  3. Select the source environment type for which you are configuring.

    Environment type Description

    Workday (Integration)

    Select if you are configuring the synchronization or a test environment.

    Workday (Production)

    Select if you are configuring the synchronization for a production environment.
  4. Select the Enable check box to enable the feature.

    You can configure the feature first, then enable it when you are ready.
  5. (Optional) Select the Enable write-back check box to enable the write-back feature.
    The write-back feature allows you to make changes to certain attributes of the user object in AD or the CyberArk Cloud Directory, then sync those changes back to Workday. Select the attributes that you want to sync back to Workday in Define provisioning rules .

    Write-back is currently supported between AD or CyberArk Cloud Directory and Workday.
  6. Enter a Name for this source.

  7. Get the Workday cloud hostname for use in generating the Workday server URL.

    The following are standard procedures, but your steps may differ slightly depending on your Workday customizations.

    1. Log in to Workday as an administrator.

    2. Enter “Public Web Services” into the search box.

    3. Select Public Web Services.

    4. Click Actions > Web Service > View URLs.

    5. Click Workday XML, re-entering your Workday administrator credentials if necessary.

      A new tab opens with a URL similar to https://wd2-impl-services1.workday.com/ccx/service/systemreport2/companyFoo_pt1/Public_Web_Services.

    6. Copy the hostname.

      Refer to the italicized part of the following URL for an example of the hostname.

      https://wd2-impl-services1.workday.com/ccx/service/systemreport2/companyFoo_pt1/Public_Web_Services

  8. Enter the Workday server URL in the specified format into the URL field.

    URL type Format
    Integration https://{host}.workday.com/ccx/service/{workday_tenantid}_pt1
    Production https://{host}.workday.com/ccx/service/{workday_tenantid}

    For example:

    URL type Example
    Integration https://wd-sample-services.workday.com/ccx/service/companyFoo_pt1
    Production https://wd-sample-services.workday.com/ccx/service/companyFoo
  9. Enter the Integration User Name appended with @ and your tenant ID.

    For example, if the integration user name in Workday is techpubs and your tenant ID is fooCompany, then you must enter techpubs@fooCompany here.

  10. Enter the Integration Password.

    This is the password for the integration user.

  11. Click Verify to verify the integration user name and password combination.

Step 2: Configure Sync Settings

Settings on this tab include new hire pre-provisioning and time offsets.

    1. Specify the Enable New Hire Pre-Provisioning options to tell CyberArk Identity to provision a user prior to the user employment start date.

      For example, if you have users starting 2 days after your synchronization action, you can tell CyberArk Identity to synchronize those user data to Active Directory by setting the Interval field to 48 hours. If you do not configure this option, the default value is eight hours.

      The maximum value is 8,760 hours (one year).

    2. Enable Run incremental sync automatically and specify the sync frequency in minutes.

      See Inbound Provisioning from Workday for more sync options.

    3. Specify the time offset between your CyberArk Identity tenant and UTC using the Tenant UTC Offset (minutes) option to prevent delayed or premature user data synchronization.

      Synchronizations are performed based on UTC time. If you need to compensate for time zone differences between your tenant and UTC, specify that offset here.

    4. Enable Do not create new users (update existing user only) if you want the sync job to ONLY update existing user data and NOT create any new users in Active Directory.
    5. Enable Ignore sync cache if you want to sync with the data source regardless of existing user data in Active Directory.

      CyberArk Identity keeps a cache of the data source's user data.

      If systems administrators update user data in Active Directory, then that data is out of sync from the data source. This option allows CyberArk Identity to ignore existing data in Active Directory and sync with the data source.

      Enabling this option makes available the Discard directory identifiers for cached entries. Enable this option if you want CyberArk Identity to discard existing user IDs stored in Active Directory and re-discovers users from UPN or samaaccount name.

  1. Click Save.

    Your configured source appears in the Sources table.

Step 3: (Optional) Configure CyberArk Identity for custom attributes.

On the Report Integration tab, select the Enable Reports Integration option to configure CyberArk Identity for custom attributes.

Before you can configure CyberArk Identity to use custom attributes, you must first create the custom attributes in Workday. See Generate and map custom attributes.

Define provisioning rules

After you've completed the steps in Enable access to Workday APIs and Add Workday as a data source, you can configure provisioning rules.

Define provisioning rules to identify users, map user attributes, and other important provisioning configuration. You can define more than one rule for each source. For example, you might use a single rule if you are provisioning all users from Workday to a single AD OU, or multiple rules if you want logical groupings of users in Workday to have different target AD OUs.

You can mix rules that have different target directories. For example, you could create one rule that provisions full-time employees to AD and another rule that provisions contractors to CyberArk Cloud Directory.

You must first add and configure a source before you can define the rules.

To define provisioning rules for Workday

Step 1: Add a new rule

  1. From Settings > Users > Inbound Provisioning, select Workday and then click Actions > Add Rule.

  2. Enter a Name for this rule.

  3. Select a Provisioning Rule Mode.

    Mode Description
    Active Makes a rule active. Not recommended until you have finished all configurations. You must activate a rule before synchronizing.
    Preview Sets the rule in preview mode. Select this option for a production environment to verify the user mapping between Workday and the target directory before you make the rule Active.
    Inactive Sets the rule as inactive. Recommended until you have finished all configuration steps. You can come back to this option and activate the rule when you are ready.

Step 2: Define the users to which the rule(s) apply

Select the Source Selection Rule to define the users to which these rules apply.

If you are provisioning all Workday users (by selecting All Users from the drop-down list) to one Organizational Unit (OU) in AD, then you do not need to perform the following sub-steps.

If you are provisioning specific groups of users to specific OUs in AD, then do the following:

  1. Click Add to select the specific group.

  2. Select a source group from the drop-down list and click the associated Add button.

  3. Repeat these sub-steps until you have added all relevant groups, then click Next.

Step 3: Define the target directory that you want to provision to.

  1. Select the AD domain from the Target drop-down menu.
  2. Select the relevant forest from the Target drop-down menu.

    When you select the forest, CyberArk Identity looks for the stored domain administrator account and shows a warning message if one is not available (unless the CyberArk Identity Connector is run by a domain administrator). See Manage domain administrative accounts.

  3. Select the relevant Domain.

  4. Select the relevant Domain Controller.

  5. Select the relevant OU or expand an OU and select the relevant groups in the Target OU area to which you want user accounts provisioned, then click Next.

Select CyberArk Cloud Directory ({CyberArk_tenantID}) from the Target drop-down menu, then click Next.

Step 4: Map the attributes

  1. Review the required and automatically mapped attributes.

    You can delete optional attributes. You also have the option to map additional attributes.

  2. (Optional) Click Add and select the Target Attribute (attribute name in Active Directory or CyberArk Cloud Directory) to add more attributes.

    • If there is only one match in Workday, then no corresponding source attributes are displayed; click Add again to add the attribute and view the mapping in the table.
    • If more than one source attribute can be mapped to the selected target attribute, then select a corresponding Source Attribute (attribute name in the data source) from the drop-down list; click Add again to add the attribute and view the mapping in the table.

      Continue mapping attributes until all necessary attributes are mapped.

    • You can edit the attribute in the Target Attribute column to map custom AD attributes to source attributes.

      For example, the following image illustrates a custom AD attribute CustomAdAttribute to the source attribute WorkdayUser.WorkEmail.

      If the custom AD attribute was entered incorrectly in the Target Attribute column, the error The given key was not present in the dictionary appears in the job report.

Step 5: (Optional) Select the sync direction for each attribute.

This column is only available if you enabled the write-back feature . In addition, you can only change the sync direction for supported attributes.

  • You can only change the sync direction for supported attributes.

  • There must be a 1:1 mapping of source and target attributes.

  • The target attributes C, Co, CountryCode, L, PostalCode, St, StreetAddress must have the same sync direction.

    If one is set to Target to Source, all of them need to be set to Target to Source.

  • Syncing the St (State) AD attribute to Workday is only supported when it is mapped to WorkdayUser.WorkRegionCode, not WorkdayUser.WorkRegion.

  • The origin attribute has priority in the event of a conflict.

    For example, if the direction for an attribute mapping is set to Target to Source, the attribute value in the Target has priority.

  • Deleting an attribute value in AD does not delete the value in the data source, even if the sync direction is Target to Source.

  • Adding or deleting user objects in AD does not add or delete user records in the data source.

    Deleted objects in AD with matching records in the source will be recreated at the next sync from the source. Objects added to AD will not be deleted at the next sync.

Step 6: Configure additional provisioning rule options

  1. Click Next to configure additional provisioning rule options.

  2. (Optional) Configure the following attribute related options.

    Option Description
    Set user’s manager attribute If enabled, users’ manager attributes in Workday are synchronized to the target directory.
    Disable user in {target_directory} if worker employment status is terminated If enabled, users with the terminated employment status in Workday are automatically disabled in the target directory source.
  3. Specify the Password Type for new user accounts.

    If you select Static Password from the drop-down list, then the system uses the same password for all new users.

    Make sure the password meets the complexity requirements set via policy for the target groups or roles. If the password does not meet the complexity requirements, you will see the error UnableToSetPassword or Password does not meet policy requirements in the sync report.

    Provide the following information:

    Field/Option Description
    Password Specify the password to be used for all users.
    Require password change at next login If enabled, new users will be required to change their passwords after the initial log in. Disabled by default.

    If you select Generated Password from the drop-down list, then the system randomly generates different passwords for each new user.

    Provide the following information:

    Field/Option Description
    Require password change at next login If enabled, new users will be required to change their passwords after the initial log in. Disabled by default.
    Delivery options

    Select the email address to which you want the auto-generated password sent.

    This is to help in your new employee onboarding process. When new users are created in Active Directory, an email will be sent to the specified address with the credentials for those users.

    • Send password to email address

      Enter the email address to which you want the password sent.

    • Send password to user’s manager

      Sends the password to the manager’s email address. Ensure that you have the email address specified in the data source.

    • Send password to user’s personal email

      Sends the password to the user’s personal email address. Ensure that you have the email address specified in the data source.

      If you have more than one option selected, the password is sent to all the selected email addresses.

Step 7: (Optional ) Map users to AD groups or CyberArk Cloud Directory Roles.

  1. Enable the Add users to groups check box.

  2. Select the Add button within the Active Directory Group Options area. The Add Active Directory Group window opens.

  3. Confirm that the appropriate source is selected.

  4. (Optional for AD) Select Assign user to an OU upon termination if you want to specify the organizational unit (OU) in which terminated users will be placed.

    If you do not enable this check box, then terminated users will remain in the current OU.

    Selecting this option requires enabling the Disable user in AD if worker employment status is terminated option. Both options must be enabled to successfully assign users to an OU upon termination.

    Start entering the group name into the Search box to find the group.

  5. Select the group and click Add.

  6. Select Re-evaluate Group Memberships to remove users satisfying the inbound provisioning rule from previous group assignments and add the users only to the groups specified.

    For example, you might have separate inbound provisioning rules configured to provision users in a sales source group to a sales AD group, and a marketing source group to a marketing AD group. If a user moves from the sales organization to the marketing organization, the user should be removed from the AD sales group so that the user's access is appropriate for just marketing, not marketing and sales. Selecting Re-evaluate Group Memberships would remove the user from the sales group when the inbound provisioning rule for the marketing source group runs.

    Re-evaluate Group Memberships removes users from all previous AD group assignments, regardless of whether the assignment was from inbound provisioning or configured manually. This might have unintended consequences for application access, authentication policies, device management, etc. Verify that your users only need the access granted to the AD groups specified in the inbound provisioning rule.
  1. Enable the Add users to roles check box.

  2. Select the Add button within the CyberArk Cloud Role Options area. The Add Role window opens.

  3. Confirm that the appropriate source is selected.

  4. Start entering the role name into the Search box to find the role.

  5. Select the role and click Add.

  6. Select Re-evaluate Role Memberships to remove users satisfying the inbound provisioning rule from previous role assignments and add the users only to the roles specified.

    For example, you might have separate inbound provisioning rules configured to provision users in a sales source group to a sales role, and a marketing source group to a marketing role. If a user moves from the sales organization to the marketing organization, the user should be removed from the sales role so that the user's access is appropriate for just marketing, not marketing and sales. Selecting Re-evaluate Role Memberships would remove the user from the sales role when the inbound provisioning rule for the marketing source group runs.

    Re-evaluate Role Memberships removes users from all previous role assignments, regardless of whether the assignment was from inbound provisioning or configured manually. This might have unintended consequences for application access, authentication policies, device management, etc. Verify that your users only need the access granted to the roles specified in the inbound provisioning rule.

Step 8: Map Provisioning Groups to Active Directory Groups or CyberArk Cloud Directory Roles.

Provisioning Groups can be used to collect users across different supervisory organizations in Workday and map them to specific AD Groups or CyberArk Cloud Directory Roles.

  1. Enable the Map Workday Provisioning Groups to Active Directory Groups check box.

  2. Select the associated Add button.

  3. Select the Provisioning Group Name from the drop-down list.

  4. Confirm that the appropriate source is selected.

  5. Start entering the group name into the Search box to find the group.

  6. Select the group and click Add.

  1. Enable the Map Workday Provisioning Groups to CyberArk Cloud Directory Roles check box.

  2. Select the associated Add button.

  3. Select the Provisioning Group Name from the drop-down list.

  4. Confirm that the appropriate source is selected.

  5. Start entering the group name into the Search box to find the group.

  6. Select the group and click Add.

Step 9: (Optional for AD) Select Assign user to an OU upon termination if you want to specify the organizational unit (OU) in which terminated users will be placed.

If you do not enable this check box, then terminated users will remain in the current OU.

Selecting this option requires enabling the Disable user in AD if worker employment status is terminated option. Both options must be enabled to successfully assign users to an OU upon termination.

Step 10: Finalize the rule(s)

  1. Click Save to save the rule configuration.

    The provisioning rule has been configured and the rule is listed in the Sources table.

  2. Click the rule to change its status if you did not already set the rule to Active.

  3. Click Save.

  4. Define additional provisioning rules as needed.

    You can define more than one rule for each source.

Generate and map custom attributes

If you are using custom attributes in Workday, you can use JavaScript to map them to appropriate attributes in the target directory. You can test how the script works with a sample user. The scripting interface also provides a listing of the attributes available in both Workday and the target directory service.

Editing the provisioning script is for advanced users who understand JavaScript. If you edit the provisioning script, it’s possible that the script will not function correctly and your users won’t be synchronized successfully.

In most cases, Workday automatically creates the necessary attributes for your user; however, you might need to create custom attributes. In those instances, you can use Workday to generate custom attributes and use the Admin Portal to map them to the target directory. For example, the default attribute to create a Common Name in AD is the Workday User. However, Workday does not generate an alphabetic Workday User attribute for contingent workers (contract or part-time employees). Contingent workers are only issued a numerical ID. To remedy this, you may want to create a custom attribute so that all workers are given human-friendly names. You can do this by creating a custom report in Workday with custom attributes and writing a script to map those attributes to the proper Active Directory attributes.

In the event of a conflict between the attribute mapping table and the script, the script has priority.

Step 1: Generate custom attributes

You create custom attributes by creating an advanced custom report. After you create it, the report is automatically run with each data synchronization between Workday and the target directory.

  1. Log in to Workday.

  2. Click Reporting & Analytics > Create Custom Report.

  3. Provide the necessary information.

    • Report Type - Select Advanced to get access from the web services.

    • Data Source - Select All > All Active and Terminated Workers.

    • Enable As Web Service - enable the check box.

  4. Click OK.

    The Edit Custom Report page opens.

  5. In the Field text box, type workday_id, then press Enter.

    You must enter workday_id for the mapping and scripting to work. The text resolves to Workday ID.

  6. (Optional) Click the + icon to enter additional custom fields.

  7. Click OK > Done.

Step 2: Copy the XSD and JSON URLs for use in the Admin Portal.

Adding these URLs into the Admin Portal connects CyberArk Identity to the custom reports.

  1. Hover over the report name associated with the Report Definition field and select the dotted icon next to the name.
    The Actions page slides open.

  2. Select Web Service > View URLs.

  3. Copy the XSD (within the Workday XML area) and JSON URLs by right clicking each and selecting Copy URL.

Step 3: Add the XSD and JSON URLs to the provisioning source.

CyberArk Identity needs to communicate with the custom report to get the attribute values. You enable this communication by adding the report XSD and JSON URLs to the Admin Portal provisioning source.

  1. Log in to the Admin Portal.

  2. Click Settings > Users > Inbound Provisioning.

  3. Click the relevant source to edit it.

  4. Click Report Integration on the Provisioning Source page.

  5. Select the Enable Report Integration checkbox.

    The Base Report URL is automatically prefilled.

  6. Paste the XSD URL (starting from ccx/service…) into the Relative Schema (XSD) URL field.

  7. Paste the JSON URL (starting from ccx/service…) into the Relative JSON Data URL field.

    These custom URLs allow CyberArk Identity to get the attribute values from the report.

  8. Enter workday_id into the Worker Unique ID Field Name.

    This field name mirrors the one entered in Workday when you created the advanced custom report.

  9. Enter the number of minutes CyberArk Identity should wait for Workday to respond with the custom attributes information.

  10. Click Save.

Step 4: Mapping custom Workday attributes with a script.

  1. Log in to the Admin Portal.

  2. Click Settings > Users > Inbound Provisioning.

  3. Select the provisioning rule for which you want to add the script.

  4. Click the Attributes tab.

  5. Confirm that the Use Attribute Mapping Script checkbox is enabled.

  6. Click Load Sample to load the sample script.

Step 5: (Optional) Click Test to verify that the script meets your purpose.

  1. Enter a Worker ID for an employee with relevant attributes.

  2. Select the Worker ID Type from the drop-down list that corresponds to worker ID you entered.

    For example, if you entered an ID for a contingent worker, then select Contingent Worker here.

  3. Click Next.

    Attribute values associated with the worker ID is displayed.

  4. Update the script as necessary for your purpose.

    For example, resolve DisplayName conflicts by using the checkValueExists function to see if the DisplayName already exists in AD. If checkValueExists returns True, create a new function to create a unique DisplayName for the user you are trying to provision.

    Refer to Conflict resolution for more information about resolving conflicts with scripting.

  5. Click Save.

    When a synchronization between Workday and the target directory is triggered, the script runs automatically.

    Most attributes map logically. However, a few AD attributes may require additional guidance. This table documents those attributes.

    Active Directory Attributes Possible Workday Attributes Notes

    C, Co

    Alpha2WorkCountry or Alpha3WorkCountry

    Options for mapping country code. Alpha2 maps to a 2 character country code (for example, US). Alpha3 maps to a 3 character country code (for example, USA).

    CountryCode

    Numeric3WorkCountry

    Use if the country code is numeric.

    L

    WorkMunicipality

    Maps to the user’s city

    Mail

    WorkEmail

    Maps to the user’s email address

    Sn

    LastName

    Maps to the user’s last name

    St

    WorkRegion

    Maps to the street name

    The following sample script maps the workday_ID custom attribute to WorkEmail attribute in Active Directory.

     
    if(SyncContext){

    trace("Starting script");

    var sc = SyncContext;

    //trace(sc.SourceUserRecord.ReportRow.Dump());

    sc.TargetUserRecord.SamAccountName = sc.SourceUserRecord.ReportRow.Get ("Workday_ID");

    sc.TargetUserRecord.UserPrincipalName = sc.SourceUserRecord.ReportRow.Get ("Workday_ID") + "@" + sc.SourceUserRecord.WorkEmail.split("@")[1];

    if(sc.SourceUserRecord.WorkEmail){

    var x = sc.SourceUserRecord.WorkEmail.indexOf("@");

    trace("Work email valid. @ at " + x.toString());

    trace("Work email in lower case is " + sc.SourceUserRecord.WorkEmail .toUpperCase());

    }

    if(sc.SourceUserRecord.ProvisioningGroups) {

    var count = sc.SourceUserRecord.ProvisioningGroups.Count;

    trace("Prov group count: " + count);

    for(var idx = 0; idx < count; ++idx) {

    trace("Name: " + sc.SourceUserRecord.ProvisioningGroups[idx] .Name + ", Status: " + sc.SourceUserRecord.ProvisioningGroups[idx].Status);

    }

    } else {

    trace('Provisioning groups not defined');

    }

    sc.TargetUserRecord.Cn = sc.SourceUserRecord.FirstName + "." + sc.SourceUserRecord.LastName;

    sc.TargetUserRecord.EmployeeId = sc.SourceUserRecord.EmployeeId;

    sc.TargetUserRecord.DisplayName = sc.SourceUserRecord.FormattedName;

    sc.TargetUserRecord.Name = sc.SourceUserRecord.ReportingName;

    sc.TargetUserRecord.Mail = sc.SourceUserRecord.WorkEmail;

    sc.TargetUserRecord.Title = sc.SourceUserRecord.BusinessTitle;

    sc.TargetUserRecord.EmployeeType = sc.SourceUserRecord.PositionType;

    sc.TargetUserRecord.GivenName = sc.SourceUserRecord.FirstName;

    sc.TargetUserRecord.Sn = sc.SourceUserRecord.LastName;

    sc.TargetUserRecord.MiddleName = sc.SourceUserRecord.MiddleName;

    sc.TargetUserRecord.Department = "My Department";

    sc.TargetUserRecord.C = sc.SourceUserRecord.Alpha2WorkCountry;

    sc.TargetUserRecord.CountryCode = sc.SourceUserRecord.Alpha3WorkCountry;

    sc.TargetUserRecord.Co = sc.SourceUserRecord.Numeric3WorkCountry;

    sc.TargetUserRecord.St = sc.SourceUserRecord.WorkRegion;

    sc.TargetUserRecord.PostalCode = sc.SourceUserRecord.WorkPostalCode;

    sc.TargetUserRecord.L = sc.SourceUserRecord.WorkMunicipality;

    sc.TargetUserRecord.StreetAddress = sc.SourceUserRecord.WorkAddressLine1 + "," + sc.SourceUserRecord.WorkAddressLine2;

    sc.TargetUserRecord.PhysicalDeliveryOfficeName = "1234 C";

    sc.TargetUserRecord.TelephoneNumber = sc.SourceUserRecord.WorkMobile;

    sc.TargetUserRecord.Mobile = sc.SourceUserRecord.WorkMobile;

    sc.TargetUserRecord.Company = "Bunnies of doom";

    sc.TargetUserRecord.Disabled = true;

    if(sc.TargetUserRecord.MemberObjectGuids){

    var newGroupList = [];

    for(var idx = 0; idx < sc.TargetUserRecord.MemberObjectGuids.Length; ++idx){

    trace("Group guid is " + sc.TargetUserRecord.MemberObjectGuids[idx]);

    newGroupList.push(sc.TargetUserRecord.MemberObjectGuids[idx]);

    }

    // newGroupList.push("f1a7e28aa5bb4f59a3e6566fc69545e8");

    // sc.TargetUserRecord.MemberObjectGuids = newGroupList;

    } else {

    trace("MemberObjectGuids is empty or not defined.");

    }

    trace("Term date is " + sc.SourceUserRecord.TerminationDate);

    trace("Exiting script");

    }

Synchronize data

After you have configured the data source and provisioning rule, you are ready to synchronize user data from Workday to your target directory. You have the option to manually trigger a full or incremental sync or schedule incremental syncs. Full syncs are time and resource intensive so it must be triggered manually; we recommend doing it only when necessary.

For the initial sync, you must perform a full one.

Successfully provisioned users are created in the target directory source with the username syntax {WorkdayUser.UserId}@{primary tenant or domain suffix}.

Edit Workday as a data source in the Admin Portal

If the inbound provisioning doesn't work as planned, you can edit the data source and inbound provisioning rule in the CyberArk the Admin Portal.

To edit Workday as a data source in the Admin Portal

  1. Log in to the Admin Portal.

  2. Click Settings > Users > Inbound Provisioning.

  3. Click the row associated with Workday.

    The Provisioning Source page opens for edits. Complete your edits and return to the Inbound Provisioning page

  4. Click a rule associated with Workday.

    The Inbound Provisioning Rule page opens for edits. Complete your edits as needed.