Integrating Workday with Greenhouse
Workday is a leading human capital management with various modules and processes for optimized business management. Greenhouse similarly leads the applicant tracking space with strong recruiting software and automation potential for hiring teams. Although Workday does have Workday Recruiting available to customers, the simultaneous leveraging of both Workday & Greenhouse is becoming increasingly popular as customers look to leverage the best of both systems. With these two systems & any two systems, strong, seamless integration is required for complete system harmony.
My thoughts below are intended to provide a starting point for teams implementing either system to integrate with the other or teams that are struggling with their current integration stability. Our goal, as always, is to reduce manual intervention and increase system balance with strong mapping, logic, and error handling.
There are several key design questions to ask when reviewing Workday x Greenhouse architecture:
1- Are you position management or job management? What is the life cycle of a position?
Position Management - imagine building the role and specific restrictions around it for a position within an organization (a COO, Director of Finance, Support Analyst, etc.).
Use case example: Corporate headquarters with a stable and planned organization structure. You know the roles you need to fill. You are preparing seats that people can come in and fill. You know exactly the amount of people within that specific organization.
Pros: Much more reliable accounting and workforce planning can be achieved. You have more control over how the role should be filled (weekly hours, compensation targets, qualifications, etc.).
Cons: You will need to create the position (the “seat”) before you move someone into it. With job management, you create the entire role around the person within the role. This can be seen as an inflexibility or a form of governance around your headcount management - it only depends on philosophy and how your team is prepared to handle it.
Job Management - Use case example:A chain restaurant company with temporary and/or seasonal employees. A somewhat unpredictable structure while workers may rotate in and out due to high turnover.
Pros: No need to painstakingly keep up with positions being opened and closed constantly for a high-turnover workforce/organization.
Cons: Position history is lost. Position and budget control is a toss up. Theoretically, you have unlimited room to hire as many employees as you would like. There would need to be more control around hiring in this model.
Either model can be made to work for any organization, but fine-tuning goes a long way. You could also use a hybrid model where you are using both position and job management, but it would be imperative that your administrators fully understand the concept and can facilitate transactions properly. This is obviously nowhere near the amount of detail needed to make a decision, but it may be a good starting point if you are thinking about implementing or transitioning to a new staffing model.
2- What types of transactions will be entered into Greenhouse and expected to flow automatically into Workday?
Let’s start with #1.
The life cycle of a position as it pertains to new hires starts with position creation. Here are a few questions to start that conversation:
1- When you open a new role, where will the team enter it first?
2- If Workday, will the entry point have enough information to provide Greenhouse for public posting?
3- If Greenhouse, will the entry point have enough detail to provide to Workday for hire?
Assuming the position will be created in Greenhouse first, there are several integration options to ensure stability.
1- A Workday Studio or Middleware can take the Position in Greenhouse and create the position in Workday at the time of hire. With this option, it’s very important that the position ID is inline between both systems. In our experience, the integration typically '“checks” to see if the position exists in Workday already before updating or creating.
2- A user will enter the same position into Workday manually after Greenhouse creation.
If you plan on integrating Workday and Greenhouse transactions, we must emphasize the importance of the identifiers aligning for accurate matching between the two systems. This will prevent duplication or incorrect staffing in your Workday tenant.
If you’d like the position to initiate in Workday, there are three options for this to be loaded to Greenhouse:
1- Your team purchases HRIS Link from Greenhouse, which will automatically pull positions into
Greenhouse for creation/updates using a Workday custom report every 15 minutes.
2- A Workday Studio is embedded in your position business processes OR scheduled to create/update Greenhouse using their Harvest API.
3- A user enters the same position into Greenhouse manually after Workday creation.
There are pros and cons to each approach around both complexity and cost as well as post-production support. Our recommendation varies based on budget, team skill set, and technical architecture. For example, if a client does not have the budget for HRIS Link but does have a Workday Studio developer in-house or leverages Stormloop Services for integration support, we’d recommend the Studio route. If HRIS Link is a viable option that fits the business needs, we do recommend exploring this approach to position creation across systems.
For #2, Greenhouse does not have an API that directly connects to a Workday tenant. A tool between the two systems is required to translate the Greenhouse payload into the Workday XML for processing OR the hire must be keyed in manually.
A key complexity driver here is the transaction type list in scope for Greenhouse. Some clients only process new staffing events in Greenhouse for hires but will do internal transfers and contractor conversions directly in Workday. Others will do everything in Greenhouse and desire the integration to automate these on the Workday side. The approach taken here has significant scope implications and is worth several design sessions with the recruiting, onboarding, and technology teams before deciding the best approach. Our same recommendation methodology holds true here. I recently completed a project for a client with no in-house Studio expertise but significant Informatica skills internally. Rather than build a Workday Studio, we built the entire inbound integration, notifications and all, on the Informatica platform.
We do have a Workday Studio that is pre-built with Workday and Greenhouse web services for expedited implementation but simply provide this as an option before pursuing the most scalable solution for our client. Each client has a unique requirement and requires careful design early in project discussions.
Other key questions worth considering are:
1- Will the integration need to update any custom objects in Workday on the pre-hire or worker
object?
2- Will the employee ID be stored or be entered in Greenhouse for reference in an integration to process re-hires? This is encouraged to prevent duplication.
3- What types of documents will need to flow into Workday and what are their document categories?
4- Which users need to be notified of integration results, and what type of information do they need? This is most commonly set as an email notification from Workday with candidate and recruiter information.
5- Should any business process components auto-complete?
This all, of courses, assumes integration connectivity between the two systems. Manual entry is always an option but may not be scalable for growing teams with a global presence.
Overall, the Stormloop team is thrilled for the future of both systems. We look forward to learning more about how clients are using each to better provide functional and technical support throughout the implementation process and ongoing support.
Follow Scott on Linkedin here: https://www.linkedin.com/in/scott-rushton-3aa945a3/
Follow Stormloop on Linkedin here: https://www.linkedin.com/company/40761570/
