Employee
Employee records with full property history tracked over time.
Organizational Unit
Departments, divisions, teams, and other nodes in a company’s structure.
Time Report
Absence and attendance records, each covering a date range and a time type.
Schedule
Work schedules defining when employees are expected to work.
Project
Project entities. Integration support is limited.
Customer
Customer entities. Integration support is limited.
Competence
Skills, certificates and licences - the catalogue an organization maintains.
Competence Assignment
Which employee holds which competence, at what level and for how long.
File Transfer
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.Employee data model
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.Organizational Unit data model
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.Time Report data model
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 data model
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 data model
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.Competence data model
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.Competence data model
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.File transfers
Uploading a file through the API, and reading back the identifier the destination gave it.