> ## 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. # Data Domains > How Twine segments different kinds of data A **data domain** defines a category of data that Twine can move between systems. Each domain has its own data model, its own sync behaviour, and its own type of domain mapping. When you configure an integration, you choose which domains should flow between which systems. Twine currently has nine domains: Employee records with full property history tracked over time. Departments, divisions, teams, and other nodes in a company's structure. Absence and attendance records, each covering a date range and a time type. Work schedules defining when employees are expected to work. Project entities. Integration support is limited. Customer entities. Integration support is limited. Skills, certificates and licences - the catalogue an organization maintains. Which employee holds which competence, at what level and for how long. Binary file exchange - payslips, agreements, and other documents. *** ## Employee The Employee domain is the foundation of most Twine integrations. Data is modelled as entities with **dated properties** - each property stores values sorted by when they take effect, rather than only the current value. This makes it possible to represent historical data and future-dated changes, though the depth of history available depends on what the source system exposes. Refer to the relevant integration page for details. Full reference for employee properties, grouped by category. *** ## Organizational Unit The Organizational Unit domain covers the structural nodes of a company - departments, divisions, teams, and similar groupings. Units can be nested to form a hierarchy. Like the Employee domain, organizational unit data uses dated properties. Properties and hierarchy reference for organizational units. *** ## Time Report The Time Report domain covers absence and attendance data. Absence is the primary focus: vacation, sick leave, parental leave, and other leave types. Attendance records are also supported where systems provide them. Unlike entity domains, time reports are not modelled with dated properties - each record is a discrete event covering a specific employee over an inclusive date range, referencing a **time type** that describes the kind of absence or attendance being recorded. Time report syncs operate over a **date range** rather than fetching all records. The range can be set as fixed dates or derived dynamically, and is configured in the sync trigger for the domain mapping. Full reference for time report fields, request statuses, and time type traits. *** ## Schedule The Schedule domain covers basic work schedules. *** ## Project The Project domain is supported in Twine but integration coverage is limited. It follows the same dated property model as the Employee and Organizational Unit domains. Project entity reference. *** ## Customer The Customer domain is supported in Twine but integration coverage is limited. It follows the same dated property model as the Employee and Organizational Unit domains. Customer entity reference. *** ## Competence The Competence domain covers an organization's catalogue of skills, certificates, licences and courses - the definitions themselves, not who holds them. Like the Employee domain, competence data uses dated properties. A catalogue entry is identified by its name and type, which is also what Twine matches on to avoid creating duplicates when the same competence arrives from more than one source. Catalogue and assignment properties, and how the two relate. *** ## Competence Assignment The Competence Assignment domain covers the link between an employee and a catalogue entry: the level they hold it at, when it takes effect, when it expires, and who issued it. An employee can hold the same competence more than once - a re-certification is a new assignment rather than an edit. Assignments depend on both the Employee and Competence domains being mapped for the systems involved, because an assignment is written using the target system's ids for both sides. An assignment whose employee or competence is not yet mapped is skipped and reported as an anomaly rather than guessed at. How assignments resolve, the order to configure the three domains in, and what to do about competences that already exist in the target system. *** ## File Transfer The File Transfer domain handles binary file exchange between systems that support file upload and download. Rather than structured data records, this domain deals with documents: payslips, employment agreements, onboarding materials, and similar files. A file transfer domain mapping defines the source system to pull files from and the destination system to push them to. The systems involved must support file operations - not all integrations do. Check the page for a specific integration to confirm file transfer support. Twine itself can be the source. A file uploaded through the API travels through a file transfer domain mapping that has Twine on the source side, which is how an external system - a learning platform issuing certificates, for example - gets a document into an HR system without needing file access to it. Twine does not keep the files it moves. It does keep a record of every transfer, including the identifier the destination system assigned to the document, so you can reference that document later even though the file itself is long gone. Uploading a file through the API, and reading back the identifier the destination gave it.