Workday Integrations Made Easy Part 1: No Complex SQLs

April 24, 2013 Appirio

By Vikas Wadhwani


In a typical implementation, there can be as many as 60-70 integrations to and from other systems, e.g, integrations to talent management, real estate partner, benefits partners, EEO reporting, LMS and many more. In a legacy platform, building this would have required significant effort, but fortunately Workday it is far simpler. What was so challenging about integrating with on-premise systems?In legacy ERP systems a developer would typicallyhave to write complex sqls to retrieve data out of a database, transform that data based on consumer requirement and then create an output file. Writing SQLs on a product database to extract data is a complex task because it requires that a developer understand usage of tables, columns, primary key, foreign key, stored procedures, functions, and more. ERP systems are complex and so are their databases. Since integrations have dependencies on databases, it requires that developers must to do an impact analysis of integration before every upgrade, ouch! So, how has Workday made integrations easier?

Workday has come up with the idea of Data source (collection of related objects) and objects (collection of sub-objects and fields). Data source is typically self explanatory as long as business meaning of common terms like Employee, Contingent Worker, Title, Payroll, Base pay, Allowance, Bonus, LOA is understood.

In order to build an outbound integration in Workday you need to create a custom report based on the Data source object. You can access objects like Worker, Payroll, Allowances, Benefits on this custom report. You will also be able to access fields within these objects on the report, for example, the Worker object will have fields like First name, Hire date, Marital status, Home address, and more. You can also add filter criteria to your report based on these fields and object, for example, (Worker type = Employee and Hire Date more than 01/01/2013).

You also have the capability to filter data on user input, for example, a user might want to provide employee status as input to a report and would like to see only employees with the status provided. Once you have built the report, you can run it immediately, as well as, add temporary filters on any field to limit the data displayed on your browser. The screenshot below shows how the Data source, object, fields and filters can be accessed on a report. Once you are done with the report, you can transform it to an output file or make the report as a service (RAAS) and you are done with building your integration.


To conclude, here are few benefits of building a integration in Workday over legacy systems.

  • To extract data out of Workday you do not need to connect to a database. All the data is already available to you in Workday tenant via Data source.
  • You do not need to write complex SQLs on database tables extract desired data, instead you need to write custom report and access user friendly objects and fields to access data. You don’t have to be a SQL developer to build custom report in Workday.
  • You do not need to write complex joins and filter clauses to get to desired result, instead in Workday, related objects are pre-linked and you can add filter criteria on your custom report in a user friendly manner.

Stay tuned for part 2 and 3 of this blog where I am going to write about “No more object oriented programming” and “How writing webservice is a breeze in Workday”

Previous Article
Cloud Metrics Launches on AppExchange
Cloud Metrics Launches on AppExchange

by Naoki Tsukamoto (@nikes63) We are excited to announce that after being run hundreds of times, Appirio Cl...

Next Article
Enabling State & Country as Picklists in Salesforce – Part 2
Enabling State & Country as Picklists in Salesforce – Part 2

by Matt Lamb (@SFDCMatt) In Part 1 of this post, we outlined the process of enabling the new State and Coun...