The Panel Provider for Workday provides bi-directional integration with Workday, via Workday’s reporting (RAS) API and Workday SOAP APIs.
The Workday provider scans data into Identity Panel primarily via the Workday reports interface. This may be accomplished with global reports or custom reports associated to an individual service account. Multiple reports may be scanned and recorded as separate silos or merged as separate object types within the same silo. Reports may also be selectively filtered via query parameters.
Report data may be augmented by secondary calls to the Workday SOAP API to retrieve data that hasn’t been made available in reports. This is done to retrieve thumbnail photos from Workday. Per-user SOAP API calls support querying on a configurable number of parallel threads and execute via a separate schedule step type for improved performance.
Each Workday report has a fully qualified URL, which includes the Workday host, the tenant id, and the report identifier. All requests are made over HTTPS using the ?format=json query parameter.
Authentication is performed using a service account encoded into a user/password pair and converted to a base64 string, then placed in the HTTP authorization header. This header is passed with each request to the reporting API.
Handling Multiple Reports per Silo
The silo Id for a Workday scan is derived from the Name of the report (from the report name in the provider settings definition), not the URL endpoint. This allows multiple reports to be scanned into a single data silo by giving separate report strips the same Name value. A silo may be populated with a separate object type for each report (e.g. contractor, employee, or (person, location), or different reports my fill the same object type.
In large organizations it is typical for Workday reports to timeout before returning a JSON response payload. Each report in the Workday provider has its own retry count. When a report query fails, the data scan will wait for one minute (to allow the report to continue to build on the Workday backend), then attempt to fetch the report again. This process is repeated up to the specified retry limit.
Key and Reference Fields
For most user reports, the primary key/DN of the record will be the Employee_ID. However, it is possible to configure alternate fields for use in fetching non-person reports, e.g. locations.
Any column names listed in the Reference Fields text box will be converted and treated as references by the data scan. To count as a valid reference, the column must contain values from the key field identified for that silo.
For organizations reading thumbnail photos out of Workday, select the photo scans checkbox for the appropriate person report(s). If photo scanning is enabled, it is expected that each row in that report represent a person, and that the key field contain ID values that are permitted by the Workday Get_Person_Photos SOAP API, such as Universal_ID, WID, Contingent_Worker_ID, or Employee_ID.
Photo Scans run as an independent schedule step type from Workday scans, and may run in parallel with Workday report scans. Because the photo scan must make a separate API call for each user, operations are expected to run much slower than the the regular report scan. To help the performance bottleneck, the photo scan supports a configurable "Photo Scan Threads" count, to allow it to dispatch multiple requests in parallel.
SOAP authentication is performed using the configured service account, with standard SOAP WSS authentication. The service account must be configured with sufficient permissions inside of Workday to access the desired endpoints.
The Workday Provider supports writeback to the SOAP API via fixture actions, e.g. to update a user’s email address, user account information, other ids, phone numbers, thumbnail photo, etc.
Writeback may be used for automated testing with Test Panel, self-service actions via Service Panel, access management via Access Panel, or synchronization via HyperSync.
In order to configure Workday fixtures, you must first create an Export Connection in Providers, and then either choose the import existing providers option, or configure an explicit Workday Connection system.
The workday provider allows writeback with an arbitrary SOAP payload, as well as providing dedicated writeback actions for the following data fields/actions:
- Email address (Primary work, and personal)
- Other ID (State and Badge)
- Phone (work, home, mobile, landline, extension, public/private, etc.)
- User Photo
- User Account name