Connectors as references

A sentence in a procedure often means a system rather than another document — the tickets we raise in Jira, the joiners list we keep in the HR drive. A connector reference is how that sentence points at the thing itself: the connected app, by the name you gave it, citable from a document exactly the way a policy or a register is.

The point of pointing at it rather than describing it is that the pointer stays true. Rename the connection, reconnect it with a different account, and every sentence that cites it follows — nobody edits prose to keep up with an integration.

What you cite

The connected apps themselves — the rows on your Connections page. Each carries:

• A name — what you called it when you connected it, or the app's own product name if you did not rename it. It is the name the chip in your text shows.
• A connector — which product it is, and therefore what it can read. Shown as provenance under the name, never as the title, so two connections to the same app do not read as one thing twice.
• An account, when the connection runs as one, which is what tells those two apart.
• A state — connected, or not answering.

A connection is workspace-wide: everyone on the workspace sees the same list, so the team selector beside the search does not narrow this row. That is unlike every other row in the picker, and it is deliberate — narrowing would hide apps the team can perfectly well name.

There is nothing to create first. If you have connected an app, it is already citable.

Citing one: the Connectors row

Press / in a document and choose Mention. The reference picker opens on its usual rail — Policies, Procedures, Work instructions, Manuals, External documents, Registers, Controls, Risks — with Connectors at the bottom.

The Connectors row lists your connected apps, by name, each showing its connector and the account it runs as, and each carrying a dot for whether it is answering. Typing narrows on the name and on the connector, so jira still finds the connection somebody renamed Engineering tickets.

Pick a row and it lands in your text as a chip wearing the app's name. It is the same rail on a document and on a control, and the same picker the citation block's Add button opens. See References for everything a chip does once it is in your text.

An app that is not answering is still listed, greyed with its reason rather than hidden. Naming the system a procedure relies on is not the same act as reading through it — a policy can cite the ticket system perfectly well on a day its credential needs renewing — and a list that quietly shortened itself would tell a workspace with three connected apps that it had two.

What the chip's dot means

A connector chip carries the same aliveness dot every chip carries:

• Green — the app is connected and answering.
• Amber — it is not: disconnected, or its credential needs renewing. The chip keeps the app's name so you can see which system has gone quiet, and the popup says which it is.
• No alarm — nothing has been observed, or the app is one you cannot see. Silence is not a verdict, so it is never painted as one.

Click the chip and the popup answers for the app: its name, its connector, the account it runs as, and its state in words. Open › goes to it on the Connections page, where its credential and permissions live.

What a workflow reads is a narrower thing

A workflow's Read the records step — and the When a source changes start beside it — do not read a whole connected app. They read one exact thing inside it: a folder, a saved list, a channel's membership. That narrower pointer is a source, it is a separate record from the connection, and it is set on the step. A control that reads a system as an audit input reads the same kind of record.

So the two are related and not the same: a sentence cites the system your procedure relies on, and a step reads one thing inside that system. Citing your ticket system in a policy does not aim a workflow at a particular board.

⚠ There is no screen that makes a source right now. The one that offered it went in August 2026, with an earlier version of this row, and a step that needs one has its ids set as JSON until it returns. Sources that already exist are untouched: steps read them, control audits grade against them, and chips citing one still resolve, still carry their own dot, and still open.

Removing a source is not refused because a document cites it — a citation that can no longer resolve states itself in red on the chip carrying it, which is better than chasing somebody into a document to tidy a chip before letting them act. There is one exception, and it protects other teams' audits: a source a control reads cannot be removed by an ordinary member. The refusal names what to do — detach it from the control first, or ask a workspace admin.

Older chips still work

A chip written before September 2026 points at a source rather than at the app. Nothing about it changed: it wears the name it was given, its dot reports that source's own last verdict, the popup names what it reads, and Open › takes you to the connection it hangs off. Both kinds of chip live in the same documents, and neither disturbs the other.

Evidence records are gone

Until September 2026 there was a separate record kind called an evidence record — a proof with its own page, its own EVD- code, its own versions, approvals and proof-pack export — sitting in the Governance list beside documents and registers. It is removed.

What it did is now done by the two things that were always underneath it: the connected app, which is what a document points at, and the control, which is where a source is attached and graded. The Governance list holds documents and registers; New offers six types and no Evidence; approvals, versions and the history panel no longer have an evidence kind. Old /data addresses land on the Governance list.

If a control of yours read an evidence record, it now reads the connected source directly — the same source, one hop shorter. See Controls and evidence for how a control's sources are attached and what an audit does with them.