One workspace
Every service your organisation switches on appears in the same workspace, on your own address, behind one sign-in. There is no second installation and no second set of logins.
How it works
One platform. Every service runs on it.
A service is authored as configuration rather than written as software. That is why your second service is a subscription change instead of a second project, and why changing a threshold does not join a development queue.
The basics
9 servicesFour things true of every service
01
02
Your rules, not ours
Who approves, above what amount, who is told and how long they have are your organisation’s own records. Your administrators change them in plain forms, without a release.
03
One trail
Every decision in every service writes to one append-only, hash-chained record for your organisation. Changes to a process are on it too, with before and after.
04
One subscription
Adding a service is a line on the subscription you already have, not a second agreement and not a second vendor review.
In the day to day
It opens on what is waiting on you
A service does not open on a dashboard you have to interpret. It opens on the decisions sitting with you, with the figures that matter beside them. Every figure opens what it counts and offers the next action.
In the day to day
A decision carries its reasons
An approver sees the cost, the budget behind it and why it needs them, on the same screen as approve and reject. A rejection takes a reason, and the reason is kept.
In the day to day
What happened is on the record
Who asked, who approved, what it cost, what was turned down and why. Append-only and hash-chained, one chain per organisation, verifying on its own.
Every product
4 rulesRules the platform keeps for you
These are not configured per process. Every product gets them, because a process that forgets them is the one that fails an audit.
01
Nobody approves their own request
Whoever raised a request is left out of every approval on it, however the approvers were chosen. When only the requester could decide, your workspace’s administrators are asked instead, and the approval says why.
02
Files cannot change under a decision
A file is stored once and never altered; a new upload is a new file. A decision records every file it was made on, and a file added afterwards is put in front of the people who decided.
03
Decisions from people who are not users
A client, supplier or media owner gets an emailed link that does one thing, for one file, for a limited time. Only that link can answer, once, and the answer is on your trail against the address it was sent to.
04
Settings for the whole workspace
A product brings its own settings, and your administrators set them under Manage, Settings. Every change is on your trail with before and after, and work in flight reads the new value at its next step.
What you set, and what we do
You own the rules. We own the shape.
Worth being exact about, because most vendors are not. The two are different jobs and only one of them is yours.
Your administrators, from inside your workspace
- Who approves, and above what amount
- Your cost centres, budgets, categories and periods
- Your people, the roles they hold and who each reports to
- Who is told, and how long an approver has before it escalates
- Your own records: stock, assets, customers, clients, projects, leave policy
- The settings a service brings, such as whether clients sign off a supplier’s proof
Us, when a service is authored or changed
- Which step follows which, and the conditions on each branch
- The records a service keeps and the fields on them
- A new service, or a new kind of step for every service
A process is edited as a draft, checked, then published. Work already under way stays on the version it started on.
Your second service
Switched on, not installed
A service you add appears in the same workspace, behind the same sign-in, writing to the same trail, managed by the same administrators. Your people do not learn a second system.
Keep exploring