Source and destination
A domain mapping always involves exactly two System Integrations - one as the source, one as the destination. Either one can be Twine itself:- Twine as destination - Twine acts as a terminator. Data is fetched from the source, mapped, and stored in Twine’s database. The flow stops there. This is the typical setup for vendor customers who want to expose data through Twine’s API.
- Twine as source - Twine acts as the originating system. Data stored in Twine is read and pushed to an external destination. This is how vendor customer integrations are completed on the outbound side.
Source domain and target domain
Every domain mapping declares a source domain - the type of data being read - and a target domain - the type of data being written. In most cases these are the same, for example reading employees and writing employees. Twine also supports asymmetrical domain mappings, where the source and target domains differ. An example would be reading from the Employee domain and writing to the Schedule domain. Asymmetrical mappings are rare and the correct behaviour depends heavily on the specific systems and use case involved. They should always be discussed with Twine support before being configured. The File Transfer domain is a notable exception: file transfer mappings are almost always asymmetrical by nature - a file is either parsed into structured entities, or entities are serialised into a file for delivery.Sync triggers
A domain mapping can have one or more sync triggers that control when it runs. The only current exception is the Manual Upload integration, which allows a file to be uploaded in the backoffice and forwarded to a receiving file transfer or file-based integration (such as Hogia Lön Plus). Manual Upload mappings have no sync triggers at all - the upload itself is what initiates the flow.Sync Triggers
Scheduled, webhook, and manual triggers - and how the Time Report domain handles date ranges.
Conditions
Domain mapping conditions filter entities for that mapping only. An entity that does not meet the condition is excluded from this mapping’s processing but is not affected in Twine or in other mappings. Conditions can also be configured at the System Integration level, where they apply to all data handled by that integration regardless of which domain mapping is running.Conditions
How to define rules that include or exclude entities from processing.
Pre-processors
Some domain mappings support pre-processors, which constrain or reshape local data before it is sent to the target system. The most common use case is date range constraining: limiting the data Twine sends to a target to a specific time window, regardless of the full history available in Twine. This is typically used when a customer has migrated to a new source system but is keeping an existing target system (such as payroll). If the historical data quality in the new source is uncertain, a pre-processor can be configured so that the target system only receives data from a specific date forward - as if all employees started on the same date. This avoids overwriting clean historical data in the target with potentially unreliable data from the new source. Pre-processor support varies by domain. Not all domain mappings have pre-processor options available.Data merging
A domain mapping can be configured with per-section sync behavior that controls how Twine reconciles locally-computed records with the records already present in the remote system. This is most relevant for multi-valued, date-tracked sections such as salaries and employment periods, where the desired behaviour - keep, append, amend, or overwrite - depends on the target system and the use case. The Diff Engine is the component that performs this reconciliation and computes the minimal set of changes to write.Diff Engine
How records are reconciled, the available per-section settings, and how system capabilities constrain them.