Connections a workflow calls
Where a workflow action sends, and the token it sends with.
On this page
A connection is a place this repository can call when a workflow says so: a chat channel, a ticket system, anything that accepts a POST. A workflow action names one by its code, so the token lives here and not in the workflow — which is exported, copied between environments, and read by more people than a token should be.
Before you start
- Connections is in the sidebar, under Administration.
- Everybody signed in can see the list. What a repository is able to call out to is a governance fact, the same kind of fact as the list of sources it reads from. Anybody can see that a connection exists, what it is called, whether it is on, how many workflow actions depend on it, and the host it points at —
https://hooks.example.com/…. - Only Sysadmin sees the rest. The whole address, the token, how the last call went, and every button — add, edit, test, switch off, delete — need Manage users and roles (ACCESS_MANAGE).
Why the address is split that way: a Slack or Teams webhook carries its secret in the path. Showing the whole URL to every reader would be publishing the credential in a different box from the one marked Token. The host answers the question the list exists to answer — where can this thing reach — and the path is the part that lets somebody use it.
This is enforced by the server, not by the screen. The rest of the address is not hidden in a column somebody could look behind; it is not sent.
Add one
- Press Add a connection.
- Give it a Code — short, upper case, and it does not change, because a workflow action names it.
- Give it a Name for people, and the URL to call.
- Put the Token in if it needs one. It is sent as an
Authorization: Bearerheader. - Press Add it.
The token is never shown again, and never leaves the server in an answer or a log. The list says a token is held, when it last changed and who changed it. Saving a connection without typing a token keeps the one it has.
What the list says
| Column | What it tells you | Who sees it |
|---|---|---|
| Connection | Its name, and the code a workflow action uses. | everybody |
| URL / Points at | Where the call goes. Sysadmin sees the whole address; everybody else sees the host and /…. |
everybody, in part |
| Token | •••••• when one is held — hover for when it changed and who changed it — or no token. | Sysadmin |
| Used by | How many workflow actions call it. Deleting one that is used says so first. | everybody |
| Last call | How the last call from a workflow went, with the answer as a tooltip. | Sysadmin — a failure comes back from the far system and can quote the whole request back |
| State | on, or off — a connection that is off is not called, and the run says so instead of failing quietly. | everybody |
Test it
Test sends one POST, the same shape a workflow action sends, with "test": true in it so whatever receives it can ignore it. The screen says what came back — the status, or the reason nothing did. A connection that is switched off is not called; the screen says that instead. Every test is written to the System tab of the activity log, with who ran it and what came back — never the token.