Key Concepts

Most companies end up with a web of point-to-point integrations: HR to payroll, HR to the identity provider, time tracking to payroll, and a spreadsheet somewhere in the middle. Every new system multiplies the connections, and every vendor change breaks something. Twine replaces that web with a hub. Data is read once from a source system, normalised into a single model, and distributed to every destination that needs it. Add a system, and you connect it to the hub rather than to everything else. This page introduces the handful of concepts you need to understand how that works. Each one links to a deeper reference in the Platform section.

​

Systems and system integrations

A system is an external product Twine can talk to: an HRIS, a payroll system, a time tracking tool, an identity provider. Twine ships with a growing catalogue of them, focused on the Nordic market. A system integration is one customer’s connection between Twine and one system. It holds the credentials, the field translations, and the filters that are specific to that system. An organization has one system integration per system it wants Twine to reach. Because both ends are separate, a system integration is written once and reused everywhere. The HRIS integration is the same whether its data goes to payroll, to an identity provider, to a time tracking tool, or to all three at once. Any supported system can act as a source. Systems with write capabilities can also act as a destination, and the same integration can be a source for one kind of data and a destination for another.

​

Data domains

Twine does not move “data” as one undifferentiated stream. It segments it into data domains: employees, organizational units, time reports, schedules, competences, projects, customers, and file transfers. Each domain has its own model, its own sync behaviour, and its own configuration. This matters in practice because domains are configured independently. You can sync employees from your HRIS to payroll every hour, pull time reports from a scheduling tool once a day, and leave the other domains switched off entirely.

​

A date-tracked data model

Twine’s model is built around when a value takes effect, not just what the value is today. Every property on an entity is stored as a list of dated properties, each with a value and the date it becomes valid. A salary is not a number. It is the number it is today, the number it was last year, and the number it becomes at the next review. The same goes for job titles, departments, employment terms, and cost centres. This is what makes retroactive corrections and future-dated changes work correctly instead of silently overwriting history. Twine can only record the history a source system actually exposes, so the available depth varies by integration.

​

Property mapping and the Data Engine

Every source system describes the same concepts differently. Property mapping is the translation layer between a system’s own fields and Twine’s model. Simple fields map one to one. Fields that need reshaping run through converters, or through the Data Engine: a node-based editor where you connect typed nodes into a graph to derive a value. Concatenate names, parse a date out of a string, look up a code in a table, compute a percentage, fall back to a default. No code, no deployment, and the same graph is testable against real data before it goes live. The Data Engine handles transformation. Its sibling, the Flow Engine, orchestrates whole processes with side effects: fetch, transform, write, branch, loop, log.

​

Domain mappings

A domain mapping is the actual connection: one source system integration, one destination system integration, one domain. It is the unit you turn on when you want employee data to start flowing from your HRIS to your payroll system. An organization typically has several. The same source can feed many destinations, and each destination receives data in the shape it expects, independently of the others.

​

Triggers and conditions

Sync triggers control when a domain mapping runs: on a cron schedule, in response to a webhook from the source system, or manually on demand. Conditions control what gets through. They filter entities before processing, so consultants never reach payroll, or terminated employees stop being provisioned in the identity provider. Conditions can sit on a system integration, where they apply to everything it handles, or on a single domain mapping.

​

Putting it together

A typical setup reads like this:

1. An organization connects its HRIS and its payroll system, creating a system integration for each.
2. Property mappings on the HRIS integration translate its fields into Twine’s model. Property mappings on the payroll integration translate Twine’s model into what payroll expects.
3. A domain mapping in the Employee domain connects the two.
4. A sync trigger runs it every hour. Conditions exclude the employee categories payroll should never see.
5. Twine fetches, maps, stores the result as dated properties, and replicates it to payroll.

Adding a third system later means one more system integration and one more domain mapping. Nothing about the existing flow changes.

​

Visibility

Integrations fail in ways nobody notices until payroll is wrong. Twine records every sync as a job with its full log, and surfaces problems it can recognise as anomalies: a missing mapping, an unparseable value, a record the destination rejected. Both are visible in the app, and anomalies can be routed to email digests.

​

Building on Twine

If you are an HR tech vendor rather than an end customer, the hub is the product. Integrate once with Twine’s public API and read normalised data from every system your customers use, instead of building and maintaining an integration per vendor.