Identity and access management
Deel to Google Workspace integration: Google accounts for a team in many countries
With an integration between Deel and Google Workspace, everyone hired through Deel, as own employee, EOR employee or contractor, gets a Google account in the organisational unit for that type of worker, with manager and team. On the last working day in Deel the account is suspended, and a contract withdrawn before the start leaves no account behind.
What the integration does
Anyone who works in Google Workspace with colleagues partly through their own entity and partly through Deel often only creates accounts when the new colleague shows up. Contractors often keep their account after their assignment ends.
- After a contract is signed, Deel reports the new person. KoppelHet creates the Google account, suspended until the start date.
- The type of worker decides the organisational unit, and with it which apps and policy apply.
- On the start date the account becomes active, with team, manager and groups.
- When team or manager change in Deel, the details and groups in Google follow.
- On the last working day KoppelHet suspends the account and transfers the files to the manager.
What to watch for with Deel and Google Workspace
- Deel returns the direct manager's work address for every person, and Google records the manager with that address. KoppelHet therefore sets the relationship directly, even if the manager works in another country.
- Employees, EOR employees and contractors each go into their own organisational unit in Google. Contractors can then for example not share files outside the domain, while own employees can.
- Deel reports a new colleague on signing, often weeks before the start. KoppelHet creates the account then but keeps it suspended until the start date, so the address is known for the invitation without anyone being able to sign in yet.
- If a contract in Deel is withdrawn before the start, KoppelHet deletes the unused Google account. Google charges a suspended account like an active one, so we do not leave it.
- When a contractor moves to the own BV, Deel creates a new contract, but the person stays the same. KoppelHet keeps the Google account tied to the person, so mail and files remain; only the organisational unit changes.
- Deel disables a webhook after ten failed delivery attempts. KoppelHet monitors this and compares the active people in Deel with the accounts in Google every day.
This integration is also part of joiner, mover, leaver.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Does the integration see salaries in Deel?
No. We only request access to people and organisation data.
Does this also work with Microsoft 365?
Yes, we build that integration too.
What can be traced afterwards for an audit?
Every action of the integration is recorded in the audit logging of the KoppelHet platform. KoppelHet works with an ISO 27001 certified management system.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Deel is read through the HRIS People API (worker_id, preferred_first_name, preferred_last_name, job_title, department, hiring_type, person_status, direct_manager.work_email, employments with termination_last_day and is_user_contract_deleted) and signed webhooks (x-deel-signature, HMAC-SHA256).
- Google is written through the Admin SDK Directory API (users with externalIds, name, primaryEmail, orgUnitPath, organizations, relations type manager, locations and suspended; groups and members) and the Data Transfer API for Drive. Access through a service account with domain-wide delegation.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Deel | Field in Google Workspace | Notes |
|---|---|---|
worker_id | externalIds (type organization) | Per person, not per contract |
preferred_first_name of first_name | name.givenName | |
preferred_last_name of last_name | name.familyName | |
Naamgevingsregel | primaryEmail | |
hiring_type | orgUnitPath | Employees, EOR or contractors |
job_title | organizations.title | |
department.name | organizations.department en groepen | |
direct_manager.work_email | relations (type manager) | |
Land van het dienstverband | locations | |
termination_last_day | suspended = true |
Related
Ashby → Deel
Ashby to Deel integration: hires at the own entity as direct employee in Deel
Bullhorn → Deel
Bullhorn to Deel integration: first placement as a direct employee with a contract in Deel
Carerix → Deel
Carerix to Deel integration: successful placement as a person or contract in Deel
Deel → 4PS Construct
Deel to 4PS Construct integration: own employees of the construction entity in 4PS, with department and cost centre as dimensions