Connectors as references

A document points at a connected app the same way it cites a policy — by name, from the Connectors row, with a dot that says whether the app is answering.

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 yours: you connect the apps you need and a colleague connects theirs, so this row lists what you have connected. The team selector beside the search does not narrow it further — your own connections are not a team's to divide.

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, 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 every document, 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.

A pointer at one thing inside an app is retired, and its workflow steps are removed

Until October 2026 a workflow's Read a connected source step and its When a source changes start could point at one exact thing inside a connected app — a folder, a saved list, a channel's membership — called a source. Alchex turned that pointer into a call to the app with a hand-written map of each vendor's tools.

That map is gone (October 2026): every app now connects one way, through its maker's own server, and the assistant reaches what is inside it by asking that server's own tools. So a source no longer reads anything, and nothing pretends it does:

the Read a connected source step and the When a source changes start were removed from workflows. A workflow that still has one is refused: saving or publishing it names the step and asks you to remove it, and running one saved earlier fails before any step with the same words;

To read something inside a connected app, ask the assistant.

Which account reads it

A connected app holds a credential per person: when you connect your own account to it (Settings → Connections), what you reach through that app is what your account can reach, not what a colleague's can. You can only point at an app you have connected, and connecting your own account never widens what you can see inside the workspace — only which account asks the app.

Older chips still work

A chip written before September 2026 points at a source rather than at the app. It still wears the name it was given and Open › still takes you to the connection it hangs off; what it pointed at inside the app is no longer read (see above). 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 document itself, which cites it. The Governance list holds documents and registers; New offers its document types and no Evidence; approvals, versions and the history panel no longer have an evidence kind. Old /data addresses land on the Governance list.