Integrations
The object you open and operate — eight aspects that decide what is created, which way each field moves, what is in scope, how often it checks, and what settles a collision.
An integration is what actually moves. It runs one collection against one external tool, on its own schedule. The Integrations list draws each one as a wire between traceunified and the other tool — arrowheads show the direction, and while it runs, packets travel the wire and its disc turns.
Each row has one control, and it toggles. Run starts the integration and dispatches a cycle straight away; Pause stops it. There is no separate “poll now”: to make a running integration catch up, pause it and run it again. Bulk Actions runs a cycle over several integrations at once. An integration with nothing routed cannot be started, because there is nothing for it to sync; stopping is never refused.
Open one and its behaviour is split into eight aspects.
Overview
Which projects it covers, how many routes it has, and which item type it carries.
Artifact creation
Which side may create records in the other:
- Outbound — a traceunified item creates its twin in the other tool.
- Two-way — either side creates for the other.
- Inbound — the other tool’s artifacts become traceunified items, and nothing is created there.
The screen states the consequence of the style you choose. An item created from another tool has no approval history and no author here; its origin is recorded as the integration and the administrator who chose the style.
Field flow
For every mapped field, whether it moves out, in, or both ways. The declared list is the policy: saving replaces it whole, and a field left undeclared follows the collection rather than a hidden default.
Widget flow
The same question for attachments, comments and relationships.
Routing
Pairs a traceunified project — or a folder or set within it — with a project in the other tool. Nothing travels until a route says so, and a route carries exactly one item type, so the scope of a sync is something you can point at.
Filtering
Which items on a route are eligible, in your own field names: is, is not, contains, does not contain, is empty, is not empty. A blank filter admits everything on the route, and the screen shows exactly what each cycle sends.
Change detection
How often the engine asks what changed. By default it polls every five minutes, with a full scan every 24 hours behind it, and both intervals are set here. The poll always runs — a missed webhook costs latency, never a change. Where the product has registered a webhook for the connection, edits arrive in seconds on top of it; which one a connection has is shown on the connection, not chosen here.
Conflict resolution
What settles a two-way field that was edited on both sides in the same cycle. The screen says, for each answer, whose work it discards:
- Report the collision — the default. Neither side is written, nothing is lost, and the collision is reported on the run until somebody settles it.
- traceunified wins — ours is written over theirs.
- The external tool wins — theirs is written over ours, including onto a controlled record; the item’s version history still holds the edit it replaced.
- Most recent wins — the later timestamp decides. It is refused on any field whose change invalidates an approval, because a clock cannot decide a value a signature depends on, and it falls back to reporting when either side gives no modification time.
Who can open it
Integrations are organisation-wide configuration, and are available to organisation administrators.