# SailPoint Workday Accounts SaaS Connector Documentation

> Workday Accounts SaaS Connector Documentation

# Documentation

# Connecting SailPoint and Workday Accounts SaaS

To connect SailPoint with Workday Accounts, perform the following tasks:

## Adding the Source in SailPoint

To connect to SailPoint, perform the following steps. Once the connection is made, you can configure it to meet your company's needs.

> [!IMPORTANT]
>
> By default, the provisioning feature is **disabled**, and the connector only supports read-only operations. To support provisioning operations, you must manually enable the feature in the source configuration.

**To configure a new source:**

1. Sign in to SailPoint.
2. Go to **Admin \> Connections \> Sources**.
3. Select **Create New**.
4. Search for the connector by entering the name in the search box, and then select **Actions**.
5. In the **Actions** dropdown list, select the setup method:

   - [**Express Setup**](<#configuring-a-source-using-express-setup>) - Quickly create a read-only connection to your target system by providing minimal configurations and authentication. On completion, aggregation is automatically started.

     > **Note**
     >
     > Express Setup supports Credential Providers. For information on supported credential providers and configuration, refer to [Credential Providers](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>). For more information, contact your SailPoint Customer Service Manager.
   - [**Standard Setup**](<#configuring-a-source-using-standard-setup>) - Provide detailed basic configuration to create the source. Once the source is created, continue with source setup.

### Configuring a Source Using Express Setup

Express Setup minimizes the initial configuration process so you can quickly connect the application and immediately begin aggregating user account and entitlement data.

1. Review the directions and select **Start Express Setup**.
2. Review the pre-populated **Source Name**, **Source Owner**, and **Description**. To update, select **Edit**.

   > **Note**
   >
   > The source name must be unique. You can change these settings later in the source configuration.
3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider.

   > **Note**
   >
   > To add a Credential Provider in SailPoint, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>).
4. Configure the authentication to allow SailPoint to connect to the source. For more information, refer to the **Connection Settings** section.
5. Select **Finish**.

   After a successful test connection, the system creates your source and prompts you to run an aggregation.

   - If you want to aggregate now, select **Aggregate**.

     - To see the latest account aggregation history, go to **Account Management \> Account Aggregation**.
     - To see the list of aggregated source accounts, go to **Account Management \> Accounts**.
   - If you want to aggregate later, select **Exit**. This returns you to the **Sources** page. Your new source is listed, but contains no accounts or aggregation history yet.

### Configuring a Source Using Standard Setup

Use Standard Setup to configure the connector for full feature support.

1. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters.
2. In the **Description** field, provide additional details about the source to help distinguish it from similar sources. This field allows a maximum of 2,000 characters.
3. In the **Source Owner** field, begin typing the name of an owner. Matches appear after you type two or more letters. For more information, refer to [Assigning a Source Owner](<https://documentation.sailpoint.com/saas/help/sources/index.html#assigning-a-source-owner>).
4. (Optional) Select a governance group to grant its members [source](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#source-sub-admin-user-level>) or [role](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#role-sub-admin-user-level>) sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html>).
5. If this source represents a primary system containing your organization's personnel records, select the **Authoritative Source** checkbox. For more information, refer to [Creating Identity Profiles](<https://documentation.sailpoint.com/saas/help/setup/identity_profiles.html>).
6. Select **Continue**. The source is created, and you are navigated to the **Source Setup \> Base Configuration** page. Continue to configure your connected source there.

## Base Configuration

Provide the base configuration parameters. Information you entered in the Create New Source dialog is automatically entered into the fields in the Base Configuration page. You can edit this information if necessary.

1. Enter a unique name and description for the source.
2. In the **Source Owner** dropdown list, select the identity that owns this source.

   - To find a source owner, begin entering their name.
3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider.

   > **Note**
   >
   > To add a credential provider, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>).
4. Configure the authentication to allow SailPoint to connect to the source. Refer to [Connection Settings](<#connection-settings>) for more information.
5. (Optional) In the **Governance Group for Source Management** dropdown list, select a governance group to associate with this source. For more information about governance groups, refer to [Associating Governance Groups with a Source](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html#associating-a-governance-group-with-a-source>).
6. (Optional) Choose whether to enable or disable provisioning for the source. Provisioning is disabled by default.

   - **Enable Provisioning** - Set the toggle to **Enabled** to allow the source to create, update, and deactivate accounts in the connected source system.
   - **Disable Provisioning** - Set the toggle to **Disabled** to disable provisioning for the source. Disabling provisioning will prevent the creation, updating, or deactivating of accounts on this source.
7. Select **Save**.

## Connection Settings

Provide the information required to connect to Workday Accounts SaaS.

1. In **Workday URL**, enter the fully qualified URL to connect to Workday's Human Resource module.
2. Select the required **Authentication Type**:

   - Basic
   - OAuth 2.0
3. Select **Save**.

### Basic Connection Settings

For the **Basic** authentication type, provide the following details:

1. In **Service Account**, enter the name of the Integration System User that has all the required permissions.

   > **Note**
   >
   > Service Account must always be in the **username@tenantname** format.
2. Enter the **Service Account Password** of the Integration System User.
3. Select **Save**.

### OAuth 2.0 Connection Settings

For the **OAuth 2.0** authentication type, provide the following details:

> [!NOTE]
>
> To use the lightweight test connection operation, set `lightWeightTestConnection` to `true` using the SailPoint REST APIs. Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1>).

1. In **Grant Type**, select the authorization grant type supported by the managed system:

   - Refresh Token
2. Enter the Workday API **Client ID** and **Client Secret**.
3. Enter the Workday API **Refresh Token**.

   > **Note**
   >
   > Ensure that the token never expires.
4. In **Token URL**, enter the Workday token URL.
5. Select **Save**.

## Additional Settings

### Filter Settings

1. Select the **Exclude Inherited Organization Roles** checkbox to aggregate only the account's assigned roles and ignore any inherited roles during account aggregation. Refer to [Organization Roles](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/schema.html#organization-roles>) for more information.
2. Select **Aggregate Terminated Account** to include terminated workers in account aggregation processes.
3. In **Termination Offset**, enter the offset value in days, which indicates the number of past days to aggregate the terminated worker's account. Default: 60 days.
4. Select the **Aggregate Future Accounts** checkbox to aggregate future accounts ahead of their hire date.
5. In **Future Offset**, enter the number of days in advance of their hire date to aggregate future accounts.
6. Enable the **Filter Accounts By Organization** option to aggregate Workday Accounts based on the organization filters provided.
7. Select the **Organization Type** option to get the Workday Accounts based on organization type. Workday uses the default `COST_CENTER` organization type.
8. Select the **Organization Reference ID** option to get the Workday Accounts based on a specific organization. If you want to add multiple organizations, enter the organizations separated by a comma. For example, `OrgRefID, OrgRefIDOne`.

   > **Note**
   >
   > To find your organization's reference IDs, complete the following:
   >
   > 1. Search for the required organization.
   > 2. Hover over **Action**, and then select **Integration ID**.
   > 3. Select **View IDs**, and write down the ID displayed in front of the organization type.

### Manage Additional Workday Accounts Settings

1. Enable the **Manage Service Center Representative Accounts** checkbox to manage Service Center Representative accounts.
2. Enable the **Manage Extended Enterprise Learner Accounts** checkbox to manage Extended Enterprise Learner accounts.
3. Enable the **Manage Implementers Accounts** checkbox to manage Implementers accounts.
4. Enable the **Manage Integration System Accounts** checkbox to manage Integration System accounts.

### Manage Workday Accounts for Students

1. Enable the **Manage Prospects Accounts** checkbox to aggregate Prospects accounts.
2. Enable the **Manage Applicants Accounts** checkbox to aggregate Applicants accounts.
3. Enable the **Manage Pre-Matriculant Accounts** checkbox to aggregate Pre-Matriculant accounts.
4. Enable the **Manage Matriculant Accounts** checkbox to aggregate Matriculated accounts.

#### Manage Additional Group Schema Attributes

1. Enter the **Integration System ID** created to retrieve the custom or calculated attributes for the OrganizationRole Group.
2. Select **Save**.

## XPath Schema Mapping

The source schema for the Workday Accounts SaaS is used to configure the objects returned from the source.

The Workday Accounts SaaS currently supports the following attributes and corresponding XPaths:

| Attributes | Description | Path |
| --- | --- | --- |
| `USERID` | Workday account username. | `Workday_Account_for_Worker_Data/User_Name` |
| `FILENUMBER` | Unique identifier for the employee or contractor. This identifier can be an alphanumeric value based on the value present in the Workday system.<br>**Note:** When aggregating service center representative accounts, the service center representative ID is populated in the `FILENUMBER` attribute. | `Workday_Account_Reference/ID[@type='Employee_ID'] &#124; Workday_Account_Reference/ID[@type='Contingent_Worker_ID']` |
| `ACCOUNT_DISABLED` | Identifies whether the Workday Account is disabled. | `Workday_Account_for_Worker_Data/Account_Disabled` |
| `REQUIRE_NEW_PASSWORD_AT_NEXT_SIGN_IN` | Indicates whether the Workday account will require a new password at next sign in. | `Workday_Account_for_Worker_Data/Require_New_Password_at_Next_Sign_In` |
| `SESSION_TIMEOUT_MINUTES` | The number of minutes the user may be idle. | `Workday_Account_for_Worker_Data/Session_Timeout_Minutes` |
| `MULTI_FACTOR_AUTHENTICATION_EXEMPT` | Exempt user from multi-factor authentication. | `Workday_Account_for_Worker_Data/Multi-factor_Authentication_Exempt` |
| `MULTI_FACTOR_AUTHENTICATION_GRACE_PERIOD_ENABLED` | Enable user's multi-factor authentication grace period. | `Workday_Account_for_Worker_Data/Multi-factor_Authentication_Grace_Period_Disabled` |
| `GRACE_PERIOD_LOGINS_REMAINING` | The remaining number of times the user can login without providing a multi-factor authentication passcode. | `Workday_Account_for_Worker_Data/Grace_Period_Logins_Remaining` |
| `ACCOUNT_EXPIRATION_DATE` | Prevents the user from signing on to the system after this date. | `Workday_Account_for_Worker_Data/Account_Expiration_Date` |
| `OPENID_IDENTIFIER` | The email address associated with the Open ID account. | `Workday_Account_for_Worker_Data/OpenID_Identifier` |
| `OPENID_INTERNAL_IDENTIFIER` | Open ID GUID. | `Workday_Account_for_Worker_Data/OpenID_Internal_Identifier` |
| `OPENID_CONNECT_INTERNAL_IDENTIFIER` | OpenID Connect subject. | `Workday_Account_for_Worker_Data/OpenID_Connect_Internal_Identifier` |
| `EXEMPT_FROM_DELEGATED_AUTHENTICATION` | Exempt from Delegated Authentication. | `Workday_Account_for_Worker_Data/Exempt_from_Delegated_Authentication` |
| `WORKER_TYPE` | Worker's type (`Employee`\|`Contingent_Worker`). | `Workday_Account_Reference/ID[@type='Employee_ID']/@type &#124; Workday_Account_Reference/ID[@type='Contingent_Worker_ID']/@type` |
| `USER_BASED_SECURITY_GROUPS` | Enables aggregation of user-based security groups. | `Get_Assign_User-Based_Security_Groups_Response/ns1:Response_Data/ns1:Assign_User-Based_Security_Groups` |
| `ORG_ROLE##ORG_NAME` | Fetches the role name along with the organization separated by a `##` delimiter. | Path is automatically assigned. |

The Workday Accounts SaaS supports updating all the schema attributes supported in the Workday managed system.

> [!NOTE]
>
> The `ACCOUNT_EXPIRATION_DATE` attribute must be in the `MM/DD/YYYY` format. For example, `07/22/2021`.

### Custom XPath

The Workday Accounts SaaS supports camel-case XPath for fetching supervisory organization records during role provisioning.

You can provide a custom XPath for the supervisory organization as given in the following example:

```text
ns1:Worker_Data/ns1:Organization_Data/ns1:Worker_Organization_Data[ns1:Organization_Data[ns1:Organization_Type_Reference[ns1:ID[@ns1:type='Organization_Type_ID']='Supervisory']]]/ns1:Organization_Reference/ns1:ID[@ns1:type='Organization_Reference_ID']
```

## Review and Test

Perform a test to confirm the connection to SailPoint.

1. Go to **Review and Test**.
2. Confirm that the entries in each field are correct.

   If you note any mistakes, return to the section and make corrections.
3. Select **Test Connection**.

## SailPoint Application Onboarding

SailPoint application onboarding enables you to easily onboard new applications and create sources following the successful onboarding of a discovery source. To use this feature, continue to **Discovered Applications** in the SailPoint user interface.

For more information, refer to [Application Onboarding](<https://documentation.sailpoint.com/saas/help/ai/app_onboarding/index.html>) in the SailPoint SaaS documentation.

# Diagnosing Connection Issues

## Timeout Errors and Settings

Timeout errors might occur when SailPoint is waiting for a response from the connector-runtime. These errors are applicable to all connectors and tend to occur during the setup of sources or when sources are down.

This document is designed to give specific information that can be used to resolve these errors.

Each timeout attribute has a default time value that is listed in seconds or minutes. Increasing the time value may resolve the error as it will allow for longer communication time between the two systems, thus avoiding the timeout error.

To increase the communication time, increase the value of the appropriate timeout attribute. Then submit the change to the connector-runtime using the SailPoint REST API.

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.

### aggregateTimeout

**Description:** This parameter is set for the aggregation timeout, measured in seconds.

**Resolution:** Increase the `aggregateTimeout` value gradually to optimize aggregation. Start with 180, then increase to 600, 900, and finally 1800. The maximum value is 3600 seconds.

For example:

If your current time value is 180 seconds, update the `aggregateTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/aggregateTimeout",
        "value": 600
    }
]
```

### healthCheckTimeout

**Description:** This parameter is set for the test connection and health check timeout.

**Resolution:** The default value is 30 seconds. If the timeout error continues, increase the value in 15 second increments and try again.

For example:

If your current time value is 30 seconds, update the `healthCheckTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/healthCheckTimeout",
        "value": 45
    }
]
```

### provisioningTimeout

**Description:** This parameter is set for provisioning timeout.

**Resolution:** Increase the `provisioningTimeout` value gradually to optimize provisioning. Start with 180, then increase to 360, and finally 600. The maximum value is 600 seconds.

For example:

If your current time value is 180 seconds, update the `provisioningTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/provisioningTimeout",
        "value": 360
    }
]
```

### timeout

**Description:** This parameter is set for pass-through authentication timeout.

**Resolution:** The default value is 15 seconds. If the timeout error continues, increase this value in 15 second increments and try again.

For example:

If your current time value is 15 seconds, update the `timeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/timeout",
        "value": 30
    }
]
```

### apiTimeout

**Description:** This parameter is set for API time tracking; customers can check it using an external tool.

**Resolution:** The default value is 60 seconds. If the error continues, increase the value by 15 second increments and try again.

For example:

If your current time value is 60 seconds, update the `apiTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/apiTimeout",
        "value": "75"
    }
]
```

## Enable Connector Logging

This topic provides the steps needed to enable logging on SailPoint using REST APIs.

> [!NOTE]
>
> This topic only applies to VA-based integrations.

> [!NOTE]
>
> The examples provided might not match your configuration. Use the logging levels and logging classes reference at the bottom of the topic to configure your API responses to match your connector.

This process is broken up into four steps:

1. Identify the Virtual Appliance (VA) cluster on which you want to enable logging.
2. Get the logging configuration for the existing VA cluster.
3. Update the VA cluster to enable logging levels.
4. Observe logging changes to the logging levels.

### Identify the Virtual Appliance Cluster

Select the VA on which you need to enable logging using REST API. If you already know the VA application's `id`, proceed to [Get the Logging Configuration](<#get-the-logging-configuration>).

1. Make the following call to the REST API to return a list of available VA clusters:

   GET /v3/managed-clusters

   The REST API returns a response that looks similar to the following:

   ```json
   [
       {
           "id": "2c9180866166b5b0016167c32ef31a66",
           "name": "Development Cluster",
           "description": "Development Cluster",
           "clientType": "CCG",
           "ccgVersion": "373_535_70.2.0",
           "pinnedConfig": true,
           "logConfiguration": null
       },
       {
           "id": "2c9180846a93ce60016ab29f039944de",
           "name": "Cloud Cluster",
           "description": "Cloud Cluster",
           "clientType": "CCG",
           "ccgVersion": "373_535_70.2.0",
           "pinnedConfig": true,
           "logConfiguration": {
               "clientId": null,
               "durationMinutes": 60,
               "expiration": "2020-12-15T19:13:36.079Z",
               "rootLevel": "DEBUG",
               "logLevels": {
                   "sailpoint.connector.ADLDAPConnector": "DEBUG"
               }
           }
       }
   ]
   ```

   > **Note**
   >
   > The previous example code shows two VA clusters. One VA cluster has a log configuration and the other does not (refer to the `logConfiguration` value in each returned VA cluster). This is because one of the clusters already has logging enabled. This is just an example configuration, and your environment may not have logging enabled on a cluster.
2. Identify the VA cluster that you want to enable logging on by its name or description and record its `id` attribute.

### Get the Logging Configuration

Get your selected VA's cluster logging configuration and identify the values you need to update.

1. Make the following call to the REST API to return the VA cluster's logging configuration. Replace `{id}` with the VA cluster's `id` attribute value recorded earlier.

   GET /v3/managed-clusters/{id}/log-config

   - If the VA doesn't have a logging configuration currently set, it returns `204 No Content` as a response.
   - If the VA has an existing logging configuration, it returns something similar to the following:

     ```json
     {
         "clientId": null,
         "durationMinutes": 60,
         "expiration": "2020-12-15T19:13:36.079Z",
         "rootLevel": "DEBUG",
         "logLevels": {
             "sailpoint.connector.ADLDAPConnector": "DEBUG"
         }
     }
     ```

     You'll need to configure the following information in the response:

     - `durationMinutes` is the number of minutes logging should remain enabled.
     - `rootLevel` is the default level for all logs. For more information, refer to [Logging Levels](<#logging-levels>).
     - `logLevels` is a map object with logging classes as keys and logging levels as values.

       - For keys, refer to [Logging Classes](<#logging-classes>) for commonly used logging classes.
       - For a list of available values, refer to [Logging Levels](<#logging-levels>).

### Update Logging Configuration

Update the VA cluster configuration returned by the REST API to update the logging settings as needed.

1. Make the following call to the REST API to update the VA cluster's logging configuration. Replace `{id}` with the VA cluster's `id` attribute value recorded earlier.

   PUT /v3/managed-clusters/{id}/log-config
2. Submit your configuration changes to the REST API in a JSON body.

   - If the VA cluster did not already have a logging configuration and you received a `204 No Content` response, you can create a new one.
   - If the VA returned a configuration, you can edit it to include the changes.

   The JSON body should be as follows:

   ```json
   {
       "durationMinutes": 60,
       "rootLevel": "DEBUG",
       "logLevels": {
           "sailpoint.connector.ADLDAPConnector": "DEBUG"
       }
   }
   ```

   Consider the following as you edit the JSON:

   - `durationMinutes` is the number of minutes logging should remain enabled.
   - `rootLevel` is the default level for all logs. For more information, refer to [Logging Levels](<#logging-levels>).
   - `logLevels` is a map object with logging classes as keys and logging levels as values.

     - For keys, refer to [Logging Classes](<#logging-classes>) for commonly used logging classes.
     - For a list of available values, refer to [Logging Levels](<#logging-levels>).

   If the update was successful, the REST API should return a response similar to the following:

   ```json
   {
       "clientId": null,
       "durationMinutes": 60,
       "expiration": "2020-12-15T19:13:36.079Z",
       "rootLevel": "DEBUG",
       "logLevels": {
           "sailpoint.connector.ADLDAPConnector": "DEBUG"
       }
   }
   ```

### Observe Logging Changes

Approximately five minutes after you update the configuration, the VA cluster starts generating log files you can review. You can view the log files in **ccg.log**.

### References

The tables in this reference section list information that can be helpful when creating the JSON body you'll use to configure the VA cluster's configuration file.

#### Logging Levels

| Logging Level | Description |
| --- | --- |
| ERROR | Designates error events that might still allow the connector to continue. |
| WARN | Designates potentially harmful situations. |
| INFO | Designates information messages that highlight process at a coarse-grain level. |
| DEBUG | Very verbose. Fine grain logging levels used for development and debugging. |
| TRACE | Most verbose. Finer grain logging levels than debugging. |

#### Logging Classes

| Connector | Logging Class |
| --- | --- |
| Active Directory | sailpoint.connector.ADLDAPConnector sailpoint.connector.LDAPConnector |
| AIX | openconnector.connector.unix.AIXConnector openconnector.connector.unix.UnixConnector |
| Amazon Web Services | logger.aws.name=openconnector.connector.aws logger.aws.level=trace logger.aws.additivity = false logger.aws.appenderRef.rolling.ref = STDOUT |
| Atlassian Suite Cloud | sailpoint.connector.OpenConnectorAdapter openconnector.connector.atlassian.AtlassianConnector |
| Atlassian Data Center | sailpoint.connector.OpenConnectorAdapter openconnector.connector.atlassian.AtlassianDataCenterConnector |
| Microsoft Entra ID | sailpoint.connector.AzureADConnector |
| Box | openconnector.connector.BoxNetConnector sailpoint.connector.OpenConnectorAdapter |
| Cerner | openconnector.connector.CernerConnector sailpoint.connector.OpenConnectorAdapter |
| Delimited File | logger.DelimitedFileConnector.name = sailpoint.connector.DelimitedFileConnector logger.DelimitedFileConnector.level = debug logger.DelimitedFileConnector.additivity = false logger.DelimitedFileConnector.appenderRef.rolling.ref = STDOUT |
| Dropbox | openconnector.connector.DropBoxConnector sailpoint.connector.OpenConnectorAdapter |
| Epic | openconnector.connector.EPICConnector sailpoint.connector.OpenConnectorAdapter |
| GE Centricity | openconnector.connector.GECentricity sailpoint.connector.OpenConnectorAdapter |
| Google Apps / G Suite | openconnector.connector.GoogleAppsDirect sailpoint.connector.OpenConnectorAdapter |
| IBM i | openconnector.connector.IBMiConnector |
| Lotus Domino | sailpoint.connector.LotusDomino |
| JDBC | sailpoint.connector.JDBCConnector |
| Sun One LDAP | sailpoint.connector.LDAPConnector |
| Linux | openconnector.connector.unix.LinuxConnector sailpoint.connector.OpenConnectorAdapter sailpoint.connector.UnixConnector |
| Microsoft Office365 | sailpoint.connector.Office365Connector |
| Microsoft SQL Server | sailpoint.connector.mssql.serviceimpl.MSSQLServerConnectorV2 |
| Okta | logger.openconnector.name = openconnector.connector.okta.OktaConnector logger.openconnector.level = debug logger.openconnector.additivity = false logger.openconnector.appenderRef.rolling.ref = STDOUT |
| Oracle Database | sailpoint.connector.OracleDBConnector sailpoint.connector.JDBCConnector |
| Oracle E-Business | sailpoint.connector.OracleEBSConnector sailpoint.connector.JDBCConnector |
| Oracle Fusion HCM | openconnector.connector.oraclefusionhcm.OracleFusionHCMConnector sailpoint.connector.OpenConnectorAdapter |
| Oracle HCM Cloud | sailpoint.connector.oraclehcmcloud.OracleHCMCloudConnector |
| Oracle HRMS | sailpoint.connector.OracleAppsHRMSConnector sailpoint.connector.JDBCConnector |
| Oracle Netsuite | openconnector.connector.netsuite.NetsuiteConnector |
| PeopleSoft ERP | openconnector.connector.PeopleSoftConnector sailpoint.connector.OpenConnectorAdapter |
| PeopleSoft HRMS | sailpoint.connector.PeopleSoftHRMSConnector |
| RemedyForce | sailpoint.connector.ForceConnector |
| RSA Authentication Manager | openconnector.connector.RSAConnector openconnector.connector.rsa.RSAHTTPClient sailpoint.connector.OpenConnectorAdapter |
| Salesforce | sailpoint.connector.ForceConnector |
| SAP Concur | openconnector.connector.sapconcur.SAPConcurConnector |
| SAP - Direct | sailpoint.connector.SAPConnector sailpoint.connector.SAPInternalConnector |
| SAP GRC | logger.SAPGRCConnector.name = sailpoint.connector.sapgrc logger.SAPGRCConnector.level = debug logger.SAPGRCConnector.additivity = false logger.SAPGRCConnector.appenderRef.rolling.ref = STDOUT |
| SAP HR/HCM | sailpoint.connector.SAPHRInternalConnector |
| SCIM 1.1 | openconnector.connector.SCIMConnector sailpoint.connector.OpenConnectorAdapter |
| SCIM 2.0 | openconnector.connector.scim2.SCIM2Connector sailpoint.connector.OpenConnectorAdapter |
| ServiceNow | openconnector.connector.servicenow.ServiceNowConnector openconnector.connector.servicenow.ServiceNowRestClient sailpoint.connector.OpenConnectorAdapter |
| ServiceNow Service Desk Integration | openconnector.connector.servicedesk.ServiceNowServiceDeskConnector sailpoint.connector.OpenConnectorAdapter |
| Siebel | openconnector.connector.SiebelConnector sailpoint.connector.OpenConnectorAdapter |
| Snowflake | openconnector.connector.snowflake.SnowflakeConnector sailpoint.connector.OpenConnectorAdapter |
| Solaris | openconnector.connector.unix.SolarisConnector openconnector.connector.unix.UnixConnector sailpoint.connector.OpenConnectorAdapter |
| SuccessFactors | sailpoint.connector.SuccessFactorsConnector |
| Sybase | sailpoint.connector.SybaseDirectConnector sailpoint.connector.JDBCConnector |
| Webex | openconnector.connector.Webex sailpoint.connector.OpenConnectorAdapter |
| Workday | openconnector.connector.WorkDay sailpoint.connector.OpenConnectorAdapter |
| Workday Accounts | openconnector.connector.workdayaccounts openconnector.connector.workdayaccounts.WorkdayAccountsConnector sailpoint.connector.OpenConnectorAdapter |
| Web Services | sailpoint.connector.WebServices |
| XML | openconnector.connector.XMLConnector sailpoint.connector.OpenConnectorAdapter |
| Yammer | openconnector.connector.YammerConnector sailpoint.connector.OpenConnectorAdapter |
| Zoom | openconnector.connector.zoom.ZoomConnector sailpoint.connector.OpenConnectorAdapter |

# Integrating SailPoint with Workday Accounts SaaS

This guide is designed to give specific information about the requirements and field definitions needed to get a working instance of a Workday Accounts SaaS connector in SailPoint.

Connecting SailPoint to your Workday Accounts SaaS connector allows you to aggregate Workday Account records from Workday and enable/disable the Workday Accounts.

> [!NOTE]
>
> To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes](<https://community.sailpoint.com/release-notes/saas>) page.

## Supported Features

The SailPoint Workday Accounts SaaS connector supports the following features.

The following table specifies which kind of authentication is required for each supported feature:

| Supported Features | Basic Authentication | OAuth 2 Authentication |
| --- | --- | --- |
| Manage Active, Terminated, Future Accounts | Yes | Yes |
| Filter Accounts by Organization | Yes | Yes |
| Manage Service Center Representative Accounts | Yes | Yes |
| Manage Extended Enterprise Learner Accounts | Yes | Yes |
| Manage Implementers Accounts | No | Yes |
| Manage Integration System Accounts | No | Yes |
| Manage Workday Accounts for Students | No | Yes |
| Manage Additional Group Schema Attributes | No | Yes |
| Aggregation of User-based security groups | Yes (Partial) - the `COMMENT` and `DESCRIPTOR` attributes are only supported for the OAuth 2.0 Authentication Type | Yes |
| Aggregation of Organization roles as Group Object | No | Yes |
| Aggregation of `SECURITY_GROUPS` | No | Yes |

### Account Management

- Create Workday Accounts.
- Aggregation.

  > **Note**
  >
  > The Workday Accounts connector supports filtering of active and future accounts based on the Organization and Organization Reference ID.
- Aggregation of future accounts ahead of their hire date. Refer to [Additional Settings](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/connecting.html#additional-settings>) for more information.
- Aggregation of Extended Enterprise Learner Accounts.
- Aggregation of Implementer Accounts.

  > **Note**
  >
  > The Workday Accounts SaaS connector does not support creating Implementer user Accounts.
- Aggregation of Integration System Accounts.

  > **Note**
  >
  > - The Workday Accounts connector does not support enable/disable operation for Integration System Accounts. To update integration system account, it should be assigned to Integration System. To create integration system account, provisioning policy must have the password and Integration System ID attributes.
  > - This functionality is applicable only for OAuth 2.0 authentication.
- Aggregation of Student Account Types:

  - Prospects
  - Applicants
  - Pre-Matriculant Accounts
  - Matriculated Accounts

### Group Management

- Aggregation of user-based security groups.
- Aggregation of Organization roles.
- Aggregation of all the types of security groups.
- Aggregation of Custom Attributes associated with [Custom Attributes for Organization Role](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/schema.html#default-group-attributes>).

#### Provisioning

The following table specifies provisioning supported features for supported attributes:

| Features | Supported For Employee/Contractors | Service Center Representative Accounts | Supported for Extended Enterprise Learner Accounts | Supported for Implementers Accounts | Supported for Integrations Accounts | Supported for Students Accounts |
| --- | --- | --- | --- | --- | --- | --- |
| Create Workday Accounts | Yes | Yes | No | No | Yes | Yes |
| Add/Remove Organization Role | Yes | No | No | No | No | No |
| Add/Remove User-based Security Groups | Yes | Yes | No | Yes | Yes | Yes |
| Change Password | Yes | Yes | No | Yes | Yes | Yes |
| Update Account | Yes | Yes | No | Yes | Yes | Yes |
| Enable/Disable | Yes | Yes | No | Yes | No | Yes |

> [!NOTE]
>
> The Workday Accounts connector supports provisioning of all supported attributes except for `File number` and `Worker type`.

### Learning Management

- Aggregation of active and completed courses assigned to the user. Refer to [Learning Management](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/learning_management.html>) for more information.
- Aggregation of the "Learning Course Offering Associated with Blended Course", digital course, and learning program as part of group aggregation.
- Addition and removal of `ACTIVE_COURSES` to the Workday account.

## Prerequisites

A Workday administrator account and password for connecting to the given URL of the Workday tenant.

### Add/Remove User-Based Security Groups

To enable the functionality for adding or removing user-based security groups within the Workday Accounts SaaS source, certain prerequisites must be completed. These steps ensure that the appropriate security controls are in place and that the necessary configurations allow this process to work seamlessly.

1. Enable the required domain security policy:

   1. Go to **System Functional Area \> Security Administration**.
   2. Locate and enable the domain security policy, **"User-Based Security Group Event"**.

      > **Note**
      >
      > Enabling this policy allows the business process to be executed as part of the Workday Accounts SaaS's security configuration.
2. Configure the User-Based Security Group Event:

   1. Access the configuration settings for the User-Based Security Group Event for Group.

      - Specify which security groups can perform workflow-specific actions, such as:

        - Approve
        - Ad hoc Approval
        - Cancel
        - Deny
        - Request Reassignment
        - View all
        - View Completed Only
   2. Define the default settings for the User-Based Security Group Event.

   > **Important**
   >
   > Ensure that the service account is part of the "Initiating Action" for the "User-Based Security Group Event for User (Web Service)."

## Supported Managed Systems

The Workday Accounts SaaS connector supports the following versions of the Workday System:

- Workday API version 39.1
- Workday API version 38.0
- Workday API version 32.1
- Workday API version 30.1
- Workday API version 24.1

> [!NOTE]
>
> The Workday Accounts SaaS connector uses Workday's SOAP API, which is independent of the Workday system version and is backward compatible.

The Workday Accounts SaaS connector supports the following modules of the Workday system:

- Workday HCM
- Workday Financial
- Workday LMS

## Required Permissions

This section describes the permissions required for the Workday Accounts SaaS application on the Workday managed system.

### Basic Authentication

Workday Accounts SaaS supports provisioning of Organization Roles.

The "Manage: Service Center" permission is required to aggregate service center representative accounts.

The following permissions are required for the user in Workday Accounts SaaS:

| Operation | Get Permission | Put Permission |
| --- | --- | --- |
| Aggregate Workday Account | Workday Account; Worker Data: Public Worker Reports; Manage Service Center; Manage: Organization Integrations |  |
| Update and Enable/Disable Workday Account |  | Workday Accounts Domain |
| Aggregate Organization Roles | Manage: Organization Roles |  |
| Add/Remove Organization Roles |  | Roles: Manage; Manage: Organization Roles; Assign Role (Web Service) from Business Process Security Policy |
| Aggregate user-based Security Groups | User-Based Security Group Administration |  |
| Provision user-based Security Groups |  | Assign Domain Security Policy Permissions to Security Group: User-Based Security Group Administration |

> [!NOTE]
>
> - All the permissions should be assigned under the "Integration Permissions" section.
> - Provisioning of Organization Roles is supported for Workday API version 30.1 and onwards.
> - On the Workday system, inactive Security Groups are not visible in the UI, however they are aggregated by the connector and can be provisioned. For aggregation of inactive Security Groups, the User-Based-Security-Group must have the ID that is assigned while creating the security group in the Workday system.
> - The *Manage: Service Center* permission is required to aggregate service center representative accounts.
> - The *Manage: Organization Integrations* permission is required to use the organization type filter.

### OAuth 2.0 Authentication

The following permissions are required for the OAuth 2.0 Authentication Type:

1. Create the API Client. Refer to [Create API Client for Integration](<#create-api-client-for-integration>) for more information on API Client creation.
2. Ensure the Workday Account used by the API Client to generate the refresh token is an integration user, and has all the permissions described in [Basic Authentication](<#basic-authentication>).
3. Add all of the following functional areas under the API Client Integration used for OAuth 2.0:

   - Staffing
   - System
   - Organization and Roles
   - Integration
   - Extended Enterprise for Learning (if Manage Extended Learner Account is enabled)
4. To fetch the `COMMENT` and `DESCRIPTOR` attributes, the following additional permissions are needed:

   | Domain | Category | Permission |
   | --- | --- | --- |
   | Workday Query Language | Report/Task Permissions | Modify access |
   | Security Activation | Report/Task Permissions | Modify access |
   | Security Configuration | Report/Task Permissions | Modify access |
5. To fetch the `OrganizationRole` group object, the following additional permissions are needed for group aggregation:

   | Domain | Category | Permission |
   | --- | --- | --- |
   | Security Administration | Report/Task Permissions | Modify access |

   Refer to [Group Object: OrganizationRole](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/schema.html#group-object-organizationrole>) for more information.
6. The following additional permissions are needed to fetch the `SECURITY_GROUPS` group object:

   | Domain | Category | Permission |
   | --- | --- | --- |
   | Workday Query Language | Report/Task Permissions | Modify access |
   | Security Activation | Report/Task Permissions | Modify access |
7. To aggregate Implementer user accounts, the following additional permissions are needed:

   | Domain | Category | Permission |
   | --- | --- | --- |
   | Workday Query Language | Report/Task Permissions | Modify access |
8. To aggregate Integration accounts, the following additional permissions are needed:

   | Domain | Category | Permission |
   | --- | --- | --- |
   | Workday Query Language | Report/Task Permissions | Modify access |
   | Security Activation | Report/Task Permissions | Modify access |
9. To aggregate the Integration System ID associated with the integration user, the following permissions are needed:

   | Domain | Category | Permission |
   | --- | --- | --- |
   | Integration Security | Report/Task Permissions | Put access |
10. To manage Student Accounts, the following permissions are needed:

    | Domain | Category | Permission |
    | --- | --- | --- |
    | Workday Query Language | Report/Task Permissions | Get access |
    | Reports: Student Recruitment | Report/Task Permissions | Get access |
    | Reports: Students | Report/Task Permissions | Get access |
    | Integration Build | Integration Permissions | Get access |

### Create API Client for Integration

1. Using the **Register API Client for Integrations** task, register a new API Client for Integrations with the following configurations:

   1. Client Name
   2. Grant type: Authorization Code Grant
   3. Access token: Bearer
   4. Select the **Non-Expiring Refresh Tokens** checkbox.
   5. Deselect the **Disabled** checkbox.
   6. Select the Scope (Functional Areas): Personal Data, Integration.
2. Use the **View API Client for Integrations** task to generate a refresh token.

   1. Select the newly created API client, and go to **API Client Actions \> API Client \> Manage Refresh Tokens for Integration**.
   2. Select the Workday Account for which the refresh token must be generated, and then select **Next**.
   3. Select the **Generate New Refresh Token** checkbox, and then select **OK**.

# Learning Management

The Workday Accounts SaaS supports the following features:

1. Aggregates the following training data associated with users from the Workday system:

   - Learning Offering associated with Blended Courses
   - Digital Course
   - Learning Program
2. Supports the addition and removal of `ACTIVE_COURSES`.

> [!NOTE]
>
> The source should be on Workday API version 39.1 to aggregate the training information associated with the user.

To enable Learning Management functionality, perform the following steps manually to add the Account Attributes in the schema:

1. Account Attribute

   | Schema Name | Description |
   | --- | --- |
   | COMPLETED\_COURSES | Completed Courses assigned to the user will be aggregated in the following format: **ID of training \| Completion date \| Registration date** |
   | ACTIVE\_COURSES | Active Courses assigned to the user as Property Entitlement and "course" type. |
2. Group Object

   Add a separate Group object (apart from the out-of-the-box Group object/schema) of the "course" type that can be created with the following properties:

   | Schema Name | Description |
   | --- | --- |
   | ID | Course ID. |
   | NAME | Course Name. |
   | UNDERLYING\_COURSE | The underlying courses: 1. Blended Course associated with the Offering Learning. 2. Courses associated with the Learning Program. |
   | DESCRIPTION | Course Description. |
   | COURSE\_TYPE | Course Type, i.e. Digital, Course Offering, or Program. |
3. Update the service account with the following permissions:

   - For aggregation, the following permission is required:

     | Operation | Get Permission |
     | --- | --- |
     | Aggregate the User Training Information | Manage Learning Content; Reports: Learning Record |
     | Aggregate Extended Enterprise Learner Accounts | Manage: Extended Enterprise Affiliation Learners |
   - For the addition and removal of `ACTIVE_COURSES`, the following permission is required:

     | Operation | Put Permission |
     | --- | --- |
     | Add/Remove ACTIVE\_COURSES | Manage: Learning Course Enrollments |
   - In addition to the permissions listed above, perform the following configuration step:

     1. Navigate to the task: Edit Business Process Security Policy.
     2. Enter: Enroll in Content.
     3. For Enroll In Learning Content (Web Service) Initiating Action, enter the security group created in the integration security group setup.
     4. For Cancel Learning Enrollment (Web Service) Initiating Action, enter the same security group created in the integration security group setup.
4. Add the following functional area under the API Client Integration used for OAuth 2.0:

   - Learning Core

## Support for Automatic Provisioning Approval LMS

You can configure the Workday connector to bypass the approval process for provisioning requests and automatically process updates.

To enable this functionality, add the following to SailPoint via the REST API:

```json
[
    {
        "op": "add",
        "path": "/connectorAttributes/courseAutoComplete",
        "value": "true"
    }
]
```

# Machine Account Attributes

Machine account attributes are used in provisioning configurations for machine accounts.

After you have [created the required machine account subtypes](<https://documentation.sailpoint.com/saas/help/machine/account_configuration.html#creating-machine-account-subtypes>), you can use the machine account attributes to provision machine accounts in your SailPoint tenant.

Refer to [Machine Identity Security Overview](<https://documentation.sailpoint.com/saas/help/machine/index.html>) for more information.

## Machine Account Provisioning Attributes

> [!NOTE]
>
> The Workday Accounts SaaS does not provide out-of-the-box machine account classification. Configure classification criteria based on your governance standard, such as naming conventions or role assignment.

| Field (name) | Display Name | Type | Required | Notes |
| --- | --- | --- | --- | --- |
| `USERID` | User ID | `string` | Yes | UserID for the account. |
| `WORKER_TYPE` | Worker Type | `string` | Yes | Worker Type of the user. For example, Integration System User. |
| `INTEGRATION_SYSTEM_ID` | Integration System ID | `string` | Yes | Integration System ID for the user. |
| `FILENUMBER` | File Number | `string` | Yes | File number of the worker. |

# Provisioning

The Workday Accounts SaaS connector supports provisioning, allowing you to create and manage accounts and entitlements in Workday Accounts directly from SailPoint.

**Prerequisite:** Your system is configured for provisioning.

When SailPoint provisions new accounts to the source, it uses the attributes on the **Create Account** page as instructions or a template for what to include in the account. This page is also referred to as the *provisioning policy*.

When new access is granted on a source where a user does not already have an account, SailPoint automatically includes account creation in the provisioning. This applies whether provisioning is started from an access request or from an automated role or lifecycle state assignment.

For direct-connect sources, SailPoint automatically creates the account from this configuration. If the source is not configured as a direct-connect source, SailPoint creates and assigns a provisioning task to the source owner and includes the values for the source owner to use in manually creating the account.

> [!IMPORTANT]
>
> This section describes the default **Create Account** configuration. SailPoint recommends that you work with Services to define a provisioning configuration specific to your company's needs. Be sure to verify large changes to the provisioning policy before implementation. Failure to do so might cause provisioning to fail.

## Default Create Account Attributes

The following table shows the attributes in the create account policy:

| Account Attribute | Description |
| --- | --- |
| User Name | The Workday Accounts SaaS username. |
| File Number | The Workday Accounts SaaS file number/service center representative ID. |
| Worker Type | The Workday Accounts SaaS worker type. For example, `Employee`, `Contingent_Worker`, or `Service_Center_Representative`. |

> [!NOTE]
>
> - If a business process in Workday requires approval before an account is created, you must approve it manually in the Workday managed system.
> - Workday account creation for terminated and future records is not supported.

> [!IMPORTANT]
>
> - For the `File Number` attribute, the worker must already exist in the Workday managed system, and you must provide the file number here.
> - If `Username`, `File Number`, or `Worker Type` is blank, the create operation fails.

### Role and Organization Assignment

If a role needs to be configured for an organization that is not present in the aggregated data, add the following attribute to the provisioning policy:

| Account Attribute | Description |
| --- | --- |
| Organization\_Reference\_ID\_Item | The reference ID of the organization to assign, other than the default organization that is populated. For example, if the value of `ORG_ROLE##ORG_NAME` is `Admin##Test_Organization` and you want to assign the `Admin` role to a different organization, add this attribute to the provisioning policy with the reference ID of that organization. |

> [!NOTE]
>
> The `Organization_Reference_ID_Item` attribute uses the organization name as the value.

### Password Configuration

When creating Workday accounts, you must configure the `GENERATE_RANDOM_PASSWORD` or `PASSWORD` attribute in the **Create Account** policy with an associated value.

- If the `PASSWORD` attribute is configured and the required password is provided, the specified password is set for the Workday account.
- If `GENERATE_RANDOM_PASSWORD` is set to `true`, ensure the following:

  - The user has a valid email address on file.
  - The Workday tenant is configured to send security emails.
  - The user cannot use delegated authentication.

## Creating Accounts in the Workday System

The Workday Accounts SaaS supports creating accounts in the Workday managed system.

The following mandatory fields are required in the provisioning plan to create an account:

| Field | Description |
| --- | --- |
| Username | The name of the user. |
| Filenumber | The file number of the worker in the Workday managed system. |
| Worker type | The type of worker, such as `Employee` or `Contingent_Worker`. |

> [!NOTE]
>
> **Notes**
>
> - Use the REST API to add multiple supported attributes to the Create Account policy on the source.
> - Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.

For existing Workday Accounts SaaS sources, you can create the Create Account policy using the REST API as long as the following schema attributes are mapped to the listed identity attributes:

| Schema Attribute | Identity Attribute |
| --- | --- |
| USERID | First Name |
| FILENUMBER | SailPoint User Name |
| WORKER\_TYPE | Static (`Employee` or `Contingent_Worker`) |

### Limitations

If a business process set up in the Workday managed system requires approval before an account is created, you must approve it manually in the Workday managed system. The Workday Accounts SaaS does not support creating accounts for terminated and future records.

# Schema Reference

The application schema is used to configure the objects returned from a connector.

> [!NOTE]
>
> - The **Account Schema** tab is used to define the attributes for each object type in the application being configured. The schema attributes can be defined as **Entitlement** or **Multi-Valued**. Refer to [Managing Source Account Schemas](<https://documentation.sailpoint.com/saas/help/accounts/schema.html>) for more information.
> - The schema attributes that are not present by [default](<#default-account-schema>) must be defined as strings if not specified.

The Workday Accounts SaaS connector uses the following default correlation and object configurations.

## Default Correlation Configuration

Before you aggregate accounts from this source, you can map account attributes with their corresponding identity attributes based on your requirements.

You can customize the correlation configuration. Refer to [Assigning Source Accounts to Identities](<https://documentation.sailpoint.com/saas/help/accounts/correlation.html>) for more information.

When you first create the Workday Accounts SaaS source, the default correlation mapping is:

| Account Attribute | Operation | Identity Attribute |
| --- | --- | --- |
| FILENUMBER | Equals | SailPoint User Name (uid) |

## Default Account Schema

Each source supports a variety of details, or attributes, about each user who has an account, such as their name, email address, manager name, and location.

The set of account attributes each source stores and how they're organized is known as the account's *schema*. To best represent your data, you can configure sources to use an account schema matching the one you use in the external connector. Refer to [Managing Source Account Schemas](<https://documentation.sailpoint.com/saas/help/accounts/schema.html>) for more information.

### Default Account ID

SailPoint requires that certain attributes remain in your configuration. These attributes are referred to as *account IDs*.

> [!CAUTION]
>
> Changing the attribute marked as the account ID after aggregating accounts can result in duplicate accounts being created. To avoid this, either reset the accounts on this source before editing the account ID attribute or edit the account ID attribute before aggregating accounts.
>
> To resolve issues caused by changing account IDs, reconfigure them to their default values.

The following table lists the default account IDs for this connector:

| Account ID | Schema Object Type |
| --- | --- |
| FILENUMBER | Account |
| ID | Group |

### Default Account Attributes

The Workday Accounts SaaS connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified.

| Attribute Name | Description |
| --- | --- |
| USERID | The Workday account user name. |
| FILENUMBER | The unique identifier for the Employee or Contractor. This identifier can be an alphanumeric value based on the value present in the Workday system.<br>When aggregating service center representative accounts, implementers and integration system accounts, the WID is populated in the `FILENUMBER` attribute.<br>This is an Account ID which must not be changed. |
| ACCOUNT\_DISABLED | Identifies whether the Workday account is disabled. |
| REQUIRE\_NEW\_PASSWORD\_AT\_NEXT\_SIGN\_IN | Indicates whether the Workday account will require a new password at next sign in. |
| SESSION\_TIMEOUT\_MINUTES | Number of minutes the user may be idle. |
| MULTI\_FACTOR\_AUTHENTICATION\_EXEMPT | Exempt the user from multi-factor authentication. |
| MULTI\_FACTOR\_AUTHENTICATION\_GRACE\_PERIOD\_ENABLED | Enable user's multi-factor authentication grace period. |
| GRACE\_PERIOD\_LOGINS\_REMAINING | Remaining number of times the user can login without providing a multi factor authentication passcode. |
| ACCOUNT\_EXPIRATION\_DATE | Prevents the user from signing on to the system after this date. |
| OPENID\_IDENTIFIER | Email address associated with the Open ID account. |
| OPENID\_INTERNAL\_IDENTIFIER | Open ID GUID |
| OPENID\_CONNECT\_INTERNAL\_IDENTIFIER | OpenID Connect subject |
| EXEMPT\_FROM\_DELEGATED\_AUTHENTICATION | Exempt from Delegated |
| WORKER\_TYPE | Employee, Contingent\_Worker, Service Center Representative, Extended Enterprise Learner, Implementer Account, Integration System User |
| USER\_BASED\_SECURITY\_GROUPS | Enables aggregation of user-based security groups of the account. |
| SECURITY\_GROUPS | Fetches all the security groups of the account except User based security groups. |

## Default Entitlement Attributes

Entitlement attributes define the entitlements, such as groups or roles, that can be assigned to the managed system's user accounts. Refer to [Managing Entitlements](<https://documentation.sailpoint.com/saas/help/access/entitlements.html>) for more information.

> [!CAUTION]
>
> Changing the attribute marked as the Entitlement ID after aggregating accounts or entitlements can result in duplicate entitlements being created, or access profiles and roles breaking. To avoid this, edit the entitlement schema before performing any aggregations.

### Default Group Attributes

The Workday Accounts SaaS connector also supports groups. The following attributes must be configured on the managed system and in the SailPoint source schema to manage groups.

The following table lists the group attributes for user-based Security Groups:

| Attributes | Description | Path |
| --- | --- | --- |
| ID | The internal ID for this group. This is an Account ID which must not be changed. | The path is automatically assigned. |
| COMMENT | The description for this group. | The path is automatically assigned. |
| DESCRIPTOR | The name for this group. | The path is automatically assigned. |

> [!NOTE]
>
> The `COMMENT` and `DESCRIPTOR` attributes are only supported for the OAuth 2.0 Authentication Type.

The following table lists the group attributes for `SECURITY_GROUPS`:

| Attributes | Description | Path |
| --- | --- | --- |
| ID | The internal ID for the groups. | The path is automatically assigned. |
| TYPE | The type for this group. | The path is automatically assigned. |
| NAME | The name for this group. | The path is automatically assigned. |

> [!NOTE]
>
> The `SECURITY_GROUPS` group attributes are only supported for the OAuth 2.0 Authentication Type.

#### Group Object: OrganizationRole

By default, the `OrganizationRole` group object is not part of the out-of-the-box schema. Use the [createSchema API](<https://developer.sailpoint.com/docs/api/create-source-schema-v-1/>) to create a new group schema for your source.

> [!NOTE]
>
> Refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community for more information on SailPoint's REST APIs.

Refer to [OAuth 2.0 Authentication](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/index.html#oauth-20-authentication>) for more information on the additional permissions required for aggregating the `OrganizationRole` group object.

The following table lists the attributes of the `OrganizationRole` group object:

| Attributes | Description | Path |
| --- | --- | --- |
| ORG\_ROLE\#\#ORG\_NAME | Associates an organization role reference ID with an organization name reference ID. | The path is automatically assigned. |
| ROLE\_NAME | Organization role name. | The path is automatically assigned. |
| ASSOCIATED\_SECURITY\_GROUP | Associated role-based security group. | The path is automatically assigned. |
| ORGANIZATION\_NAME | Name of the organization. | The path is automatically assigned. |

To aggregate custom fields defined for the `OrganizationRole` group object, refer to [Configuring Custom Attributes for the OrganizationRole Group](<#configuring-custom-attributes-for-the-organizationrole-group>).

##### Schema Example

The following is an example of API body content for adding entitlements to the source:

```json
{
  "name": "OrganizationRole",
  "nativeObjectType": "OrganizationRole",
  "identityAttribute": "ORG_ROLE##ORG_NAME",
  "displayAttribute": "ORG_ROLE##ORG_NAME",
  "hierarchyAttribute": null,
  "includePermissions": false,
  "features": [],
  "configuration": {},
  "attributes": [
    {
      "name": "ORG_ROLE##ORG_NAME",
      "type": "STRING",
      "schema": null,
      "description": "Associates an organization role reference ID with an organization name reference ID",
      "isMulti": false,
      "isEntitlement": false,
      "isGroup": false
    },
    {
      "name": "ROLE_NAME",
      "type": "STRING",
      "schema": null,
      "description": "Name of the Role",
      "isMulti": false,
      "isEntitlement": false,
      "isGroup": false
    },
    {
      "name": "ORGANIZATION_NAME",
      "type": "STRING",
      "schema": null,
      "description": "Name of the organization",
      "isMulti": false,
      "isEntitlement": false,
      "isGroup": false
    },
    {
      "name": "ASSOCIATED_SECURITY_GROUP",
      "type": "STRING",
      "schema": null,
      "description": "Name of the Associated role-based security group",
      "isMulti": false,
      "isEntitlement": false,
      "isGroup": false
    }
  ]
}
```

> [!NOTE]
>
> The new group object is only supported for the OAuth 2.0 Authentication Type.

#### Configuring Custom Attributes for the OrganizationRole Group

This section describes the procedure for fetching custom attributes from Workday.

The Workday Accounts SaaS supports aggregating custom fields defined for the `OrganizationRole` group object. To fetch the values of custom and calculated fields for the `OrganizationRole` group object, ensure that you enter the **Integration System ID** in the UI. Refer to [Manage Additional Group Schema Attributes](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/connecting.html#manage-additional-group-schema-attributes>) for more information.

##### Configure an Integration System in Workday

Perform the following steps to configure the Workday Integration System:

1. Search for **Create Integration Field Override Service** in Workday, and create a new Integration Field Override Service.
2. Assign a name to the Integration Field Override Service and select the business object as **Organizations**.
3. Add the fields, as per your requirement, and provide a name for each field:

   1. Select the **Plus** icon to add a new row, and then select **OK**.
   2. Choose a name that will match the schema attribute.
   3. Define the required settings for the new fields.
   4. Select **Done**.
   5. Repeat these steps for each new field.
4. Create a new Workday Integration System as follows:

   1. On your Workday Home page, go to **Integration System \> Create Integration System**.
   2. Provide a name for the Integration System.
   3. Select **New Using Template** and provide the value as **Document Transformation**.
   4. Select **OK**.
   5. Go to **Actions \> Integration System \> Configure Integration Attachment Service**.
   6. Select the Attachment column and select **Create Integration Attachment Service**.
   7. Attach an empty text file and select **OK**.
5. In your new Workday Integration System, add the field override service created in the previous steps, as follows:

   1. Go to **Custom Integration Services**.
   2. Select the **Plus** icon. Under **Custom Integration Services**, add the field override service you created.
   3. Select **OK**.
6. Note the System ID for this Workday Integration System. It is required to retrieve the custom or calculated attributes.
7. Search for **View Integration System**.
8. Enter the name of the Workday Integration System you created.
9. Select **OK**.
10. Map the new fields to the correct value:

    1. Go to **Integration System \> Configure Integration Field Overrides**.
    2. Select the calculated or custom field and map the correct value to it in **Override External Field**.
    3. Select **OK**.
    4. Select **Done**.
11. When applicable, grant the required permissions to the service account associated with the source to aggregate the new custom or calculated fields.

> [!NOTE]
>
> - Custom and calculated attributes added to the Workday OrganizationRole Group schema must have `__c` appended to the field names created in Workday. For example, if you added `PREVIOUS_EMPLOYER` to Workday, you would add `PREVIOUS_EMPLOYER__c` in the source schema.
> - Aggregation takes more time for a larger number of configured custom attributes and calculated fields. The value of the calculated fields and custom attributes are calculated at run time, and aggregation is delayed, as it requires extra time to fetch the calculated values.

## Organization Roles

The Workday Accounts SaaS aggregates and provisions an organization role with the organization name.

You must add a new schema attribute `ORG_ROLE##ORG_NAME` in the account schema. The `ORG_ROLE##ORG_NAME` is a multi-valued entitlement attribute of type `OrganizationRole`. The `ORG_NAME` value is used as the organization reference ID while assigning a role to a worker.

### Assigning an Organization Other Than the Default Organization

If you want to assign an organization other than the default organization, configure the `Organization_Reference_ID_Item` attribute in the provisioning policy. This is the reference ID of the organization.

For example, if the value of the `ORG_ROLE##ORG_NAME` attribute is `Admin##Test_Organization` and you want to assign the `Admin` role to a different organization than `Test_Organization`, you must use the `Organization_Reference_ID_Item` attribute in the provisioning policy and pass the required organization reference ID.

### Excluding Inherited Roles During Aggregation

The Workday Accounts SaaS supports aggregation and provisioning of Organization Roles assigned to the user in Workday. These roles are assigned to the user's parent/direct organization, as well as the underlying inherited organization. By default, the Workday Accounts SaaS aggregates both the direct and underlying inherited roles assigned to the users.

If you want to exclude the inherited roles during account aggregation, then enable the **Exclude Inherited Organization Roles** checkbox on the [Additional Settings](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/connecting.html#additional-settings>) configuration page.

# Troubleshooting

If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support.

For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information:

- [SailPoint Identity Services Documentation](<https://documentation.sailpoint.com/saas/help/index.html>)
- [SailPoint Support Knowledge Base](<https://support.sailpoint.com/csm?id=kb_view2&amp;kb_id=05ff44289f011200550bf7b6077fcfa3>)
- [SailPoint Developer Community](<https://developer.sailpoint.com/>)

## Debug Logs

For information about managing additional source settings, including debug logging and downloading connector logs, refer to [Managing Additional Settings](<https://documentation.sailpoint.com/saas/help/sources/managing_additional_settings.html>).

## Account Aggregation Returns Zero Accounts

**Issue**: Account aggregation completes successfully but returns no accounts from Workday. The integration user may lack the required domain security policy permissions, even if all documented permissions have been assigned.

**Resolution**: Ask the customer's Workday administrator to verify and configure the following permissions:

1. In Workday, search for **Domain Security Policies for Functional Area**.
2. Select **Staffing** and go to **Worker Data: Workers**.
3. Under the **Integration permission** section, verify that the SailPoint security group is listed.

   - If the security group is not present, add it to the Integration permission section.
4. Run the **Activate Pending Security Policy Changes** task.
5. Verify that the issue is resolved.

## Aggregation Is Passed but the SECURITY\_GROUPS Attribute Is Not Fetched

**Issue**: During entitlement aggregation in the Workday Accounts SaaS, you may encounter one of the following:

- Aggregation completes successfully, but the `SECURITY_GROUPS` attribute is not returned.
- Aggregation fails with the following error:

  ```text
   invalid request: WQL error.",
   "errors":[{"error":"Enter a valid report field. This field is invalid: cf_SecurityGroupName.",
   "field":"cf_SecurityGroupName",
   "location":"Invalid SELECT clause"
  ```

**Resolution**: Check with your Workday team to verify and correct the configuration by following these steps:

1. In the search bar, enter **Edit Calculated Field**.
2. Search for Security Group Name from the list of **Calculated Field**.
3. On the **Calculation** tab, verify that the **Concatenate Text** function includes the **Security Group** field.

   [![Calculation tab of the Security Group Name calculated field, showing the Concatenate Text function with the Security Group field](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/img/security_group_name_calculation.png>)](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/img/security_group_name_calculation.png>)
4. On the **Additional Info** tab, verify that the **WQL Alias** Name is set exactly as follows: `cf_SecurityGroupName`.

   > **Note**
   >
   > The alias is case-sensitive and must be entered exactly as shown.

   [![Additional Info tab of the Security Group Name calculated field, showing the WQL Alias set to cf\_SecurityGroupName](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/img/security_group_name_additional_info.png>)](<https://documentation.sailpoint.com/connectors/workday_accounts/saas/help/img/security_group_name_additional_info.png>)
5. If the WQL alias is incorrect or missing, update it accordingly.
6. Save the changes and re-run the entitlement aggregation.

## Workday Accounts Connector Does Not Provision Multiple Requests Simultaneously

**Resolution**: This is a limitation of the Workday API, where multiple provisioning requests containing different entitlements cannot be processed simultaneously. As a workaround, customers should include all required entitlements within a single provisioning request.

## Create Account Operation Fails

**Issue**: The Create Account operation fails with the following error: `Please check the logs. Either username, filenumber, or worker-type is empty.`

**Resolution**: The Create Account policy must include values for username, filenumber, and worker-type. If any of these values are missing, the operation will fail with the error mentioned above.