Skip to main content
The projects in a Tylon workspace
A workspace holds projects. A project is a product this team ships, and it owns the four things that make a board mean something: its repositories, its cards, its releases and its own flow. The count beside each one is what it is made of — repositories, then cards.
Two projects in one workspace move differently on purpose. A mobile app that ships through a store review and an API that deploys on merge do not want the same stages, and neither is made to pretend otherwise.

​
Inside a project

A Tylon project
Overview, Flow and Repositories — and along the top, the four places the project’s work actually is: its board, its trunk, its backlog, its releases.

​
How it moves

The stages, in order, as a sentence: Backlog → In development → In review → Staging → In production. Edit the flow opens the flow screen, where each of those stages gets its branch rule.

​
What it is made of

The branches Tylon currently owns here — not everything on the provider. That distinction is the point of the panel: 20 branches in flight is work this board is responsible for, and what already landed has left this list for the trunk. Each repository names its default branch and when Tylon last agreed with the provider about it. Under it, one line per branch:
The branch, what it targets, the card it belongs to, the stage that card is in, the pull request and what CI said. Blocked and Waiting sit on the same line, so the reason a branch is not moving is on the row rather than one click away.
A branch pushed with a name the convention does not recognise is not lost — it arrives in the inbox to be adopted onto a card.