Datasource integration with Workday

Workday is a cloud-based enterprise software platform that delivers human capital management (HCM), financial management, and analytics capabilities. Its HCM module is designed to streamline and unify core HR functions such as talent management, payroll, benefits, and workforce planning, providing real-time insights and automating many HR processes.

As such, an enterprise's Workday HCM environment usually contains much if not all of the HR-related data of that customer enterprise. To export this data for uses external to Workday itself, Workday provides (among other solutions) the Enterprise Interface Builder (EIB), which can generate files of an arbitrary form, in one of many formats, containing only the data specified by the user, of only the objects specified by the user, in a user-specified format, on a configurable schedule.

Since much of the data held in Workday HCM can be relevant for skill inference, we have therefore developed a standard file-based integration that can take in these EIB files and load their contents into the SkillEngine API. From this data, we can then infer the skills of or needed for the related Employees, Jobs, and more. These skills are then available in the TechWolf SkillEngine API, but can i.a. also be pushed back into Workday using the Workday Employee Skill Sync.

Prerequisites

To have access to the Workday datasource integration, at least the following prerequisites must be met:

You have the appropriate TechWolf API licenses.
You have the appropriate SkillEngine API credentials, which include:
- Tenant ID
- Tenant secret
- Tenant name
- Region (Europe or United States)
You have a TechWolf API tenant set up that contains the relevant information for the requested output integration.
Both you and TechWolf have access to the agreed input location.

Setup

Setting up the standard Workday-to-TechWolf datasource integration comprises only two aspects. On one hand, EIB exports must be set up within Workday with specifications that match those required by TechWolf, which are explored in more detail below. On the other hand, communication and agreement with TechWolf on some key aspects of the integration and some details about the EIB exports must exist; in particular, the cadence with which the exports are made and delivered, the location at which the exports will be delivered to TechWolf (presumed to be a directory on your TechWolf S3 bucket), the format in which the files will be delivered to TechWolf (XML, CSV, ...), and the exact way in which the exports correspond to the input required by TechWolf (insofar as the EIB setup does not match the default specification).

EIB specification

Below, an overview is given of the standard EIB specification expected by TechWolf. Some important notes to give on this are the following:

All files are presumed to be full dumps, i.e. the state of all relevant entities is expected to be given in each export file, not just the changes compared to the last export.
Not all files are necessarily required, though existing dependencies must be respected. For example, if the basic information of employees (i.e. their existence) is already synced, it is optional whether to include e.g. employee goals as well; yet when employee goals are to be synced, the employee baseline sync must be included as well. An overview of the dependencies is given in the Dependencies section.
All expected fields can be provided under another name, or split among different fields, as long as this division or rename is then used consistently (and is communicated to TechWolf). This applies to both the fields marked as "required" as those that are marked as "optional". When multiple input fields are taken together to form one expected (or additional) field, the resulting field will consist of the values of the constituent fields, separated by a hyphen surrounded by spaces (" - "). Additionally, some field conversions are also supported; in particular, dates can be converted to the required format, and arbitrary string-to-string mappings can be configured, which can be particularly useful in combination with field filtering (mentioned below). Possible limitations specified on fields always apply after transformation.
Fields that are marked as "required" are generally expected to always be present (after transformation). However, there is also support for "default values", though this only applies to certain fields (marked with *). Setting defaults should be avoided, since it makes data less informative, and should only be used in cases where it is unavoidable and doesn't cause unnecessary obfuscation or decreased informativeness. One use case could be to set all certificate descriptions to be "-" by default if no actual certificate descriptions are available, but the certificate titles are still informative enough to warrant syncing certificates.
The integrations support field filters: per input file, one field can be chosen to act as a filter (besides possibly also carrying information to be synced), where the input object (xml objects, csv row, ...) is only processed if the value of the filter field is either contained in the given whitelist of values or not included in the given banlist of values. Note that filtering is completely optional and that filtering is applied after input transformation. Do note that TechWolf always prefers filtering at the EIB where possible, to prevent unnecessary data transfer and processing.

Job Families

Field name	Field description	Required?	Limitations
job_family_id	The id of the job family in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹.
job_family_name	The name of the job family.	YES	Must be at least 1 and at most 255 characters long after being trimmed.
job_family_inactive	Whether the job family is active ("0", default) or inactive ("1").	NO	The job family is treated as inactive if and only if the value of this field is "1".
job_family_group_name	The name of the job family group.	NO	Must be at least 1 and at most 255 characters long after being trimmed, or absent altogether.

