Reach

If you’ve ever wondered why a colleague with the same job title as you can see a work package you can’t, this is why. It’s a deliberate design, not a bug, and it applies underneath almost everything else in the product.

The two kinds of access

Every role in OTB Works is one of two scopes:

• Programme-wide. Holding the role means the permission applies everywhere, full stop, no per-item check. Delivery Lead, Finance, Reviewer, Board Reader, Auditor, Assessor and Risk Owner are all programme-wide.
• Reach-scoped. Holding the role only gets you as far as “eligible in principle”, you still have to actually reach the specific thing you’re trying to see or edit. Member, Workstream Lead, Work Package Owner and Customer are all reach-scoped.

What “reaching” something means

For the ordinary plan hierarchy (workstreams, work packages, deliverables, steps), you reach an item if you are:

• named as its owner (or the owner of something above it in the hierarchy),
• named as its customer, or
• assigned to it directly.

A Workstream Lead reaches everything under the workstreams they lead. A Work Package Owner reaches everything under the work packages they own. If you hold none of these relationships to something, a reach-scoped role does not let you see it, edit it, or approve changes to it, even if you hold the same role as someone who can.

The Customer role is deliberately narrower still, see below.

Where you’ll notice it

• The plan itself. A Work Package Owner sees the work packages they own and their contents; they don’t see the rest of the programme’s other workstreams unless something else, a second role, or being named on more than one thing , gives them reach to it too.
• Approving a sitting. A reviewer must reach every entity a sitting touches, not just some of them. If a proposed change spans two workstreams and you can only reach one, you are refused the decision entirely, you are never offered a partial approval of “your half” of it.
• Signing an acceptance stage. A stage that names a role rather than a specific person can be configured as programme-wide (“anyone with that role”) or reach-scoped (“only the person with that role for this work”), the same composition rule, one level down.
• The declared-status and change-sitting write actions. These are always checked against reach for the specific entity you’re touching, never assumed from your role alone.

The Customer role is narrower than reach, it’s a different shape entirely

A Customer isn’t given the ordinary plan-reading permission narrowed by reach , they’re given a separate, deliberately narrow read of just the deliverable(s) they’re named the customer of: its definition of done, its evidence, its dates, and how sign-off is progressing. Nothing else, not other deliverables in the same work package, not RAID items, not benefits, not money. This is a considered decision: handing a customer the ordinary “Member” role instead, just to make signing and seeing work, would show them the whole programme within reach the moment they’re named on a single thing, everything else in that workstream, sibling deliverables, internal notes. The narrower, purpose-built read avoids that entirely.

Cost visibility is its own, separate reach question

Seeing money is never implied by seeing the plan. A person with ordinary plan access and no cost permission never sees a figure, not on a screen, not inside a report, not inside a cost breakdown, even if they can otherwise see everything else about the same item. Finance, Board Reader and Auditor are the roles that carry cost visibility, and all three are programme-wide for it, not reach-scoped.

What you are told when something is out of reach

A plan record you do not see in full answers not found, the same answer as for a record that does not exist. This holds on the plan routes whatever the reason: workstreams, work packages, deliverables and steps, sign-off, notes, discussion, monthly reports, finance reads narrowed to one of them, and the Advisor. A guessed address therefore confirms nothing about what is there.

Lacking a permission is a different refusal. It names the permission, and it is the same whether or not the record exists. If you meet “not found” for something a colleague can open, ask a workstream lead about your reach. The product does not say why, by design.

Reach and what a role may see beyond it

From 1.0.5 an administrator can set, role by role, how much of other people’s work a limited role sees in full, as a neutral line or not at all. Your own work is always in full, and editing and approval follow what you see in full. See how a role’s visibility works.

Why this exists

This is deliberately enforced on the server, not just hidden in the interface, a person who can’t reach something is refused the request itself, and (for live, real-time updates) never even told that the thing they can’t reach was touched at all. Reach exists so that a wide plan can be worked on by many people without everyone seeing everything: a Work Package Owner does their job without needing visibility into a colleague’s entirely separate workstream, and a Customer can be handed a login without ever seeing more of the programme than what they’re actually being asked to accept.

Where to go next

• A sitting: why a reviewer’s own reach determines whether they can decide it at all.
• The acceptance and approval chains: how reach composes with “who may sign this stage.”
• The administrator guide’s people and access page for how reach is actually set (by naming someone as an owner, customer or assignee on the plan itself, never as a separate field on their account).