Workiva Support Center

Complete the following sections in order to create an Integration System User (ISU) account and a Security Group (SG) account for API access to Workday from Workiva.

There are three major tasks as part of this process.

1. Create an Integration System User (ISU) account.
2. Create a Security Group.
3. Assign and activate the domain security policies and permissions.
4. Test and verify the account access.

Create an Integration System User (ISU) account

Complete the following steps to create an Integration System User (ISU) account that will be used by Workiva.

1. Log into your Workday tenant as an administrator (or a user with the appropriate security rights).
2. In the Workday Search box, enter Create Integration System User and select that task.
   
3. Enter a User Name. For example: ISU_WorkivaChain_API_User.
   We recommend using a term such as “API_User” or "outbound” to indicate that it is for outbound requests.
4. Enter and verify a Password.
   Make certain that the password meets your tenant’s password structure rules.
5. Uncheck Require New Password at Next Sign In.
   This keeps the account from being forced to change the password at first login.
6. As this account is only for API/integration use and should not be used to log in interactively, mark the Do Not Allow UI Sessions checkbox.
7. (Optional) Set the Session Timeout Minutes to an appropriate value for your integration’s needs. Setting this to 0 means that the session does not expire.
8. Click OK to create the account.
9. On the next screen, click Done to finish creating the ISU.
   
10. (Optional) Navigate to the task “Maintain Password Rules” and add this new ISU to the list of “System Users exempt from password expiration” so the password doesn’t expire and break integrations.

Create a Security Group

Complete the following steps to create a special Security Group for the ISU. Doing so allows you to limit it to only performing the Get Workers action.

1. In the Workday Search box, enter Create Security Group and select that task.
   
2. Select the Type of Tenanted Security Group you want. This set of instructions uses "Integration System Security Group (Unconstrained)",
   but if your security policy requires a more restrictive policy, “Constrained” should also work, but has not been tested.

Note: There are two types of Security Groups: constrained and unconstrained.
A constrained security group ensures that the web service returns results restricted to a particular supervisor organization. An unconstrained security group lets the user query any Workers in your tenant.

1. Enter a Name for the group. For example, SG_WorkivaChain_Group.
2. Click OK.
3. In the Integration System Users field, locate and select the ISU you created in Create an Integration System User (ISU) account. (ISU_WorkivaChain_API_User).
   
4. Click OK.
5. Click Done on the following screen.

Assign the domain security policies (permissions)

In Workday, a Domain controls access to a specific set of data or actions. For example, “Workers Data: Public Worker Reports” governs who can call the Get_Workers operation on the “Staffing” web service. This step defines what data and what actions the security group (and by extension, the ISU) can perform. For each domain (area of data / function) you want your integration to access, you must set the activity permissions for the security group.

Required Workday domain security policies

The following domain security policies and access values are required for the Get Workers command.

Set Security Group Permissions

Complete the following steps to set the permissions for the Security Group that will be used by Workiva.

1. In the Workday Search box, enter Maintain Permissions for Security Group and select that task (this opens the Maintain Permissions for Security Group dialog.).
   
2. In Operation, select "Maintain".
3. In the Source Security Group field, locate and select the name of the group you created in Create a Security Group (the one your ISU is a member of). For this example, it is "SG_WorkivaChain_Group".
4. Click OK.
5. Click the Add (+) button in the upper left of the table to add a new row, then search in the Domain Security Policy column for the domain policy “Worker‌Data: Public Worker Reports.”
   
6. Locate the View/Modify Access column and select Get Only (this sets it to read-only access).
7. Repeat steps 5 & 6 for the “Workers Data: Current Staffing Information” and “Worker Data: Skills and Experience” policies.
8. Click OK to save your changes.
9. Click OK.
10. Click Done.

Activate your Security Policy changes

Complete the following steps to activate the Workday Security Policy changes you have made.

1. In the Workday Search box, enter Activate Pending Security Policy Changes and select that task.
   

2. Enter a brief comment describing the change.
   For example, “Applying domain policies to SG_WorkivaChain_Group Security Group”.

   Warning: This change will apply all pending security policy changes, potentially affecting other security groups than the one you just set up. Check for other pending security policy changes before continuing.

3. Click OK.
4. Mark the Confirm checkbox in the next dialog, and click OK to make these changes active.
   
