Open to read, scoped to edit
The model has one simple rule at its core:Everyone in your organization can read the whole map. You can edit only the parts you own.Open reading is deliberate. Transparency is what fuels the opportunity flywheel: trained people spot gaps across the whole company, not just in their own silo. Scoped editing is what keeps the map trustworthy: a process has one owner and one definition, not fifty divergent copies.
Ownership
Two kinds of ownership decide edit scope.Unit leader
The named leader of an org unit. Leads that part of the tree and, by default, owns the processes defined there.
Process owner
The person accountable for a specific process definition. Assigned per process, and reassignable.
Every process also has a Kowalah owner: the person on your Kowalah team who helps keep that process true as part of the managed service. Customer ownership and Kowalah ownership sit side by side.
Edit versus suggest
What a person can do to a given process depends on two things: whether they own it, and where it sits relative to their own unit in the org tree. Your unit is your altitude, and you have reach downward from it.
Core team and admins hold edit reach across the whole map for their own organization. Owners hold edit reach over what they own. Managers hold edit reach over everything beneath them. Everyone else suggests. This is the default, and it is safe: nothing changes a process without its owner’s agreement.
Reach downward is what makes this workable at scale. A function lead does not have to be named owner on every process in their function to keep them true, but they still cannot reach sideways into a peer’s function or upward into their own leadership’s definitions.
The suggest-then-approve flow
When someone who runs a process proposes a change, it does not apply straight away. It becomes a suggestion routed to the process owner.1
Someone proposes a change
A person who runs the process edits a step or KPI. Because they do not own it, the change is captured as a suggestion with a clear before and after.
2
The owner reviews it
The suggestion appears in the owner’s review queue. They see exactly what would change.
3
The owner accepts, adjusts, or rejects
Accepting applies the change. Adjusting lets the owner refine it first. Rejecting records the reasoning. Either way, the owner stays in control of their definition.
Widening someone’s edit reach
Edit reach follows the org tree, so the way to widen it is to set someone’s place in that tree correctly rather than to grant a per-person exception.1
Set their home unit
A person’s home unit is their altitude. It is what gives them edit reach over their own unit’s processes and everything below. Someone with no home unit set can only view and suggest, everywhere, which is the safe default but a frustrating one if they should be editing.
2
Name them as process owner
Ownership travels independently of the org chart. Naming someone the owner of a process gives them edit rights over it wherever it sits, which is how you handle a definition that crosses org lines.
3
Or make them core team
Core team and admins can edit anywhere in your organization. Use this for the small group who genuinely curate the whole map, not as a shortcut for the two cases above.
Revision history keeps it safe
Every process and unit keeps a full revision history: who changed what, when, field by field. Changes are attributed to your team members, to your Kowalah partner, or to the system, so there is always a clear record. Any change can be reverted in one click. This is what makes the map safe to keep current: because nothing is ever truly lost, there is no risk in editing. A wrong change is a quick revert away, not a support ticket.What’s next
Operating model setup
Positions, home units, and getting the map live
Owning and improving a process
The editing and suggesting experience, for owners and runners