> ## 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.

# Conditions

> Filtering data entities based on rules

**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:

| Level                  | Scope                                                                                          |
| ---------------------- | ---------------------------------------------------------------------------------------------- |
| **System Integration** | Applies to all data handled by that integration, across all domain mappings that belong to it. |
| **Domain Mapping**     | Applies only to data flowing through that specific domain mapping.                             |

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

## 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.

## Conditions on file uploads

[File transfers](/platform/other/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.