> ## Documentation Index > Fetch the complete documentation index at: https://docs.twine.se/llms.txt > Use this file to discover all available pages before exploring further. # Platform Overview > How Twine moves, transforms, and distributes data between systems Twine is an integration platform that connects your business systems - HR, payroll, time tracking, identity providers, and more - and keeps their data in sync. You define what data should flow where, and Twine handles the rest. ## How data flows **1. Fetch** - Twine reads data from a source system as-is, in whatever shape that system exposes it. **2. Map** - Each property from the source is mapped to a Twine property. There are three ways a mapping can work: * **Direct (1:1)** - the source value is used as-is. * **1:1 with converters** - the source value passes through one or more converters before being stored. Converters handle type coercions (string to date, float to percentage) as well as system-specific transformations that only make sense for a particular integration. * **Data Engine (or Graph Engine for legacy setups)** - a node-based pipeline derives the final value from zero or more source properties. Because the engine can emit a constant with no inputs at all, it covers cases that can't be expressed as a simple field mapping. The result of this stage is a fully mapped entity in Twine's data model, stored in Twine's database. **3. Replicate** - Once an entity is stored, Twine spawns a replication job for each destination system configured in the domain mapping. Each destination receives the data in the format it expects, independently of how other destinations consume the same data. ## Configuration primitives Twine exposes a small set of building blocks that you combine to describe any integration: Domains segment data by type - for example, employee profiles, employment terms, or salary. Each domain defines what data Twine tracks and how it is structured. A domain mapping connects a source system to a destination for a given domain. It tells Twine which data to fetch, how to map fields, and where to send the result. Property mappings translate fields from a source system's data model into Twine's internal representation, and from there into whatever the destination expects. Triggers control when Twine runs a sync - on a schedule, in response to a webhook, or manually on demand. Conditions filter data entities before they are processed or distributed, so that only relevant records reach each destination. Twine's two node-graph engines: the Data Engine for pure transformation and the Flow Engine for orchestrating multi-step processes with side effects. ## The data model Twine's internal data model is built around employees as the primary entity. Most data that flows through Twine describes some aspect of a person's employment - their role, their salary, their schedule, their identity. A key characteristic of this model is that many properties are **date-tracked**: rather than storing only the current value, Twine records values by when they take effect. This makes it possible to represent historical data and future-dated changes - though the depth of history available depends on what each source system exposes. Refer to the relevant integration page for details. Learn how Twine models employee data, including how dated properties work.