Job families can also be extended with an arbitary amount of "profile data", which will be used for skill extraction. There is one type of job family profile data available: job_family_description. For every profile data variant, we need the following information:

The name of the source field(s) in the input (and their ordering, in case of concatenation)
The profile data type (job_family_description)
Whether the profile data should always be present (true or false)

Job families can also be extended with an arbitrary amount of "custom properties", which will NOT be used for skill extraction, but might be useful for querying or other identification, grouping or disambiguation scenarios. For every custom property, we need the following information:

The name of the source field(s) in the input (and their ordering, in case of concatenation)
The name of the custom property (at least 1 and at most 100 characters; cannot contain "__")
The data type of the custom property ("text", "number", "boolean", "list[text]" or "datetime")
Whether the custom property should always be present (true or false)

Jobs (Job Profiles)

Field name	Field description	Required?	Limitations
job_id	The id of the job in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹.
job_name	The name of the job.	YES	Must be at least 1 and at most 255 characters long after being trimmed.
job_inactive	Whether the job is active ("0", default) or inactive ("1").	NO	The job is treated as inactive if and only if the value of this field is "1".
job_family_id	The id of the job's job family.	NO	Will be slugified if present; must be at least 1 and at most 100 characters long after being trimmed and slugified¹, or absent altogether. If a job family id is given, a job family with that id MUST exist.

Jobs can also be extended with an arbitary amount of "profile data", which will be used for skill extraction. There are four types of job family profile data available: job_description, job_title, vacancy, skill_notes. For every profile data variant, we need the following information:

The name of the source field(s) in the input (and their ordering, in case of concatenation)
The profile data type (job_description, job_title, vacancy or skill_notes)
Whether the profile data should always be present (true or false)

Jobs can also be extended with an arbitrary amount of "custom properties", which will NOT be used for skill extraction, but might be useful for querying or other identification, grouping or disambiguation scenarios. For every custom property, we need the following information:

The name of the source field(s) in the input (and their ordering, in case of concatenation)
The name of the custom property (at least 1 and at most 100 characters; cannot contain "__")
The data type of the custom property ("text", "number", "boolean", "list[text]" or "datetime")
Whether the custom property should always be present (true or false)

Vacancies (Job Requisitions)

Field name	Field description	Required?	Limitations
requisition_id	The id of the vacancy in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹.
job_id	The id of the job related to the vacancy in TechWolf.	NO	Will be slugified if present; must be at least 1 and at most 100 characters long after being trimmed and slugified¹, or absent altogether. If a job id is given, a job with that id MUST exist.
job_title	The job title of the vacancy.	YES	Must be at least 1 and at most 255 characters long after being trimmed.
job_description	The job description of the vacancy.	YES*	Must be non-empty after being trimmed.
job_requisition_inactive	Whether the vacancy is active ("0", default) or inactive ("1").	NO	The vacancy is treated as inactive if and only if the value of this field is "1".

Vacancies can also be extended with an arbitrary amount of "custom properties", which will NOT be used for skill extraction, but might be useful for querying or other identification, grouping or disambiguation scenarios. For every custom property, we need the following information:

The name of the source field(s) in the input (and their ordering, in case of concatenation)
The name of the custom property (at least 1 and at most 100 characters; cannot contain "__")
The data type of the custom property ("text", "number", "boolean", "list[text]" or "datetime")
Whether the custom property should always be present (true or false)

Employees (Workers)

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹.
assigned_position_id	The id of the employee's current job in TechWolf.	NO	Will be slugified if present; must be at least 1 and at most 100 characters long after being trimmed and slugified¹, or absent altogether.

Employees can also be extended with an arbitrary amount of "custom properties", which will NOT be used for skill extraction, but might be useful for querying or other identification, grouping or disambiguation scenarios. For every custom property, we need the following information:

The name of the source field(s) in the input (and their ordering, in case of concatenation)
The name of the custom property (at least 1 and at most 100 characters; cannot contain "__")
The data type of the custom property ("text", "number", "boolean", "list[text]" or "datetime")
Whether the custom property should always be present (true or false)

Employee Certifications

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. An employee with this id MUST exist.
timestamp	The timestamp at which the skills related to the certification become relevant for the employee.	NO	Defaults to creation time of the related skill event within TechWolf.
certificate_title	The title of the certificate.	YES*	Must be at least 1 and at most 255 characters long after being trimmed.
certificate_description	A textual description of the certificate.	YES*	Must be non-empty after being trimmed.

