Community

Add first_name, last_name, email, work_email columns to the PEOPLE table - Deel (Lite) connector

Pedro Coura User

July 08, 2026 20:42

What we need: Add worker name and email to the Deel (Lite) connector ideally as first_name, last_name, email, work_email columns on the existing PEOPLE table. (Alternatively, materialize the already-listed people_email / contract_worker_alternate_email tables with real rows but columns on PEOPLE is the cleaner outcome for us.)

Use case: We use this connector as the HRIS source for an automated User Access Review (UAR) pipeline that reconciles Snowflake and Fivetran user accounts against the HR roster by work email. With no name/email field anywhere, the connector can't support UAR, offboarding automation, or any identity / HRIS-join use case.

What we verified (queried in Snowflake as ACCOUNTADMIN, so no masking / role filtering):

PEOPLE has 20 columns, all job/org metadata, no first_name, last_name, email, or work_email.
id, external_id, and hris_organization_user_id are opaque UUIDs, no human-identifiable key to join on.
Across 945 rows, external_id is never an email, and for contractors it's populated in only 1 of 129 rows — so there is no alternate join key either.
people_email / contract_worker_alternate_email never materialize; your engineering confirmed (tickets #384804, #393850) they are "parent-level operation markers" with 0 real rows.

This is not a source-data gap: confirmed with Deel Deel (Malcolm Woodbury, Systems Integrations) confirmed on a shared thread that worker emails do exist on their side for sample workers they can see both work and personal emails on file and are exposed via the /people/{id}/emails endpoint. Deel's explicit recommendation was that "Fivetran should contact Deel to make adjustments to their connector." The data and endpoint exist, and Deel is ready to coordinate; please reach out to them to add the /people/{id}/emails mapping to the Lite connector.

Impact/scope: 945 workers in PEOPLE: ~625 direct employees (coverable via our Dayforce connector) + 189 EOR + 129 contractors. The contractors, and likely the EOR workers, exist only in Deel and cannot be reconciled without name/email from this connector. Contractors are in scope for our UAR, so this is a hard blocker.

Minor: If these tables can't be materialized, please stop reporting people_email / contract_worker_alternate_email as "extracted" in the sync dashboard; it implies data is arriving when none lands.

Please sign in to leave a comment.

Comments

1 comment

Pedro Coura User
- July 08, 2026 20:55
Hi team
Quick update before your engineering team spends time on my previous question,

we think we've found a likely source-side cause that re-scopes what I'm asking for.

Deel's API docs and their developer community indicate that when a Deel access

token is generated with "Hide all personally identifiable information (PII)" or

"Hide sensitive employment information" enabled, fields like first_name,

last_name, email, and work_email are omitted entirely from the /people response

(not null the fields are absent). That matches exactly what we're seeing, and

it's consistent with your engineering's finding that "no source data is currently

being returned for people_email / contract_worker_alternate_email." In other

words, the connector may be working as designed, and the PII is being stripped at

the token level before Fivetran ever sees it.

We're going to regenerate the Deel token with those PII options disabled and

re-sync on our side first.

So my earlier question ("is there a plan to add worker name/email to PEOPLE?") is

likely premature. The re-scoped question is: once the Deel /people response

includes first_name, last_name, email, and work_email, will the Deel (Lite)

connector automatically:

1) populate the existing people_email table, and/or

2) surface name/email columns on the PEOPLE table?

Or is additional connector-side mapping required even when the source returns

those fields?

Please keep this ticket open, but no need for heavy engineering effort on "adding

name/email" until we confirm the token change on our side. I'll report back with

results after the re-sync.

Thanks,

July 08, 2026 20:55

Hi team
Quick update before your engineering team spends time on my previous question,

we think we've found a likely source-side cause that re-scopes what I'm asking for.

Deel's API docs and their developer community indicate that when a Deel access

token is generated with "Hide all personally identifiable information (PII)" or

"Hide sensitive employment information" enabled, fields like first_name,

last_name, email, and work_email are omitted entirely from the /people response

(not null the fields are absent). That matches exactly what we're seeing, and

it's consistent with your engineering's finding that "no source data is currently

being returned for people_email / contract_worker_alternate_email." In other

words, the connector may be working as designed, and the PII is being stripped at

the token level before Fivetran ever sees it.

We're going to regenerate the Deel token with those PII options disabled and

re-sync on our side first.

So my earlier question ("is there a plan to add worker name/email to PEOPLE?") is

likely premature. The re-scoped question is: once the Deel /people response

includes first_name, last_name, email, and work_email, will the Deel (Lite)

connector automatically:

1) populate the existing people_email table, and/or

2) surface name/email columns on the PEOPLE table?

Or is additional connector-side mapping required even when the source returns

those fields?

Please keep this ticket open, but no need for heavy engineering effort on "adding

name/email" until we confirm the token change on our side. I'll report back with

results after the re-sync.

Thanks,