MyRapidi
MyRapidi
Menu

Search our Wiki

Workday Schema Structure and Field Management

Alongside the REST WebService connection, every Workday integration uses a JSON schema that describes the objects and fields available in the customer's Workday environment. This schema is what makes the integration flexible: it's read by the integration layer, and it can be extended by the customer without any development work.

Why a schema instead of hardcoded mappings

Workday customers frequently add custom fields to their reports over time (a new cost center attribute, a new custom ID, and so on). If field mappings were hardcoded, every such change would need a developer to update and redeploy the integration. Instead, the schema acts as a live contract: as long as it accurately describes the report, new fields become available to map as soon as the schema says they exist.

How the schema is structured

The schema has one definition per Workday report/endpoint, named to match the endpoint exactly. Each definition contains a definitions block listing every field in that report, and a properties block that references them.

Each field entry typically includes:

  • description – what the field represents
  • example – a sample value, useful for documentation and for anyone mapping the field later
  • type – e.g. string
  • format – where relevant, e.g. date
  • readOnly – whether the field is read-only (true for essentially all Workday report output, since these are read-only report rows)

Example field definition:

"Hire_Date": {
  "description": "Employee's hire date.",
  "example": "2022-03-14",
  "readOnly": true,
  "format": "date",
  "type": ["string"]
}

There is also a shared context definition (tenant alias and report path) used for connection-level metadata rather than report data itself.

One schema for all endpoints

There is only one schema per tenant, covering every object/endpoint in use, not a separate schema per report or table. Each one just gets its own definition inside that same schema file. This is what allows the whole integration to run through a single REST WebService connection: since one Metadata URL already describes everything, there's no need to set up a separate connection for each endpoint.

The customer's workflow for adding a new field

This is the core benefit of the approach:

  1. Customer's Workday admin adds a new field to the relevant custom report in Workday.
  2. Customer (or whoever manages the schema) adds a matching field definition to the JSON schema: name, description, type, format, example.
  3. The schema is saved back to its hosted location (referenced by the REST WebService's Metadata URL).
  4. The integration picks up the new field automatically on the next read of the schema. It's now available for mapping into the target system, no code change, no new release, no ticket to Rapidi.

The only requirement is that the schema stays in sync with the actual report output. If a field is removed from the Workday report but left in the schema, or vice versa, mapping will fail or return unexpected results, so schema maintenance is a shared discipline rather than a one-time setup step.

Where the schema is hosted

The schema is hosted as a static JSON file on GitHub and referenced by URL in the REST WebService's Metadata URL field. Any stable, publicly (or securely) reachable JSON endpoint works; GitHub Pages is convenient because it's version-controlled and easy for a customer's technical team to edit and publish changes to.