Fivetran feature request - expand OData navigation properties (SAP SuccessFactors connector)

Connector: sap_success_factors_loves_prod -> Snowflake database FIVETRAN_PROD, schema SAP_SUCCESS_FACTORS_LOVES_PROD Related ticket: 401921. That ticket has the same root cause. It covers JobApplicationStatusAuditTrail on our test connector. Date: 2026-11-02

Summary

The connector lands SAP SuccessFactors OData navigation properties as __deferred placeholders, not as values. We need specific navigation properties expanded with $expand. We also need each related entity's key flattened into a scalar column.

This request lists every table and column our current reporting needs. We are not asking for all navigation properties to be expanded.

The ask

For each navigation property listed below:

1. Request it with $expand.
2. Return only the related entity's key, using $select (for example externalCode) to keep the payload small.
3. Land that key as a scalar column in the destination, beside the existing navigation column.

For example, FODepartment would be requested as follows:

GET /odata/v2/FODepartment
      ?$expand=parentNav
      &$select=externalCode,startDate,parentNav/externalCode

The result would land as a scalar column such as parent_external_code.

Please backfill every expanded column across the table's full history. Do this with a historical re-sync when the expansion is enabled or inform the customer they need to manually resync the table themselves. A key that lands only on rows synced after the change leaves the history unusable. That is what happened on JOB_APPLICATION_STATUS_AUDIT_TRAIL (see below).

The connector has done this before, more than once. Two examples on our own connector:

• JOB_APPLICATION.CUSTOM_JOB_APP_STATUS arrives hydrated on every row.
• JOB_APPLICATION_STATUS_AUDIT_TRAIL gained three scalar keys from expanded navigation properties, starting with syncs on 2026-10-15. The keys are JOB_APPLICATION_ID, JOB_APP_STATUS_ID and JOB_APP_STATUS_SET_ID.

So this request asks for a pattern that already works in the connector, applied to more properties.

What lands today

The table below shows every column in this request, measured on the production connector on 2026-11-02. "Pure stub" means the value's only key is __deferred.

Priority 1 - organisational assignment on JobRequisition

We need the organisation each requisition was raised for. Every one of these columns is a placeholder on all 173,479 rows today.

We do not need hiringManager expanded. JOB_REQUISITION_OPERATOR already gives us the hiring manager's user id.

A related type defect: JOB_REQUISITION.COST_CENTER_ID and JOB_REQUISITION.POSTALCODE are TEXT columns. On all 173,479 rows they hold the __deferred placeholder text, not a value. Please check whether these are navigation properties landing in scalar-typed columns. If they are, please expand them in the same way.

Priority 2 - organisational hierarchy on the foundation objects

We need these parent links to roll departments up to divisions, divisions up to business units, and cost centers up to their parents. Every one is a placeholder on every row today.

The scalar half of each of these pairs is absent, for example a plain parent column. In 107 other scalar-and-navigation pairs in this schema, the scalar half lands correctly. So the only route to these values is the navigation property.

Priority 3 - job code to job function

POSITION.JOB_CODE lands as a scalar. We cannot map it to a job function, because the job classification object (FOJobCode) is not available in the connector. We would accept either of two fixes:

• Option A: make FOJobCode (the fo_job_code table) available to sync, with its jobFunction field. Support has already acknowledged that fo_job_code is missing from the supported-schema documentation.
• Option B: expand POSITION.CUSTOM_JOB_CODE_NAV (jobCodeNav) and return jobCodeNav/jobFunction as a scalar column.

Ticket 401921 follow-up - backfill JOB_APPLICATION_STATUS_AUDIT_TRAIL

Thank you for expanding jobApplication and jobAppStatus on this table. The keys you added are correct. The history was not backfilled, though, so the table is still 99.3% unusable.

The keys are correct where they exist

These figures cover the rows that carry keys, read on the production connector on 2026-11-02.

The history has no keys

Keys appear only on rows synced since 2026-10-15. Rows synced before that date were never re-landed. The audit trail goes back to 2014-05-08, so almost all of the funnel history is still unattributable.

Two details make us want your confirmation before a re-sync:

• No old event has ever been re-read with the expansion. Every keyed row was created on or after 2026-10-15. So we have no evidence yet that the API returns the related application for older events, including events from 2014.
• The expansion was not applied consistently at first. 6,091 rows synced between 2026-10-15 and 2026-10-26 still arrived keyless. Those events were created between 2026-10-14 and 2026-10-25. Every row synced from 2026-10-27 onward carries keys.

What we are doing: we are running a historical re-sync of JOB_APPLICATION_STATUS_AUDIT_TRAIL ourselves.

The ask:

1. Please confirm that the re-sync requests every row with the expanded jobApplication and jobAppStatus properties.
2. If SAP returns no related application for some older events, please tell us how those rows will land.
3. Please tell us what changed between 2026-10-15 and 2026-10-26, when 6,091 newly synced rows still arrived without keys.

We will report the post-re-sync key coverage back on this ticket. We list it beside the new expansions because one fix to navigation-property expansion, with a backfill, covers all of these tables.

Two smaller observations on the same table

• LAST_MODIFIED_DATE_TIME carries no time of day on any row. Every value is midnight. CREATED_DATE_TIME does carry a time, on 16,528,217 rows. Please check whether the time part is being dropped from lastModifiedDateTime.
• REV_TYPE is null on every row. SAP's API Reference Guide lists revType as a scalar property of this entity.

How we measured

All figures were read from the production destination (FIVETRAN_PROD.SAP_SUCCESS_FACTORS_LOVES_PROD) on 2026-11-02. We used read-only aggregate queries over every row, not samples. A value counts as a placeholder when its JSON object has exactly one key, __deferred. We can share the queries.