Skip to main content

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 below:
  • 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 (csv row, xlsx 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.

slugify

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_“

Job Families

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)

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)

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)

Courses

Courses 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)

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

Employee Education History

Employee External Work History

Employee Internal Work History

Employee Feedback

Employee Goals

Employee Learning History

Employee Learning History records the Courses an Employee has completed. Each record references a Course by its id, so the corresponding Course must be synced as well.

Employee Resumes