Workday Data Coverage and Performance

Understand the data gaps, limitations, and performance expectations of the Workday data connector.

Overview

Visier provides an integration that covers the key metrics and dimensions needed to jump-start a people analytics strategy. We have identified the critical attributes that most organizations will need to retrieve from their Workday system. The Workday API does not expose all of the data required to build a people analytics solution. Because of the Workday limitations, the connector is not a one-size-fits-all strategy as it covers approximately 75% of the required data. If there are topics and fields that are not covered by the Workday connector, you can load this data via Workday Reports-as-a-Service (RaaS) or flat file.

Data coverage

This section details the data coverage the connector provides for subjects in Visier’s analytic model. Use the following table to determine if the connector can be used to retrieve the data you want to analyze.

If the connector provides:

• Full coverage: The connector can be used to load this data. You will have a good set of data to fill out Visier’s Blueprint.
• Limited coverage: The connector can be used to load this data. However, there will be gaps. For example, supplementary data may be absent or some source system properties may not be supported by Visier’s analytic model. You will need to load additional data to fill out Visier’s Blueprint.
• No coverage: The connector cannot be used to load this data.

Subject	Data Coverage	Notes
Organization Core (Employee, Starts, Exits, Hierarchies)	Limited	For full data coverage, you will need to load via RaaS or flat file: Workday calculated fields ManagerID To support additional use cases, you will need to load via RaaS or flat file: As-was/Historical Organization Hierarchies International Assignments Filtered population
Placements	Full
Performance	Full
Budgeted Compensation	Full	Full data coverage for the following pay types: Base Pay, Bonus, Merit, Allowance, and Stock. You will need to load data for any additional pay types via RaaS or flat file.
Compensation Payout (Actual Compensation)	Full	This subject extracts a large number of records. Try a test extraction of three months. If extractions take too long, we recommend uploading flat files.
Pay Change Events	Full
Managed Position	No
Requisition	No
Applicant and Candidate	No
Absence	Limited	The method to get full data coverage for this subject is in Beta. If you’re interested in trying this implementation, contact Visier Support.

Ways to achieve full data coverage

The Workday API does not provide 100% coverage for all the data needed for a people analytics implementation. In particular, it does not expose the transactional logs for non-worker tables, which we sometimes require. This section provides details on the RaaS or flat file supplementation required to achieve full data coverage. For more information on setting up RaaS reports, see Workday Reports-as-a-Service (RaaS).

Organization Core

Worker Manager History

In Workday, managers are part of the Organizations table and not directly tied to the worker. As a result, if the manager is terminated, the direct reports will be unable to detect the change. We recommend that you load this data via flat file or Workday RaaS for full data coverage.

Organization History

No transactional logs available. The API returns the last modified date which is used to build history. The effective date is not returned, so the connector cannot build an accurate history for forward/backdated changes. We recommend that you load this data via flat file or Workday RaaS for full data coverage.

Requisition

The connector cannot get accurate requisition status updates. We recommend that you load this data via flat file or Workday RaaS for full data coverage.

If you want to use this connector to retrieve this data, you will need to supplement requisition status history and custom fields via a RaaS or flat file.

Applicant and Candidate

The Workday API does not:

• Detect changed candidates without extracting all candidates. If the Workday system has a large number of candidates, this will not be a viable solution.
• Return substage information.
• Provide accurate history for non-status changes.

We recommend that you load this data via flat file or Workday RaaS for full data coverage.

Table history for non-workers

The Workday API does not provide transactional data for non-worker tables such as job profile, job family group, and compensation grade. To build history, the connector takes snapshots of the data based on the configured granularity (Daily, Weekly, Monthly). The finer the granularity, the longer the initial historical extraction will take. For most customers, monthly granularity on these tables is sufficient and will extract in a reasonable time.

Workday Reports-as-a-Service (RaaS)

If you know how to build reports in Workday, the Workday Report-as-a-Service (RaaS) connector can be a good alternative to uploading flat files to addressing the gaps in coverage of Workday’s API. Once the report is built in Workday and enabled as a web service, Visier can extract the contents without having to manage flat files.

The Workday reports would need to be built in a way that allows Visier to pull historical data. We expect the reports to be built in one of the following formats:

