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 data merge settings that control how Twine reconciles locally-stored values with values found in the remote system during pipeline execution. This is most relevant for multi-valued fields such as salaries, where the desired behaviour (replace, append, deduplicate, etc.) depends on the customer’s intent.Data merging is a complex topic and will get its own dedicated page. This section is a placeholder.