How access works

Access in OTB Works is decided by three things: what a person is allowed to do (permissions), how those permissions are bundled (roles), and which part of the programme they can reach (reach).

Permissions, roles and reach

A permission is one thing a person may do, such as view the Deliver stage or edit costs. Permissions are fixed by the product. You cannot invent one.

A role is a named bundle of permissions, plus one scope. A person can hold several roles at once, and they add together. A role change takes effect on the person’s next request, with no need to sign out.

Scope decides how far the role’s permissions extend:

• Programme-wide: the permissions apply everywhere.
• Only for their own workstreams and work packages: the permissions apply only where the person has reach.

Reach is the link between a person and the work. A person with a reach-scoped role reaches a workstream if their linked person record is any of these:

• The workstream’s owner.
• The owner or customer of a work package inside it.
• The owner or customer of a deliverable inside it.
• Assigned to a work package or deliverable inside it, directly or through a team.

Being assigned to a single step does not give reach over the whole workstream. A step’s assignee can still update that step’s own progress.

If a reach check fails, the refusal says why, naming the workstream.

The five stages

Permissions follow the five stages of the product: Assess, Decide, Deliver, Steer and Prove. A person who holds none of a stage’s permissions does not see that stage at all.

Each stage has up to four levels, counting None:

Level	Meaning
None	The stage does not appear for this role.
View	Can see everything in the stage but change nothing.
Contribute	Can see the stage and do its everyday work.
Manage	Can also configure how the stage runs.

Not every stage has every level. Steer is a reading stage, so it has only View. Decide and Prove have no Manage level.

Money (cost figures) is a separate control from the stages. A person can hold all five stages and never see a figure.

Some capabilities are switches rather than levels: administering people and set-up, managing logins without full administration (no shipped role holds it; it is for custom roles), operating the instance, accepting a risk, signing off, signing off on behalf of someone else, using Advisor, reading Advisor’s interaction log and reading the audit trail.

The shipped roles

Fourteen roles ship with the product. They are marked Shipped default on the screen. Their names cannot be changed or deleted. Their descriptions and permissions can be edited.

Running the programme day to day

Role	Scope	Purpose
Member	Own work	Sees and edits the plan where they are involved, approves changes on that work, signs off stages they are named on, and reads the published month.
Workstream Lead	Own work	Leads workstreams. Same permissions as Member, and is the person sign-off steps address by name for that workstream.
Work Package Owner	Own work	Owns work packages. Same permissions as Member.
Delivery Lead	Programme-wide	Oversees the whole plan. Creates workstreams, changes how status is judged, rules on findings, signs off, and can sign off on behalf of a customer. Does not see cost figures unless also given Finance.
Finance	Programme-wide	Sees and edits money across the programme without editing the plan.
Reviewer	Programme-wide	Approves or rejects proposed changes anywhere, without editing the plan.

Assurance

Role	Scope	Purpose
Assessor	Programme-wide	Scores assessments, raises findings, attaches evidence and rules on findings. Cannot accept a risk.
Risk Owner	Programme-wide	Accepts risks. Cannot raise, score or rule on findings.
Assess Contributor	Programme-wide	Scores only the sections of an assessment they are assigned.

The Assessor and Risk Owner are separate on purpose, so the person who assessed is not the person who accepts the risk.

Customers

Role	Scope	Purpose
Customer	Own work	Sees only their own deliverables and can sign them off or send them back. Nothing else.

Read-only

Role	Scope	Purpose
Board Reader	Programme-wide	The board’s view: tracking, published reports, the board pack, costs, the plan and assurance findings. Cannot produce a board pack.
Auditor	Programme-wide	Reads all five stages and costs. Changes nothing. Can read Advisor history and the audit trail.

Administration

Role	Scope	Purpose
Admin	Programme-wide	Runs all five stages and administers people and set-up: people and access, the tracker connection, the status vocabulary and sign-off chains, branding and the importer. Does not hold the keys to the instance itself.
System administrator	Programme-wide	Runs the instance: the licence, single sign-on, outbound email, updates, and Advisor and Support settings. Sees none of the programme and cannot manage people. Give both roles to someone who does both.

The full table of permissions for every role is in the roles and permissions reference.

Create a custom role

You need the Admin role, or any role with the administration permission.

1. Open the account menu, then Admin, then People and access.
2. In the Roles section, select New role.
3. Enter a Name. It must not match another role.
4. Choose a Scope: Programme-wide, or only for their own workstreams and work packages. One scope applies to every permission the role grants.
5. Add a Description.
6. For each stage and for Money, pick a level: None, View, Contribute or Manage. The legend explains each level.
7. To add switches such as accepting a risk, select Show advanced permissions.
8. Save the role.

To change a role, edit it from the same list. Changing its permissions requires stating its scope again.

A role cannot be deleted while any account holds it, or while a sign-off or approval chain stage names it as a signer. Changing who holds the instance.operate permission needs you to hold it already. The product also refuses any change that would leave nobody able to administer, or nobody able to operate, the instance.

People and accounts

OTB Works keeps two things apart:

• A person is anyone the plan refers to: an owner, an assignee, a customer, a name in a report. A person does not need to sign in.
• An account is a login. Every account is linked to a person.

In People and access you can:

1. Select Add a person.
2. Enter a name and email, and choose what they are here to do: Team member, Stakeholder, Vendor or Contact.
3. Turn on Can sign in if they need an account, and tick the roles to grant.
4. Select Add person.

For a person with a login, the product emails a link so they set their own password. Nobody types one for them. This needs an email provider to be configured.

To grant or revoke roles later, use Manage roles on the person’s row. Disable an account to stop sign-in, rather than revoking roles: roles are kept, and re-enabling restores them. The last administrator cannot be disabled.

Cost figures are never implied by the plan roles. Only roles holding the money permission, or a read-only role such as Board Reader or Auditor, see them.

Invitations

The Invitations tab under Admin is about one-time scoped links. A scoped link lets someone do one thing, such as sign off one deliverable or complete their sections of one assessment, without an account or a password. A link works once and expires after a fixed number of hours, which the page shows. Links can be withdrawn. Resending issues a new link and withdraws the old one. The raw link is never shown to the person who issued it.

Single sign-on provisioning

If you configure single sign-on, a first sign-in creates the account for a person who already exists on the programme, matched on email address. It never creates the person. If the identity provider sends someone the programme has not heard of, they are refused with the reason. An administrator must add the person first.

Roles belong to the person, not to the sign-in method, so grant them in People and access as usual. Works does not read identity provider groups, so a group in your directory does not grant a role.