In short.
Workflows are the process rules in Collabase Projects. A project defines its own statuses with a category, allows exactly the transitions you intended, and sets per work item type which fields are required. Approvals hold a flow until somebody decides.
Your own statuses per project
Name, colour and order are set by the project, and the columns follow them
Three categories
To do, in progress and done carry the backlog, the burndown and velocity
Only permitted transitions
A governed workflow allows exactly the paths you defined
Field rules per type
Required, hidden or in a fixed position, per work item type
When a case skips the approval because nothing holds it back.
A case counts as done although the review is still outstanding. A bug report arrives without the steps to reproduce it. Both are questions of process: which stations exist, which path between them is allowed, and which fields have to be filled before anything moves on.
- 01
Work jumps straight to done although a review belongs in between.
- 02
A bug report arrives without the details nobody can reproduce it without.
- 03
An audit lacks the evidence that the intended path was followed.
What you gain.
01
Statuses that match your stations
In review, with the specialist unit, waiting on the customer: every project creates its own statuses, with a name and a colour. Each one belongs to one of the three categories to do, in progress or done, and Collabase computes backlog, burndown and velocity from that. The order in the settings is the order of the columns on the board.
Name, colour, order · The category carries the maths
02
Free choice or a governed path
Free choice is the default: a work item may move into any status. For audited processes you define per status where it may go from there. Every other move is refused, on the board and through the API alike. That is what evidences that the intended path was followed.
Transitions per status · Applies through the API too
03
Types across three levels
A work item type carries a name, an icon and a colour. Types created globally are available in every project, the space adds its own, the project adds more again. Each level adds, none overrides the one above, so the shared set stays intact while one team adds its speciality.
Global, space, project · Adds instead of overriding
04
The fields a type demands
Per type a rule decides whether a field is required, stays hidden or sits in a fixed position. A bug demands the steps to reproduce; an epic needs no story points. A hidden field cannot be set through the API either, so the rule is the same everywhere.
Required, hidden, ordered · Applies through the API too
Who this pays off for.
Regulated environments
A governed workflow evidences that every station was passed in the intended order.
Service desk
Waiting on the customer is a status of its own instead of a note in a comment.
Quality assurance
The bug type demands the details nobody can reproduce the defect without.
Business departments
One type per kind of request, with exactly the fields that belong to it.
Workflows belong to Projects.
Statuses and types apply to the work items of a project and set the columns on the kanban board. Approvals run through the automation engine: it holds the run, notifies the person responsible and continues along the path their decision takes. All apps share login, permissions and data. One contract, one deployment, one point of contact.
Operations and data sovereignty.
Where the data sits is decided by the operating model, not by the small print.
Swiss hosted
Operated on Swiss public cloud at Infomaniak, one isolated environment per customer. Content is processed in Switzerland only, apart from the upstream web application firewall.
Self-hosted
Runs on your own infrastructure. Full control over the data, no access from outside.
revFADP & GDPR
Data processing agreement included. Compliant with the revised Swiss data protection act and the GDPR.
Questions from first conversations.
Workflows and approvals in practice: what comes up most often in a first conversation.
Can we define our own statuses?
Yes. The project decides name, colour and order, and the columns on the board follow that order. Two projects in the same system may work differently.
Why does a status also need a category?
Because the backlog, the reporting and the velocity have to know what a status means. The three categories open, in progress and done supply that meaning, whatever you call the status itself.
Can we stop someone from skipping a step?
Yes. The governed flow allows exactly the transitions you defined, rather than offering every status for free selection. Approvals hold a flow until somebody decides.
Can required fields differ per work item type?
Yes. Field rules define per type what is required, what is hidden and what sits in a fixed position.
Put your process into a project.
In the proof of concept we model one of your approvals with statuses, transitions and field rules.
Pricing: from 16 CHF per user and month