• Historical: Report should take as input start + end date and return all records that have changed in the given time period. This format allows you to get history over a given date range in a single report.
• Top-of-Stack (Snapshot): Report should take as input a snapshot date and return a snapshot of the records on the given date. This format is easier to build but less performant. This format requires the report to be run many times to build history.

In order to pull history in a reasonable amount of time, each RaaS report should complete in under two hours. Here are some tips for keeping Workday reports performant:

• Build the report from indexed data sources.
• Limit the amount of custom fields in the report (especially for large data sets).
• Avoid using custom fields to aggregate and filter data.
• Order filters that remove the most records first so each subsequent filter operates on fewer records.

Extraction times

Performance factors

The following factors impact the performance of the connector.

Workday Instance Type

The API response time for Workday varies depending on the Workday instance. The average response time can vary between 1-10s depending on the instance. 10s means effectively 10x longer to extract data.

Recommendations:

• Establish a connection to a production instance even for sample extraction as the sandbox instance is significantly slower.
• Upgrade to a more powerful Workday premium account if you are experiencing performance issues.

Number of Employees

The number of active employees and the number of all time employees will factor into the performance of historical extractions. The more employees you have, the more data you’re pulling in.

We recommend you limit the overall amount of history being pulled to reduce the number of historical records being extracted. Most customers find 3-5 years sufficient for their analytical needs

Average number of changes

The average number of changes impacts the number of requests being made each delta extraction.

Recommendations:

• Use Snapshot mode to extract some initial historical data to work with while you wait for granular history to be retrieved.
• Limit per worker history. Extract 1 - 3 years of history so no requests are made to get older historical changes for each worker.

Extraction types and performance

The main performance bottleneck for the Workday API is generally how fast requests take.

Historical vs delta extractions

The first time you onboard a data subject to Visier via the connector an initial historical extraction is done to pull all the records and changes in history, going as far back as needed. Most organizations find 3-5 years will meet their needs. Due to the volume of data, these extractions can take some time to complete.

After the initial extraction is complete, delta extractions are performed, where only changes since the last extract are pulled. Given the smaller number of changes these are much faster.

There may be cases where a subsequent historical extractions are required after the initial extract. For example, if additional fields or tables need to be added to the extract.

Delta extractions

Delta extractions, extractions that only fetch changes in data since the last extraction, will fetch the majority of modified workers with one API request, meaning that even if all employees undergo changes, a company with a population of 10,000 would require only 10,000 requests. In order to properly capture backdated changes, it is necessary to rebuild the history of the employee from the oldest backdated change to the present. This means that the further in the past these backdated changes are, more requests are necessary in order to fully rebuild the history of an employee.

Historical extractions

If you’re extracting a large volume of data (headcount greater than 30K) a full historical extraction will still take a while to complete even with a strong Workday instance. Depending on actual headcount it can take 3 to 7 days, and even longer if requests are slow.

The following table shows the average response times for the get_Workers endpoint for the best onboarding experience. If response times are slower than listed, you may want to consider using another method to load data.

Headcount	Average Response Time
Greater than 30K	Less than 2 seconds
10 to 30K	Less than 4 seconds
Less than 10K	Less than 5 seconds

Snapshot mode

Snapshot mode pulls a snapshot of data at the end of every month for the specified extraction interval. It can speed up the performance of the extraction by limiting the number of requests made to Workday at the cost of data granularity.

Performance benchmarks

The following table shows extraction statistics from organizations that are currently using the Workday connector. Compare the characteristics of your target tenant to estimate the extraction time. These characteristics are just some of the factors that can impact extractions. For more information, see Performance factors. You may encounter additional delays for extractions that take longer than one week to complete due to Workday’s weekly scheduled maintenance window.

Active Employees	Get_Workers Average Time	Historical Extraction Time
0 to 5K	0.5 to 3.0 seconds	1 to 12 hours
0 to 5K	Greater than 3.0 seconds	12 to 36 hours
5K to 15K	0.5 to 3.0 seconds	6 hours to 4 days
15K to 50K	1.0 to 3.0 seconds	1 to 2 weeks
15K to 50K	3.0 to 6.0 seconds	2 to 4 weeks
Greater than 50K	0.5 to 2.0 seconds	1 to 2 weeks
Greater than 50K	2.0 to 7.0 seconds	2 to 8 weeks