# Workday
## Overview
This document provides instructions for configuring a Workday tenant to enable the Veza integration.
The Veza integration for Workday Human Capital Management (HCM) enables search, workflows, and insights to show who can take privileged actions within Workday. After configuring the integration, you can use Search, Insights, and Workflows to:
* Find the Domain and Business Policies that belong to each security group
* Find the Permissions granted by Workday Security Policies
* Conduct user access reviews using Workday as an identity source
By default, this connection is read-only. To enable provisioning capabilities and email write-back, see the [Enable Lifecycle Management](#enable-lifecycle-management) section.
Veza will discover the following entities:
* Workday Tenant
* Workday Worker
* Workday Account
* Workday Security Group
* Workday Domain Security Policy
* Workday Business Process Security Policy
See [notes and supported entities](#notes-and-technical-details) for more details.
### Deployment Architecture
Veza connects to Workday using OAuth 2.0 with JWT authentication secured by X.509 certificates. Deployment requires creating an Integration System User, registering an API client with appropriate permissions, and generating certificates for secure communication. The integration discovers Workday Workers, Accounts, Security Groups, and Domain Security Policies, with optional support for Lifecycle Management capabilities.
## Configuring Workday
### Prerequisites
* You will need an x509 certificate and private key for API client registration and configuring the Workday provider in Veza. You can generate these directly in Veza when configuring the integration, [create them manually with OpenSSL](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/openssl.md), or use an existing signed certificate and key pair.
* Verify that Oauth2 authentication is enabled for the Workday tenant. On your Workday instance, enter `Tenant Setup`, then pick **Security** and click **Edit**. Find **OAuth 2.0 Settings** and check the box **OAuth 2.0 Clients Enabled**.
To create an integration user with the required scopes:
1. On your Workday instance, type `Create Integration System User` to create a user for Veza. After creating it, copy the username for later.
1. Check **Do Not Allow UI Sessions**
2. On your Workday instance, type `Register API Client` to add an API client.
1. Enter a name for the client
2. For **Client Grant Type** pick `Jwt Bearer Grant`
3. Enable the `Enforce 60 Minute Access Token Expiry` to align with best practice
4. Choose to “create a new x509 public key”
5. Paste the text of the PEM-encoded Certification file containing the public key. (starting with `-----BEGIN CERTIFICATE-----` and ending with `-----END CERTIFICATE-----`)
6. For **Integration System User** select the user created in the previous step
7. For `Scope (functional areas)`, enter:
* System - required for all Workday integrations
* Staffing - required for all Workday integrations
* Organizations and Roles - optional but recommended to enable gathering Organizations and Organizational Roles
* Contact Information - required for all Workday integrations to retrieve `workAddress_Country` property for workers
* Tenant Non-Configurable - only required when getting [Custom Reports](#workday-workers-custom-reports) via OAuth
8. Click **OK** to create a API client and save the client ID for later.
API Client
3. On your Workday instance, type **View API Clients** to retrieve the endpoint URL for the API client you just created. Copy the **Workday REST API Endpoint** URL (it will look like this `https://wd5-services1.myworkday.com/ccx/api/v1/veza`). Save the URL for configuring the integration in Veza.
4. On your Workday instance, type `Create Security Group` to add a security group
1. For **Type of Tenanted Security Group**, pick **Integration System Security Group (Unconstrained)**
2. Enter a name for the security group and click OK to create it.
3. On the **Edit Integration Security Group (Unconstrained)** screen, add the Integration System User to the group under **Integration System Users**. You can search or browse for the appropriate user. Click OK to add it.
5. On your Workday instance, search for `Maintain Permissions for Security Group` to apply the necessary permissions for the security group.
1. For **Operation**, pick **Maintain**.
2. For **Source Security Group**, enter the name of the security group you created earlier.
3. Click OK to open the edit form.
4. On the next screen, under **Domain Security Policy Permissions**, add a separate row for each required Domain Security Policy. To add a new row click the **+** icon, enter the correct access level and the Domain Security Policy. Add the Domain Security Policy according to the following table.
5. Click OK, review the permissions and click **Done**. 
6. Activate the security policy changes on Workday. If you don’t activate the security policy changes, Veza will not be able to extract the data from Workday:
1. On your Workday instance, type `Activate Pending Security Policy Changes` and pick **Tasks & Reports** > **Activate Pending Security Policy Changes**.
2. Add a descriptive comment and click **OK**.
3. Review the pending security policy changes, click the **Confirm** checkbox, and click **OK**.
### Domain security policy permissions
To gather entities and attributes, the Veza service principal must have the following permission scope:
| Access | Policy |
| --------------- | ------------------------------------------------- |
| View and Modify | Workday Query Language |
| Get Only | Worker Data: Workers |
| Get Only | Worker Data: Staffing |
| Get Only | Worker Data: Current Staffing Information |
| Get Only | Security Configuration |
| Get Only | Business Process Administration |
| Get Only | Worker Data: Current Management Level Information |
| Get Only | Integration Security |
| View Only | Person Data: Work Email |
| Get Only | Manage: Organization Roles |
| Get Only | Manage: Organization Integration |
**Note:** Veza uses Workday Query Language (WQL) to retrieve data from Workday. The `View and Modify` scope is required for WQL to function. Without this permission, API calls will fail with a `"permission denied" (code: S22)"` error.
#### Understanding Worker Data: Staffing inherited permissions
By default, the "Worker Data: Staffing" domain security policy includes inherited security policies that are essential for the integration to function correctly. If you encounter issues with the integration, verify that the **Domain Security Policies Inheriting Permission** in your Workday environment includes all of the following:
* Worker Data: Active and Terminated Workers
* Worker Data: Active Employees
* Worker Data: All Positions
* Worker Data: Assignments and Global Mobility
* Worker Data: Contingent Worker Assignment Details
* Worker Data: Employee Contracts
* Worker Data: Flexible Work Arrangements
* Worker Data: General Staffing Information
* Worker Data: Job Family on Worker Profile
* Worker Data: Previous System Staffing Information
* Worker Data: Probation Periods
* Worker Data: Staffing Activity Summary
* Worker Data: Staffing Reports with Compensation Data
* Worker Data: Work Assignments
* Worker Data: Work Shifts
* Worker Position: View
The following screenshot shows the expected inherited permissions under the "Worker Data: Staffing" policy:
### Enable Lifecycle Management
When configuring a Workday integration in Veza, tick the **Allow Provisioning** box to make the integration an eligible provider for Lifecycle Management. When creating Lifecycle Management Policies, administrators will be able to pick the Workday tenant as the source of identity. When Veza connects for extraction, changes to user attributes will trigger lifecycle management actions based on the active Policies and Mapping Rules.
### Permissions for Lifecycle Management
To enable Lifecycle Management capabilities, the domain security policy for the integration requires the additional permissions:
> The following permissions are required **in addition to** the base domain security policy permissions listed above.
| Access | Policy |
| --------------- | ---------------------------------------- |
| View and Modify | Workday Query Language |
| View and Modify | Person Data: Work Email |
| View and Modify | Person Data: Work Contact Information |
| View and Modify | Worker Data: Staffing |
| View and Modify | Worker Data: Public Worker Reports |
| Get Only | Security Configuration |
| Get Only | Business Process Administration |
| View and Modify | Security Administration |
| View and Modify | Workday accounts |
| View and Modify | Special OX Web Services |
| Get and Put | User-Based Security Group Administration |
The Workday API client must have the scopes:
* **System** - required for all Workday integrations
* **Staffing** - required for all Workday integrations
* **Contact Information** - required for all Workday integrations
* **Organizations and Roles** - recommended for enhanced organizational data
* **Tenant Non-Configurable** - required when gathering Worker metadata from Custom Reports via OAuth
See [Enable Provisioning for Workday](/4yItIzMvkpAvMVFAamTf/integrations/integrations/workday/provisioning.md) to grant the additional capabilities with a segmented security group.
## Configuring Workday on the Veza Platform
To register the integration in Veza, log in as a user with the administrator role, and go to **Integrations** > **Add Integration**.
1. Pick **Workday** for the integration type and click **Next**.
2. Enter a **Name** to identify the integration.
3. Enter the **REST API Endpoint** URL, retrieved in step 4 above after configuring the Workday API client.
4. Enter a **Client ID** from step 2.
5. Upload a **Private Key**: this is the certificate's private key in `.pem` format. Alternatively, click **Generate & Download Certificate and Key Pair File** to have Veza generate the certificate and key pair. Upload the downloaded certificate to the Workday API Client (see step 2.4 above), and upload the private key here.
6. Enter the Workday integration system user (ISU) **Username** created in step 5.
7. (optional) **Datasource Selection**: Choose which datasources to discover and extract from Workday. Options include:
* **Worker**: Employee records, custom properties, organizational data
* **IAM**: Accounts, security groups, policies, roles, organizations
When no datasources are selected, all datasource types are enabled by default. This provides flexibility for organizations that only need specific Workday data.
8. (optional) Add identity mapping configurations to correlate Workers to identities in an integrated Identity Provider.
9. (optional) Use the *Properties to Redact* field to list built-in Worker attributes to skip during extraction and set to *REDACTED*.
10. Save the configuration to queue the first extraction.
### Workday Workers Custom Properties
To discover custom attributes your organization applies to Workers in Workday, define them by name and type on in the **Custom Properties** section of the integration configuration.
1. On **Edit Integration** > **Custom Properties** tab, click **Add Custom Property**.
2. **Name**: Enter the name of the custom attribute on the Workday object, e.g. `cf_CFEEWorkerStatus`.
3. **Type**: Specify how Veza should handle the contents of the field. Supported types are:
* String
* Number
* Boolean
* RFC339 Timestamp
* String List
4. **Save** the configuration.
Troubleshooting: An error message indicates if Veza cannot find a matching property. Properties must exactly match the WQL alias (including the `cf_` prefix). The workday security group must have `Integration Security - Get Only` permission to extract custom properties.
These properties are added to Veza's WQL query on the allWorkers table. The custom attributes will appear in Access Graph after the next sync, enabling Lifecycle Management actions and filters for Search, Rules, and Access Reviews based on the values.
### Workday Workers Custom Reports
Veza can extract Workday Worker profile information stored in Custom Reports to expand Worker's profile information displayed in Veza.
#### Workday requirements
* Assign the Veza integration System User to the appropriate Security Group with permissions to View Custom Reports
* The Custom Reports must be shared with Veza's Integration System User directly or via a Security Group
* Custom Reports must have "Web Service" enabled
* Custom Reports must have Business Object "Worker" with Field "Workday ID" as a column
* The API Client must have the **Tenant Non-Configurable** scope enabled for accessing Custom Reports via OAuth
#### Veza setup
When configuring the integration in Veza:
1. Under **Custom Reports**, list the URLs of the Custom Reports in a comma-separated list with `?format=json` appended at the end. For example:
`https://wd5-impl-services1.workday.com/ccx/service/customreport2/veza/ReportName_A?format=json,https://wd5-impl-services1.workday.com/ccx/service/customreport2/veza/ReportName_B?format=json`
Veza supports two authentication methods for accessing Custom Reports:
* **OAuth Token (Default)**: Veza will first attempt to use the OAuth token, similar to other data retrieved via WQL. If that fails, Veza will automatically fall back to basic authentication.
* **Basic Authentication (Legacy)**: Uses username and password authentication for backward compatibility with existing configurations.
2. Under **Password**, write the password of the Veza Integration System User with access to the Custom Report. This is only required if using Basic Authentication or as a fallback method.
### Identity Mapping Configurations for Workday
Associating Workday Workers with IdP identities, and IdP identities with Workday Accounts enables search and visualization of relationships such as:
* Workday Worker -> Okta Identity -> Workday Account -> Domain Security Policy
* Workday Worker -> Azure AD Identity -> Workday Account -> Domain Security Policy
* Workday Worker -> Microsoft Azure AD Identity -> Snowflake Local User -> Snowflake Effective Permissions
{% hint style="info" %}
Identity mapping works with **any Veza-integrated Identity Provider**, including Okta, Azure AD, OneLogin, and PingOne. When the Query Builder displays an "IdP User" in a relationship chain, this is a generic label that refers to whichever IdP you have configured.
{% endhint %}
{% hint style="warning" %}
The configuration steps below assume a standard out-of-the-box Workday deployment. If your Workday instance is customized the available attributes and matching behavior may differ. Contact Veza support if your Workday Worker entities are missing expected attributes such as name or email.
{% endhint %}
To configure these identity mappings, you will need to integrate your identity provider. Then, edit **both** integrations to add a custom mapping based on matching unique ID or email. Both sides must be configured to complete the full chain from Workday Worker → IdP User → Workday Account:
1. Edit the Workday integration, and add a mapping configuration. Select your Identity Provider for the destination data source type. This creates edges from Workday Workers to IdP users.
2. Edit the integration for your IdP, and add a mapping configuration. Select "Workday Iam" for the destination data source type. This creates edges from IdP users to Workday Accounts.
## Supported Entities
The following entity types and attributes are discovered by the Veza integration for Workday:
{% hint style="info" %}
Many entities include additional attributes populated by Veza's enrichment system (such as owners, identity classifications, and risk scores). See [Enrichment Configuration](/4yItIzMvkpAvMVFAamTf/integrations/configuration/enrichment.md) for details on configuring these attributes.
{% endhint %}
### Identity Entities
#### Workday Worker
Workers are records for employees within Workday. A worker might or might not have a Workday Account.
Veza handles Workers as a separate data source, to enable two different identity mappings:
* From Workday Worker to Identity Provider user (any configured IdP: Okta, Azure AD, OneLogin, etc.)
* From Identity Provider user to Workday Account
Attributes are sourced from the `allWorkers` WQL table via the Workday REST API.
| Veza Attribute | Workday Field | Notes |
| ------------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------------- |
| `BusinessTitle` | `businessTitle` | `allWorkers` table |
| `CostCenter` | `costCenter.descriptor` | `allWorkers` table |
| `CreatedAt` | `createdMoment` | `allWorkers` table |
| `Email` | `email_PrimaryWorkOrPrimaryHome` | `allWorkers` table; falls back to `email_PrimaryWork` |
| `EmployeeID` | `employeeID` | `allWorkers` table |
| `EmployeeTypes` | `employeeType[].descriptor` | `allWorkers` table; includes `"Pre Hire"` when hire date is in the future |
| `FirstName` | `legalName_FirstName` | `allWorkers` table |
| `HireDate` | `hireDate` | `allWorkers` table; converted to RFC3339 using worker's primary location timezone |
| `HiringManager` | `originalHiringManager.descriptor` | `allWorkers` table; pre-hire workers only |
| `HiringManagerEmail` | `originalHiringManager.email` | `allWorkers` table; pre-hire workers only |
| `IdpUniqueId` | `workdayID` | `allWorkers` table; used for identity mapping |
| `IsActive` | `currentlyActive` | `allWorkers` table |
| `LastName` | `legalName_LastName` | `allWorkers` table |
| `Location` | `location.descriptor` | `allWorkers` table |
| `ManagerIdpUniqueIdList` | `workersManager[].id` | `allWorkers` table; used for LCM manager linking |
| `Managers` | `workersManager[].descriptor` | `allWorkers` table |
| `ManagementLevel` | `managementLevel.descriptor` | `allWorkers` table |
| `ManagementLevelId` | `managementLevel.id` | `allWorkers` table |
| `Position` | `position.descriptor` | `allWorkers` table |
| `PrimaryTimeZone` | `timeZoneOfLocationOfWorkersPrimaryPosition[0].descriptor` | `allWorkers` table |
| `TerminationDate` | `terminationDate` | `allWorkers` table; converted to RFC3339 using worker's primary location timezone |
| `WorkdayID` | `workdayID` | `allWorkers` table; primary Workday identifier |
#### Workday Account
A local account used to access modules, reports, and modify data related to Workers in Workday. An account might or might not be associated with a Worker profile.
Attributes are sourced from the `allWorkdayAccounts` WQL table via the Workday REST API.
| Veza Attribute | Workday Field | Notes |
| ---------------------- | ----------------------------- | ------------------------------------------------------------------------------- |
| `CreatedAt` | `createdMoment` | `allWorkdayAccounts` table |
| `DoNotAllowUISessions` | `doNotAllowUISessions` | `allWorkdayAccounts` table; contributes to `identity_type = non_human` |
| `Email` | `emailAddress` | `allWorkdayAccounts` table; falls back to `emailAddressForBusinessProcesses` |
| `IsActive` | `accountDisabled` | `allWorkdayAccounts` table; inverted (`true` when not disabled) |
| `IsDeveloper` | `systemUserIsDeveloper` | `allWorkdayAccounts` table |
| `IsImplementer` | `isImplementer` | `allWorkdayAccounts` table |
| `IsIntegrationUser` | `isIntegrationUser` | `allWorkdayAccounts` table; contributes to `identity_type = non_human` |
| `IsLocked` | `lockedAsOfMoment` | `allWorkdayAccounts` table; non-empty value indicates account is locked |
| `LastLoginAt` | `timeOfMostRecentSignOn` | `allWorkdayAccounts` table |
| `PasswordExpired` | `passwordExpired` | `allWorkdayAccounts` table |
| `PasswordLastSet` | `daysSinceLastPasswordChange` | `allWorkdayAccounts` table; derived (current time minus days since last change) |
| `RoleName` | `roleName` | `allWorkdayAccounts` table; e.g., `"SystemUser"` |
| `UpdatedAt` | `lastFunctionallyUpdated` | `allWorkdayAccounts` table |
| `Username` | `username` | `allWorkdayAccounts` table |
| `WorkerWorkdayId` | `worker.id` | `allWorkdayAccounts` table; links account to associated Worker |
#### Workday Position
Job position within the organization. Positions can be held by workers and associated with organizational roles.
Attributes are sourced from the Workday SOAP API (GetRoleAssignments).
| Veza Attribute | Workday Field | Notes |
| -------------------- | ------------------------------- | --------------------------------------------------- |
| `EmployeeId` | `workerEmployeeID` | SOAP GetRoleAssignments |
| `PositionDescriptor` | `positionIdentifier.descriptor` | SOAP GetRoleAssignments |
| `PositionId` | `positionID` | SOAP GetRoleAssignments |
| `WorkerWorkdayId` | `workerIdentifier.id` | SOAP GetRoleAssignments; links to associated Worker |
### Group and Role Entities
#### Workday Security Group
Security Groups manage permissions for users in Workday. They can be role-based or user-based:
* **Role Based Security Groups** - Collections of users with security groups assigned to them because of their Role
* **User Based Security Groups** - Collections of users with security groups directly assigned to their profiles
Attributes are sourced from the `securityGroups` WQL table via the Workday REST API.
| Veza Attribute | Workday Field | Notes |
| -------------------------- | --------------------------- | ----------------------------------------------------------------------------------- |
| `AssignableRoleDescriptor` | `assignableRole.descriptor` | `securityGroups` table |
| `AssignableRoleWorkdayId` | `assignableRole.id` | `securityGroups` table |
| `Comment` | `comment` | `securityGroups` table |
| `ContextType` | `context_Type` | `securityGroups` table |
| `CreatedAt` | `createdMoment` | `securityGroups` table |
| `IsActive` | `inactive` | `securityGroups` table; inverted (`true` when not inactive) |
| `SecurityGroupType` | `type` | `securityGroups` table; e.g., `"Integration System Security Group (Unconstrained)"` |
| `UpdatedAt` | `lastFunctionallyUpdated` | `securityGroups` table |
| `WorkdayOwned` | `workday_Owned` | `securityGroups` table; `true` for Workday-managed groups |
#### Workday Security Group Binding
Represents the assignment of a security group to a Workday organization. Bindings can be direct (assigned explicitly to an organization) or inherited (propagated from a parent organization in the hierarchy).
Attributes are derived by Veza from organizational role assignment and security group data.
| Veza Attribute | Workday Field | Notes |
| -------------- | ------------- | ------------------------------------------------------------------------------------------------------ |
| `IsInherited` | — | Derived; `true` if the binding was propagated from a parent organization, `false` if directly assigned |
#### Workday Organizational Role
Role within an organization that can be assigned to positions or workers. Organizational roles define responsibilities and access within the organizational hierarchy.
Attributes are sourced from the Workday SOAP API (GetRoleAssignments).
| Veza Attribute | Workday Field | Notes |
| ------------------------------ | ----------------------------------------- | ----------------------- |
| `OrganizationalRoleDescriptor` | `organizationalRoleIdentifier.descriptor` | SOAP GetRoleAssignments |
| `OrganizationalRoleId` | `organizationalRoleID` | SOAP GetRoleAssignments |
#### Workday Organizational Role Assignment
Assignment linking an organizational role to a specific position within an organization.
Attributes are sourced from the Workday SOAP API (GetRoleAssignments).
| Veza Attribute | Workday Field | Notes |
| ------------------------------ | ----------------------------------------- | ----------------------- |
| `OrganizationDescriptor` | `organizationIdentifier.descriptor` | SOAP GetRoleAssignments |
| `OrganizationReferenceId` | `organizationReferenceID` | SOAP GetRoleAssignments |
| `OrganizationalRoleDescriptor` | `organizationalRoleIdentifier.descriptor` | SOAP GetRoleAssignments |
| `OrganizationalRoleId` | `organizationalRoleID` | SOAP GetRoleAssignments |
| `RoleAssigneeDescriptor` | `roleAssigneeIdentifier.descriptor` | SOAP GetRoleAssignments |
| `RoleAssigneePositionId` | `roleAssigneePositionID` | SOAP GetRoleAssignments |
### Organization Entities
#### Workday Organization
Organizational unit within Workday (such as departments, cost centers, or regions). Organizations form a hierarchy and can have members, superior organizations, and associated security policies.
Attributes are sourced from the Workday SOAP API (GetOrganizations).
| Veza Attribute | Workday Field | Notes |
| ---------------------------------- | --------------------------------------------- | ---------------------------------------------------------- |
| `IsActive` | `inactive` | SOAP GetOrganizations; inverted (`true` when not inactive) |
| `OrganizationSubtypeDescriptor` | `organizationSubtypeIdentifier.descriptor` | SOAP GetOrganizations |
| `OrganizationSubtypeId` | `organizationSubtypeID` | SOAP GetOrganizations |
| `OrganizationTypeDescriptor` | `organizationTypeIdentifier.descriptor` | SOAP GetOrganizations |
| `OrganizationTypeId` | `organizationTypeID` | SOAP GetOrganizations |
| `OrganizationVisibilityDescriptor` | `organizationVisibilityIdentifier.descriptor` | SOAP GetOrganizations |
| `ReferenceId` | `organizationReferenceID` | SOAP GetOrganizations |
| `SuperiorOrganizationDescriptor` | `superiorOrganizationIdentifier.descriptor` | SOAP GetOrganizations; parent org in hierarchy |
| `SuperiorOrganizationId` | `superiorOrganizationID` | SOAP GetOrganizations; parent org in hierarchy |
### Filtering inherited organization permissions
When querying Workday Account → Workday Organization paths, the **Include assumed Workday Organizations** toggle controls whether the query follows organization-to-organization hierarchy edges. Disabling this toggle excludes most inherited paths, but some paths may still appear when a security group binding was inherited from a parent organization without an intermediate Workday Organization node.
To fully exclude inherited organization access, add a filter on the intermediary **Workday Security Group Binding** entity:
* Set **Is Inherited** to `false`
This filter removes bindings that were propagated from a parent organization, showing only direct assignments. You can combine this filter with the **Include assumed Workday Organizations** toggle for the most precise results.
### Policy Entities
#### Workday Policy Binding
In Workday, security policies define permissions to securable objects such as reports, tasks, and business processes.
In the Veza Access Graph, policy binding entities for Workday show the scope of permissions an identity has to a Domain or Business Process Security Policy (such as `Get`, `Put`, or `View`).
Setting Workday Policy Binding as the destination entity type for a Workflow query enables review of permissions for each identity of the source entity type (such as Workday Account).
#### Workday Domain Security Policy
Domain Security Policies control access to reports, tasks, and integrations.
Attributes are sourced from the `domainSecurityPolicies` WQL table via the Workday REST API.
| Veza Attribute | Workday Field | Notes |
| ------------------------ | ------------------------------ | ------------------------------ |
| `CreatedAt` | `createdMoment` | `domainSecurityPolicies` table |
| `Description` | `description` | `domainSecurityPolicies` table |
| `FunctionalAreas` | `functionalAreas[].descriptor` | `domainSecurityPolicies` table |
| `IsActive` | `policyIsActive` | `domainSecurityPolicies` table |
| `UpdatedAt` | `lastFunctionallyUpdated` | `domainSecurityPolicies` table |
| `UsingParentPermissions` | `usingParentPermissions` | `domainSecurityPolicies` table |
#### Workday Business Process Security Policy
Business Process Policies are used to secure business process objects in Workday.
Attributes are sourced from the `businessProcessTypes` WQL table via the Workday REST API.
| Veza Attribute | Workday Field | Notes |
| ------------------------ | ------------------------------ | ---------------------------- |
| `AttachmentsEnabled` | `attachmentsEnabled` | `businessProcessTypes` table |
| `CreatedAt` | `createdMoment` | `businessProcessTypes` table |
| `Description` | `description` | `businessProcessTypes` table |
| `DynamicBusinessProcess` | `dynamicBusinessProcess` | `businessProcessTypes` table |
| `FunctionalAreas` | `functionalAreaS[].descriptor` | `businessProcessTypes` table |
| `UpdatedAt` | `lastChanged` | `businessProcessTypes` table |
### Tenant Entities
#### Workday Tenant
The tenant is the top-level entity representing an organization's Workday environment.
| Veza Attribute | Workday Field | Notes |
| -------------- | ------------- | --------------------------------------------- |
| `InstanceUrl` | — | Derived from the configured REST API endpoint |
#### Workday Tenant Workers
Container representing all workers within a Workday tenant.
| Veza Attribute | Workday Field | Notes |
| -------------- | ------------- | --------------------------------------------- |
| `InstanceUrl` | — | Derived from the configured REST API endpoint |
## Notes and technical details
### API endpoints
The Veza integration interacts with Workday through three distinct API endpoints:
1. **Workday REST API**: Used to execute Workday Query Language (WQL) queries to discover entities and their attributes.
* `https:///ccx/api/v1/`
2. **Workday SOAP API for Custom Reports**: Used to retrieve expanded Worker profile information (optional).
* `https:///ccx/service/customreport2//?format=json`
3. **Workday SOAP API for Lifecycle Management**: Used when Lifecycle Management is enabled to manage entitlements and update Worker emails during provisioning workflows:
* Assign or remove users to or from Security Groups: `https:///ccx/service//v42.0`
* Email write-back:
* `https:///ccx/api/person/v3//workContactInformationChanges//emailAddresses`
* `https:///ccx/api/person/v3//workContactInformationChanges//submit`
* `https:///ccx/api/staffing/v5//workers//workContactInformationChanges`
### Saved Queries
The integration includes Saved Queries to identify:
* Workday Security Groups not containing any Workday Account
* Workday Security Groups with no active Workday Account
* Activated Workday Accounts with no log-ins in the last 90 days
* Workday Accounts with Implementer user flag enabled
* Workday Accounts with Developer user flag enabled
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/workday.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.