Skip to main content
Four tabs: General, Members, Rules and Errors. The three below are the ones that change what other people — and other things — can do here.

​
Members

Members of a Tylon workspace
The role defines what each person can do — and which statuses they can move a card into. That second half is the one worth reading twice: a role here is not a label, it is the answer the board gives when somebody drags a card into In production.
​
The workspace is theirs, including who else holds it.
​
Promotes. The stages that merge into main name Maintainer as their minimum role on the board.
​
Does the work: starts cards, pushes branches, opens pull requests.
​
Reads.
Iris and Otto are in this list with roles of their own. An agent is a member, so the same table answers “what may this agent do” without a second permission model to keep in step with the first. Invites are a link you hand over — Tylon builds it and does not send the email itself.
The server is the authority. The interface hides what a role cannot do, and hiding a button is convenience, never authorization — the same move made through the API or the MCP server is refused the same way.

​
Rules

Automation rules in Tylon
The mechanical half of the work: assign, label, prioritise, park, say something. Each rule reads as one sentence — When … then … — and the line under it says whether it has ever actually run.
The third trigger is the one most boards cannot express. Sitting still is not an event: nothing happened, and nothing happening for three days is exactly the thing a review queue needs somebody to notice.
Anything that needs judgement is a single action — wake an agent — because a rule that thinks is a rule nobody can predict. When a rule does act, it acts as whoever wrote it, and the card’s story names the rule that did it.

​
API credentials

Making a Tylon API credential
How something that is not a browser reads and writes here — a deploy script, a status page, a spreadsheet. It brings a client id and a secret instead of a person through a sign-in.
​
One or several, each with its own role, the same way you connect an editor. On each board it may do what you ticked and never more than you hold there — and it keeps that whatever later happens to you.
​
read is always there. write lets it open cards, move them, cut branches and promote releases, every write carrying an Idempotency-Key.
The secret is shown once, when it is made. There is no way to show it later without keeping it readable, so have somewhere to put it before you press the button. To roll one over, make a second secret, move the integration across, then revoke the old one — both are live in the meantime, so nothing goes dark during the swap.

The API reference

What to send, which board a request lands on, and how writes stay safe to retry.