/
Workday Custom Report

Workday Custom Report

Report-as-a-Service (RaaS) access

Report-as-a-Service (RaaS) allows access to Workday custom reports as web services. When you enable a Workday custom report as a web service, the report results can be accessed through URLs.

  1. Log in to the Workday tenant.

  2. In the Search field, type View custom report.

  3. On the View Custom Report screen, click My Reports.

  4. Select the report you want to view. Click OK.

  5. On the View Custom Report page, click Actions > Web Service > View URLs. Make sure Report is Web Service enabled. Edit Report, Go to Advanced Tab, Check “Enable as Web Service” option.

  6. Click OK.

  7. For REST, on the View URLs Web Service page, in the JSON section, right-click JSON, then Copy URL. The URL format will be something like below:

    https://wd2-impl-services1.workday.com/ccx/service/customreport2/mytenant/report_owner_username/report_name?format=json&Last_Updated=2023-10-01&Department=Sales

Use the output from the report to map fields in the trigger mapping section. The reportuser and reportname combination should be provided in the “report_name” property. Report filter values can also be setup as shown below.

report_name:report_owner_username/report_name filter:Last_Updated={last_successful_date_time} filter:Current_Time={current_date_time} filter:Department=Sales key:WorkerID=customfield_10128 map:Worker=customfield_10122 map:Title=customfield_10123 map:Cost_Center[0].Reference_ID=customfield_10010

Note: The filters are the ones that the custom report expects. Filter fields should be String, Date or Numeric fields, and not Objects which expect Reference ID values. Other filter smart values supported are {last_successful_date}, {current_date_time} and {current_date}.

Mock Endpoint for Testing

To test Workday Custom Report, here’s a mock endpoint and report:

API Endpoint URL = <contact us at support@onwardb.com> API version = v40.1 Tenant name = <contact us at support@onwardb.com> Username = <contact us at support@onwardb.com> Password = <contact us at support@onwardb.com>

Use the below for mapping configuration in your Workday Custom Report trigger:

key:WorkerID=customfield_10128 report_name:lmcneil/get_worker map:Worker=customfield_10122

Incremental Data Extract

OnRamp can pull data from any Workday Custom Report that’s enabled as a RaaS (Report as a Service). These reports should return incremental data so that only new events (hires, terminations, job change, etc) are processed. Reports in Workday can be setup for incremental data output in one of two ways. Filtering by effective date or by entry date. Effective date (e.g. Hire Date) based filtering will cause records to appear multiple times in the report output. For instance if you filter for workers with Hire_Date in next two weeks, then that worker will appear in every scheduled run until the hire date is in the past. On the other hand, filtering on entry date (event initiated or completed date) will ensure that records are returned only once - only when the event completed date meets the scheduler time filter.

One common approach is to use the Event details that accompany any object. For example, in this report we show how the Hire Event can be accessed on any worker. The sub-filter can then be set based on the hire completion date. Other objects have associated events you can pull in the report e.g. All Positions has Hiring Event sub-object, All Job Requisitions has Job Requisition Event, and so on.

Here’s the sub-filter:

 

Another approach is to use the data source: Business process Transaction. This allows you to extract incremental data with the filter set to date and time completed.

 

Here’s the filters section of the report that filters on the hire event completion date:

Another useful filter is the “Last Functionality Update” - this is a field that’s available on most objects and can be used to return data whenever an object is changed.

Here you can see the same field on the Positions object.

Jira Issues - Create or Update

Normally every new record in the Workday custom report output ends up as a new ticket. However, there are instances when you may need an existing ticket to be updated e.g. the hire (or termination) date is pushed out. In this case it makes sense to to update a previously created ticket rather than creating a new one. 

There are other more long running scenarios too e.g. an employee gets a promotion in February and OnRamp creates a new issue which is processed and completed. Nine months later, another Change Job is initiated as the employee’s location has changed. In this case, a new issue should be created.

Another scenario would be a hire (processed by OnRamp) leaves the company. After some time the employee returns to the company and is rehired with the same employee ID. In this case, again a new issue should be created for the second hire instead of updating the previous issue.

To handle all these scenarios, we recommend you use the Business Process Event WID as the key for OnRamp. The ‘wid’ will stay the same when a business process is ‘corrected’ or ‘rescinded’ so it will handle the above scenarios gracefully.

If, for some reason, your business processes do not support the use of wid, here are a couple of other suggestions:

  1. Create a key that is unique not just employee level, but at the "event" level. For example, you may consider a key that concatenates employee id with position ID. Again assuming position id is new on rehires, this will ensure the rehire is created as a new ticket.

  2. If you always want OnRamp to create a new ticket in Jira, then you can set this below config line: config:ignore_update_check=true

 

Related content