Employee Education History

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. An employee with this id MUST exist.
timestamp	The timestamp at which the skills related to the education become relevant for the employee.	NO	Defaults to the education end_date (if this exists), or else the education start_date (if this exists), or else the creation time of the related skill event within TechWolf.
degree_name	The title or a short description of the degree.	YES	Must be non-empty after being trimmed.
school	The institution responsible for the education.	NO	Must be non-empty after being trimmed, or absent altogether.
start_date	The start date of the education.	NO	Must be a valid date or datetime in IS08601 format after being trimmed (or converted into such during input transformation), or absent altogether.
end_date	The end date of the education.	NO	Must be a valid date or datetime in IS08601 format after being trimmed (or converted into such during input transformation), or absent altogether.

Employee External Work History

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. An employee with this id MUST exist.
timestamp	The timestamp at which the skills related to the work experience become relevant for the employee.	NO	Defaults to the work experience end_date (if this exists), or else the work experience start_date (if this exists), or else the creation time of the related skill event within TechWolf.
job_title	A formal title that describes the job function.	YES	Must be at least 1 and at most 256 characters long after being trimmed.
job_description	A formal title that describes the job function.	NO	Must be non-empty after being trimmed, or absent altogether.
company	The company offering the job.	NO	Must be at least 1 and at most 256 characters long after being trimmed, or absent altogether.
start_date	The start date of the work experience.	NO	Must be a valid date or datetime in IS08601 format after being trimmed (or converted into such during input transformation), or absent altogether.
end_date	The end date of the work experience.	NO	Must be a valid date or datetime in IS08601 format after being trimmed (or converted into such during input transformation), or absent altogether. Only relevant if the job is not still ongoing.

Employee Internal Work History

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. An employee with this id MUST exist.
timestamp	The timestamp at which the skills related to the work experience become relevant for the employee.	NO	Defaults to the work experience end_date (if this exists), or else the work experience start_date (if this exists), or else the creation time of the related skill event within TechWolf.
job_id	A formal title that describes the job function.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. A job with this id MUST exist.
company	The company offering the job.	NO	Must be at least 1 and at most 256 characters long after being trimmed, or absent altogether.
start_date	The start date of the work experience.	NO	Must be a valid date or datetime in IS08601 format after being trimmed (or converted into such during input transformation), or absent altogether.
end_date	The end date of the work experience.	NO	Must be a valid date or datetime in IS08601 format after being trimmed (or converted into such during input transformation), or absent altogether. Only relevant if the job is not still ongoing.

Employee Feedback

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. An employee with this id MUST exist.
timestamp	The timestamp at which the skills related to the work experience become relevant for the employee.	NO	Defaults to the creation time of the related skill event within TechWolf.
description	A textual description of the feedback.	YES	Must be non-empty after being trimmed.

Employee Goals

Field name	Field description	Required?	Limitations
employee_id	The id of the employee in TechWolf.	YES	Will be slugified; must be at least 1 and at most 100 characters long after being trimmed and slugified¹. An employee with this id MUST exist.
timestamp	The timestamp at which the skills related to the work experience become relevant for the employee.	NO	Defaults to the creation time of the related skill event within TechWolf.
description	A textual description of the goal.	YES	Must be non-empty after being trimmed.

Dependencies

The Workday datasource integration can be deployed partly, not necessarily syncing all data detailed above. However, not any arbitrary combination of synced entity types and skill event types is possible. The graph below gives an overview of the dependencies between the integration parts, where the arrows represent "is needed for" dependencies, i.e. an integration part cannot be active unless all integration parts leading into it are active. Dashed arrows represent "soft dependencies", i.e. dependencies for optional "foreign key"-like fields. The primary identifiers of the main objects in a file are bold, optional fields are italicized.

Dependency graph

Coming soon

Support for mapping organisational structure from Workday Supervisory Organizations to TechWolf Organisational Units using the standard Workday datasource integration.
Support for transaction-based delta syncs, where only the difference with the state at the time of the previous export is communicated.

Slug strings are strings consisting of only lowercase letters, uppercase letters, numbers, underscores (_) and dashes (-).

When non-slug strings are slugified at TechWolf's side, we use a mapping as defined in slugify, except for the following mappings:
- "/" becomes "_SLASH_"
- "(" becomes "_OPENR_"
- ")" becomes "_CLOSER_"
- "[" becomes "_OPENS_"
- "]" becomes "_CLOSES_"
- "{" becomes "_OPENC_"
- "}" becomes "_CLOSEC_"
↩