5. Your security group can now execute the Get Worker web service.

(Optional) Removing general access from the “Worker Data: Worker” domain

Workday Tenant configurations may vary from instance to instance. If "All Users" have been provisioned with Read access, please use the following guidance to constrain the Workiva Integration System User permissions to only what is required.

IMPORTANT: This instruction was written for implementing a Get_Worker data retrieval chain, and will need to be modified for any other use.

Note: Removing "All Users" will require you to explicitly specify the groups that should have access to the "Worker Data: Worker" Domain policy.

Remove general access from the “Worker Data: Worker” domain

Complete the following steps to remove general access from the “Worker Data: Worker” domain.

1. In the Workday Search box, enter Domain Security Configuration and select that task.
2. In the prompt, search for and select the domain “Worker Data: Worker”.
3. Once this page opens, click the Related Actions menu (the small gray “twinkie” button with three dots or an arrow).
4. Navigate the menu as follows:
   1. Choose Domain, then Edit Security Policy Permissions.
   2. Scroll down to the Integration Permissions section.
   3. Find the row for the All Users security group.
   4. Click the X to remove it.
   5. Click OK to save your changes and make them active.

Activate your Security Policy changes

Important caution: This change can affect other integrations or reports that rely on “All Users”, so test this in a sandbox first and verify that this change does not break any other processes.

Complete the following steps to activate your Security Policy changes.

1. In the Workday Search box, enter Activate Pending Security Policy Changes and select that task.
2. Enter a brief descriptive comment describing the change.
   For example, “Removed the ‘All Users’ Security Group”.
3. Click OK to save your changes and make them active.

Add your Security Group to “Worker Data: Worker”

Having removed the open access, you must now explicitly give your ISU’s group the permissions it needs. Complete the following steps to do so.

1. In the Workday Search box, enter Domain Security Configuration and select that task.
2. In the prompt, search for and select the domain “Worker Data: Worker”.
   (You may already be on that screen.)
3. Once this page opens, click the Related Actions menu.
4. Navigate the menu as follows: 
   1. Choose Domain and then Edit Security Policy Permissions.
   2. Scroll down to the Integration Permissions section.
   3. Click Add (+) in this section.
   4. Locate and add the security group you created in Create a Security Group.
   5. Grant Get permission. This allows the integration to query Worker data.
   6. Click OK to save your changes and make them active.
5. Run the “Activate Security Policy Changes” process once again.
   Your Security Group (and its members) can now make a Get_Worker API call and retrieve public Worker data, while the “All Users” group no longer has that access.

Test and Verify

Test and verify that you can use your ISU’s credentials (or the integration system using those credentials) to make a Get_Worker API call. If successful, you’ll receive Worker data as defined by the “Public Worker Reports” and “Worker” domain policies. If you get a “not authorized” (HTML Error code 401 or 403) or “no data” (HTML Error code 404), double-check that you activated the pending policy changes after each of the steps above.

Note: As implemented by Workiva, the data returned by the Get_Worker call is a subset of the possible Worker data that can be returned. For information on which fields are available, refer to the “Modify command tab” section of the Workiva Support page Get Workers command configuration tabs.

Notes

• This document assumes that by default, the “Worker Data: Worker” domain is delivered with the “All Users” group.
• This document assumes that by default all accounts (including ISUs) are automatically added to the “All Users” group when created.
• For sensitive fields (such as PII), Workday applies field-level security. To expose private attributes (email, phone, etc.), you must modify those field-level policies separately — this prevents over-exposure of confidential info.
• As always, we request that you thoroughly test all integrations in a Sandbox or Implementation tenant as failure to do so can have an unintended impact on integrations other than the one you're working in.
• For more information about the Get_Workers web service, refer to this Workday Support page: Concept: Get Workers SOAP Web Service Guidelines and Troubleshooting.
• As there can be many Domains that control access to data sections, make sure to review the Get_Workers API document and search for the term "Domain", as this will provide useful information on which domains control which section.
• The Required Workday domain security policies listed in this document are the minimum permissions required for the connector to invoke the API.
• Review the Reference: Security-Related Reports page in the Admin Guide for details on available security-related reports.

For instructions on setting up a Get Worker connection in Chains, refer to the Workiva Support page Set up a Get Worker Connection in Chains.