Skip to main content
An Organization is the top-level tenant in Twine. Every integration, user, stored entity, and configuration belongs to exactly one Organization. The term is used consistently across the backoffice and the API.

​
Cardinality

An Organization typically corresponds 1:1 with a real-world company. For holding companies and other structures where HR and payroll responsibilities are split across subsidiaries, separate Organizations are sometimes created per subsidiary. The right shape depends on how the underlying source and target systems are organised.

​
What an Organization owns

​
System Integrations

An Organization holds all of its System Integrations - one for each external system Twine connects to, plus an entry for Twine itself. System Integrations are the building blocks that Domain Mappings link together, and they own the property mappings and conditions that govern how each system’s data is handled.

​
Users and roles

Users belong to an Organization and are granted access through roles. A role defines what a user is permitted to do within the Organization. Roles are also the unit through which API access is granted. API keys are issued against a role, and any request authenticated with that key is bound by the permissions of the role it was issued for. Programmatic access and human access share the same permission model.

​
System Data

System Data is a viewer for all the entities Twine has stored for the Organization, browseable per domain (Employees, Organizational Units, Customers, Projects, Schedules, and Time Reports). The Employees view is the most fleshed-out and the most used in practice. From an entity detail view it is possible to:
  • Preview the payload that would be sent to a given target system during replication, where supported.
  • Inspect the corresponding data as it exists in the connected remote systems.
  • Trigger an isolated sync by selecting a Domain Mapping, which spawns a Sync job scoped to just that single entity.

​
Jobs

Every sync run and every replication run is recorded as a Job. Jobs carry the log output, per-pipeline-step timing metrics, and any error output produced during execution. They are tied to a Domain and optionally to a specific end of a Domain Mapping. The two main job types are:
  • Sync - reads entities from a source system, transforms them via property mappings, filters them via conditions, and persists them to Twine. One Sync job is created per sync run.
  • Replication - sends a single entity to a target system. Filters first, then transforms from Twine’s model into the target’s model via property mappings, then performs the API calls. One Replication job is created per entity per target.
A Sync job spawns one Replication job per entity, with two exceptions: when Twine itself is the target the flow terminates at persistence, and when a file-based source writes to a file area destination the file is produced as part of the Sync job and no per-entity Replication jobs are spawned.

​
Anomalies

Anomalies are detected data issues, optionally scoped to a System Integration and/or Domain Mapping. They come from two sources: built-in checks that run when sending data to a target (which halt the pipeline for the affected entity if a required value is missing or invalid), and Data Engine anomaly nodes that customers can add to their graphs to flag custom conditions. Some anomalies clear automatically when the underlying issue resolves; others have to be cleared manually in the backoffice.

​
Templates

A Template is a reusable copy of a System Integration’s property mappings. Templates are useful for vendor customers who repeatedly onboard new customers on the same source systems - rather than rebuilding the mappings from scratch, an existing template can be applied to a new System Integration to skip that setup work. Templates only contain property mappings; they never include credentials or domain mappings.

​
Notes

Notes are freeform text notes scoped to the Organization. They are typically used to capture context, action items, or anything else worth recording at the Organization level.

​
Logs

The Logs area surfaces audit and request traces relevant to the Organization, such as the ledger requests that record changes to stored data over time.

​
Notifications

Notifications are delivered as email and configured at the Organization level. There are two kinds today:
  • Anomaly digests - configured with an optional System Integration scope, a list of anomaly codes, a digest interval, and a list of recipient Users.
  • System Data Events - a digest listing entities that were created or updated. Currently supported for the Employee domain only.

​
General settings

Organization-level settings define behaviour that applies across all integrations within the Organization. The most notable example is custom property definitions - any custom properties available on the Employee data model (or other domains that support them) are declared at the Organization level so they can be referenced consistently by every System Integration. The Employee Number Generator is also configured at the Organization level. It produces employee numbers according to a configured rule, used when a destination system requires a number that the source system does not provide.