Heuristic Planning Systems
Partners and tenancy
A partner is not a special case bolted onto the data model. It is an organisation nested inside another one.
Organisations nest
An organisation is the tenant boundary, and organisations can sit inside other organisations. That single property is what models a partner: the partner is a child organisation, its people are members of that child, and their roles are scoped to it. They see their own organisation, not the parent and not the organisations alongside them.
The relationship runs one way. A grant made at the parent cascades down to the children beneath it, so one assignment can give a central team visibility across every partner. Nothing cascades upward.
API tokens are bound to the organisation they were created in, so an integration built by a partner stays inside that partner’s boundary.
Access reads as a sentence
Four reusable pieces, and one of them is the access. An assignment says who can do what, and where.
Platform Engineers → Contributor → Customer-facing projects
Role
A named bundle of permissions. Standard roles cover the usual shapes, from platform administration down to read-only, and organisations can define their own.
User group
A named set of people. Add someone to the group and they inherit whatever that group has been granted, with no separate step to remember.
Project group
A named set of projects. Add a project to the group and every existing grant covers it immediately.
Assignment
The grant itself, and the only thing that actually confers access. Roles and groups define nothing on their own until an assignment ties them together.
The practical consequence is that access is maintained by editing definitions rather than by hunting through individual permissions. Someone joins a team, so they join the user group. A project joins a portfolio, so it joins the project group. A role needs to do more, so the role changes and everyone holding it changes with it.
One question, asked at every level
Every authorisation decision resolves to the same question: does any assignment give this subject a role containing the needed permission, at a scope that covers this resource? Scope is a chain, and a grant anywhere on it applies.
work item → project → release train → programme → organisation → parent organisation → global
That is why a single assignment at organisation scope can cover hundreds of projects, and why adding a project to a portfolio does not require anyone to revisit who may see it.
Current status
The permission model described here is in preview. Permissions are computed and visible throughout the product, but they are not yet enforced on every route. We are not claiming enforced tenant isolation today, and you should not evaluate the product as though we were.
Existing users and tokens have already been mapped to assignments, so switching enforcement on will not remove anyone’s access. If tenant separation is a requirement for your evaluation rather than a preference, talk to us about timing before you commit to anything.
Ask about enforcement timing