Process Owner
Every process can name one user as its Process Owner. The Process Owner is the person accountable for the process itself: its design, and every change made to it after it is live.
Use it to answer “who has to agree before this process changes?”. Pick the person who answers for how the process runs, such as the head of the department it serves, rather than whoever happened to build it.
The Process Owner is not a role. A role is filled by users, authorities, groups or organizations, and can admit many people. The Process Owner is always exactly one user, or nobody.
Setting it
- Open the process in the Builder, with no step selected.
- On the Main tab, pick a user in Process Owner, beside the process name, description and tags.
- Deploy the process.
The field is optional. Nothing fills it for you: a process starts without an owner unless someone picks one, and the person who built or deployed it does not become the owner. Picking a different user in the Builder and deploying again changes the owner.
Once the process is live, its owner shows on the process’s detail page under Processes, next to what it calls and what calls it. Click the name to open that user.
What the Process Owner can do
| Authority | Where | What it does |
|---|---|---|
| Sign off changes | A task titled Owner sign-off in Tasks | When a module is installed that would change the process, the install waits for the Process Owner to approve it. If they reject it, nothing is installed. |
| Transfer ownership | Transfer ownership in the ⋮ menu of the process’s detail page, shown only to the owner | Hands the process to another user. Pick the New owner and confirm with Transfer. From then on, the new owner signs off changes and you no longer do. |
A sign-off covers every owned resource the module changes at once. If it changes several processes, datastores or integrations with different owners, each of those owners gets the task, and all of them have to approve before anything is installed. Something the module adds for the first time has no owner yet, so it needs no sign-off.
A process without an owner needs no sign-off. A module can change it as soon as it is installed, with nobody asked. Name an owner on every process where changes should be approved.
Related authorities
Three other kinds of authority sit close to the Process Owner. They do different jobs and do not imply each other.
Admin. The Admin authority lets you build and deploy processes, so an admin can set or change any process’s owner in the Builder. It does not make you the owner: only the owner signs off changes.
Instance Owner Role. The Instance Owner Role, set on the same tab, decides who may cancel and migrate the process’s running instances. It is a role, so it can admit many people. Being the Process Owner does not put you in it; add yourself to that role if you should be able to cancel instances too.
Start and step roles. Who may start an instance is decided by the process’s start role, and who sees an instance and works its tasks by the roles of its steps. The Process Owner has no extra say there.
| Who | Decides |
|---|---|
| Process Owner | Approves changes to the process, and hands it on |
| Admin | Builds and deploys, and so can set any process’s owner |
| Instance Owner Role | Cancels and migrates running instances |
| Start role | Starts new instances |
| Step roles | Work the tasks of each step |
Without an owner
A process with no owner is a normal state, not an error. Its detail page shows an admin of the workspace in the owner spot, and the Transfer ownership dialog reads Current owner: the tenant admin (unassigned). That is a stand-in for display only: the admin does not sign off changes to it.
To give an unowned process an owner, pick one in the Builder and deploy, or have the admin shown in the owner spot use Transfer ownership on the detail page.
Datastores and integrations carry an owner the same way. It is shown on their pages, can be transferred from there, and gates sign-off when a module changes them.
Best practices
- Name an owner on every live process. An unowned process can be changed by a module without anyone approving it.
- Choose one person who answers for the process, not the builder. Building it and being accountable for it are different jobs.
- Transfer ownership before the owner leaves or changes jobs. Unlike a role, the owner is a single named user and does not follow a team or an authority.
- Keep the Process Owner and the Instance Owner Role apart in your head: one approves how the process changes, the other ends individual cases.