Skip to main content
Conditions are rules that control which entities are included in or excluded from processing. They act as a filter applied before data is acted upon.

​
Where conditions apply

Conditions can be configured at two levels: If both levels have conditions configured, both must be satisfied for an entity to proceed. Integration-level conditions are evaluated first.

​
Organization-wide conditions

The organization can also hold conditions of its own, under Organization → Conditions. These are named rules over one domain’s records that belong to no integration and no domain mapping, and they never run during a sync. They exist for the Public API: pass a condition’s id as condition_id to the list endpoint of its domain and only the records it passes come back. Each condition decides over one domain, chosen when it is created: employees, time reports, organizational units, competences or employee competences. The rule itself is built on the same canvas as any other condition. Because Twine encrypts record properties at rest, an organization-wide condition is evaluated in the application after each page is read, not in the database. The API reference explains what that means for paging.

​
Condition rules

A condition is made up of one or more rules. Each rule evaluates a property on the entity against a value using an operator. Common operators include:
  • Equal to / not equal to
  • Contains / does not contain
  • Is set / is not set
  • Greater than / less than (for numeric and date properties)
Rules can be combined with AND (all rules must pass) or OR (any rule must pass) logic.

​
Section filters

A condition keeps or drops a whole record. A section filter keeps the record and drops some of its rows. The typical case is a consultant who became a permanent employee: the source system still lists the consultancy as an employment, and you want the person in Twine with only the permanent one. Section filters belong to a source system integration and are set on its Conditions page, under Section filters, with New section filter. They are available where the source system supports them, currently Evity employee data. Each filter names one section of the employee data, such as the employment history, and an expression that is checked for each row. Rows the expression is true for are kept:
The row’s own fields are available by name, and it is the row. employee is the whole employee as the source system returned it, which lets a rule depend on the other rows. This one drops consultancy rows only for people who also have another employment:
An empty expression keeps every row.

​
When section filters run

  • After conditions. Conditions see every row, so a condition that excludes anyone who is a consultant now or in the future works exactly as before. Section filters only apply to the employees that pass.
  • Before the employee is stored in Twine. Removed rows never reach Twine, and so never reach any system Twine sends the employee to.
  • In every sync from the integration, whichever domain mapping starts it, and in the sync preview. The preview lists the rows a filter removed for each employee it changes.
  • Not when inspecting data. “Inspect remote data” shows everything the source system returns, removed rows included.

​
What to expect

  • Employment dates follow the rows that are kept. With the consultancy removed, the hire date is the start of the permanent employment.
  • Turning a filter on changes employees already in Twine on the next sync, and those changes are sent on to the systems Twine writes to. Preview the sync, and the replication to any target that already holds the removed rows, before you rely on it.
  • A rule that cannot be evaluated stops the sync with an error naming the employee. A row is never kept or dropped by guesswork.

​
Conditions on file uploads

File transfers are checked against two sets of conditions, and both must pass before the file is sent:
  • File transfer conditions are evaluated against the file itself, so they can read properties like content_type, size and original_name.
  • Employee conditions are evaluated against the employee the file belongs to. A file uploaded without an employee skips this check rather than failing it.
An excluded file is reported as rejected rather than failed — it was deliberately not sent, so there is no error behind it.

​
Active status filtering

A common use of conditions is filtering by employment status. For example, a destination payroll system may only need to receive active employees. Rather than manually maintaining this list, a condition on active_status ensures that terminated employees are automatically excluded. When an employee’s status changes to terminated, Twine will stop replicating updates for that entity to any mapping that has an active-only condition configured.