Skip to main content
This page is part of an early release. Detailed information about Twine’s integration with this system is being prepared and will be filled in shortly.

​
Writing employees to Hibob

Hibob can be the target of an employee domain mapping, not just a source. Twine writes two things: the employee’s own fields, and new entries in their salary table. Only the fields you have mapped are written. Everything else on the employee is left exactly as it is, so mapping one field will never blank the rest of the record.

​
The employee must already exist in Hibob

Twine does not create people in Hibob. An employee has to exist there and be matched to the Twine employee before anything is written; unmatched employees are reported instead of created. This is because Hibob’s API has no way to record a hire event. An employee created through it would have no lifecycle history, and would immediately read back as inactive on the next sync. Create people in Hibob, then let Twine keep their details up to date.

​
Salary history can be added to, but not changed

Twine can add salary entries that Hibob is missing — including ones dated before every entry Hibob already holds, which is the usual case when moving payroll history in from another system. Hibob works out each entry’s end date itself, so a backfilled salary slots into the timeline correctly. Twine will not modify or remove an existing salary entry. Hibob offers no way to edit one in place; the only route would be to delete it and add it back, and between those two steps Hibob treats the employee as being back on their previous salary. Rather than risk that, a changed salary is reported as a warning naming the employee and the date, and the entry is left for you to correct in Hibob.
If a salary looks wrong in Hibob, fix it there. Twine will not fight you for it, and the next sync will not undo your correction.

​
Email addresses are not changed unless you ask

An employee’s email address is their login identity in Hibob, so Twine leaves it alone by default even when it is mapped and differs. Turn on Allow email address updates in the integration’s settings to let it through. Every other mapped field is written regardless of that setting.

​
First runs are slow

Hibob accepts far fewer writes per minute than reads. A first run that backfills salary history across a few hundred employees can take the better part of an hour. The sync is correct and picks up where it left off — it is simply paced by Hibob. Later runs, which usually write little or nothing, are unaffected.

​
Documents

Twine can write documents to Hibob three ways, and Hibob files every one of them under an employee — there is no organization-level document store, so a file with no employee cannot be delivered here. The first two share a configuration; a Flow does not. They are described separately below because the fields, and the rules for which value wins, are genuinely different.

​
Upload settings, for domain mappings and the API

How the document is filed is not a setting on the domain mapping. It comes from property mappings that write to Hibob’s File transfer side: upload_target has no default because Hibob has no neutral place to put a document — confidential and shared are different visibility levels, and picking one for you would be a guess about who is allowed to see the file. A mapping that does not set it fails the delivery with a message saying so, before anything is sent. A constant is usually the right mapping for all three. Map them from the employee only when the answer genuinely differs per person — for example filing contracts as confidential but certificates as shared.

​
Letting the caller choose

To decide per upload rather than per integration, send the choice in the File Transfers API’s metadata and read it back out:
Map upload_target from File transfer → File transfer with an Attribute node on metadata followed by an Extract node on target. Anything the caller sends in metadata is readable this way, so the same pattern works for upload_file_name and upload_overwrite.
Give the mapping a fallback if you use this — an upload that omits the key produces no value, and a missing upload_target fails the delivery.

​
Two mappings can set them, and one wins

These fields can be written from either of two property mappings, because both have Hibob’s File transfer as their target side:
  • File transfer → File transfer, evaluated against the uploaded file, so it can read the file’s own name, size and content type.
  • Employee → File transfer, evaluated against the employee the document belongs to.
Where both map the same field, Employee → File transfer wins — including when it produces no value. A mapping on the employee side that evaluates to empty for a particular employee overrides the file-side value rather than falling back to it, so that employee’s upload fails on a missing upload_target while everyone else’s succeeds.If you map a field on the employee side, make sure it produces a value for every employee.
Use one side or the other for a given field unless you specifically want that override behaviour.

​
In a Flow

Hibob’s Upload document step is configured on the step itself and ignores the property mappings above entirely. It takes the file from an assign and offers two ways to say where it goes:
  • Target — a dropdown listing the Shared and Confidential folders plus any custom folders in your Hibob account.
  • Target assign — an assign holding a folder’s id or its exact name. Reserved words shared and confidential work here too.
Where both are set, Target assign wins; the dropdown is ignored. Setting neither fails the step with a message saying so, as does a Target assign naming a folder Hibob does not have. Overwrite behaviour is not offered here: the step always uploads. Filing a document under a name that already exists leaves you with two of them.

​
Documents that already exist

This applies to the domain mapping and API routes only; a Flow step always uploads. If a document with the same name is already filed against the employee and upload_overwrite is off, Twine does not upload it a second time. Over the API the transfer still reports delivered — the document you wanted in Hibob is in Hibob — but with no remote_id, because no upload happened and Hibob was never asked for an identifier. remote_metadata.note says as much. Turn overwrite on if you need the identifier back every time.

Hibob changelog

Notable changes to the Hibob integration over time.