Integration Hub
Your engineers never leave their tools.
Integration Hub keeps a traceunified record and its twin in Jira or GitHub in step — continuously, with every field’s direction declared and an answer for a collision settled before it happens. The work stays where the work happens. The evidence stays where an auditor can read it.
Two live integrations with Jira, drawn the way they work — traceunified at one end, the external tool at the other, and what crosses between them.
What it does
Declared, not inferred.
A sync that guesses is a sync somebody has to audit by hand. Four things are stated up front, so what crosses is a decision on the record rather than the behaviour of a job nobody can see.
Every collision has a declared answer
Each paired field declares which way it moves — out, in, or both. Where a field moves both ways, the integration states what settles an edit made on both sides at once: report it and overwrite neither, let one side win, or take the most recent. The clock is refused on any field whose change invalidates an approval, because a timestamp cannot decide a value a signature depends on.
Jira and GitHub, with Bitbucket for code
Jira and GitHub sync items both ways, through connectors built for how each one behaves. Bitbucket Cloud links the commits and pull requests that name an item back to that item — code evidence on the record, with nothing synced. Every connection starts read-only, and writes to the other tool only once an administrator opts it in. A connector is offered only once it has run against a live instance of its tool: a generic REST connector is built and is waiting on exactly that.
No polling to manage
There is nothing to trigger and nothing to switch. Every integration polls on its own, with a daily full scan behind it, so a missed delivery costs latency and never a change. Where the connection’s account can manage webhooks, the product registers its own and keeps it in repair, and edits arrive in seconds. Each connection simply shows which it has — Webhook + poll, or Poll.
The change is on the item, attributed
An inbound edit lands through the same save path as a person’s: a new version of the item and an audit entry, attributed to the individual behind the external account — and held rather than guessed when nobody matches. What the integration does on its own is recorded under the account it is declared to act as, never passed off as a person’s. Sync history records how every cycle went: what it read, wrote and refused.
Every screen
Configure it once. Watch it run.
The Hub is eight screens, and each one answers a single question. Configure is where you decide what moves; Monitor is where you see what the engine could not finish on its own.
Landscape
Every connection, collection and integration in one picture. Click any of them to isolate what depends on it — what stops if you rotate that credential tonight — and open it from there.
ConfigureConnections
Jira, GitHub or Bitbucket, with an encrypted credential and a health check. Each starts read-only, sets up its own webhook, and shows whether changes arrive by webhook and poll, or poll.
ConfigureCollections
Which projects and artifact type, and the item type they become. Fields, picklist values, relationships and attachments are mapped here, and the other tool’s required fields are checked as you go.
ConfigureIntegrations
The object you open and operate: which side creates records, which way each field moves, the routes it covers, a filter on what crosses, how often it looks, and what settles a collision.
MonitorActivity
Everything the engine cannot finish on its own — setup problems with their remedy, links held, failing or orphaned, and writes waiting to be delivered. Retry, abandon or clear, with a recorded reason.
MonitorAccount mapping
An edit from an external account nobody can match waits here instead of being attributed to someone plausible. Map the account once, and its edits carry the right name.
MonitorSync history
One row per cycle: what triggered it, what it read and wrote, and why anything was skipped — with a gap flagged wherever no cycle ever read. An operational record, not the audit trail.
MonitorTrace coverage
A project’s synced items measured against its trace matrix: how many are traced, and which are not — the one question a successful sync never answers.
On the thread
An item that arrives from another tool is not yet on the thread.
The twin is a native record here, so everything the thread does to a record it does to this one — including counting it as a gap when nothing traces it. That matters, because a sync that brought in fifty requirements reports itself as a success whether or not anyone ever traced them, and Trace coverage is the screen that says which.
A requirement pushed to the other tool keeps its identity, version and state on this side.
A test case synced from the other tool is a real test case here — and counts against coverage like any other.
A link drawn in the other tool becomes a real trace here, where your collection maps that relationship. Trace coverage counts the synced items nothing traces and names them, so the gap is found before an auditor finds it.
Stop asking engineering to work twice.
Connect the tool they already use, declare what crosses, and let the record keep itself.