One team identity, only the facts an app needs

Imagine a small design studio using a project tracker and a review tool. The same team works in both, but the tools need different information. The tracker might need to know who belongs to the studio. The review tool might also need a role that helps it decide who can approve a design.

A reusable organization identity can help those products recognize the same team. The useful boundary is what comes next: which facts may each application learn, and what may it do with them?

M7’s documented organization model keeps those questions separate.

Ask for organization facts explicitly

Organization information is an explicit M7 extension, separate from ordinary UserInfo. An integration requests the registered orgs scope; it does not receive organization information simply because someone signs in. Consumer authorization requires hosted consent.

The documented lookup supports active consumer users and ordinary client-credentials applications discovering their own Management memberships. Tenant member tokens, personal machine-owner proxies and Device authorization are outside that supported path. Registering an application under a tenant does not make a tenant member token eligible.

These are documented integration contracts, not a promise that every product already implements the complete flow. Builders should verify the receiving application and runtime they intend to use. The organization information guide describes the request and its boundaries.

The owner controls disclosure

An eligible lookup can return the caller’s current organization role, such as owner, admin or member, along with public membership data and assigned tags. Private membership data is excluded.

The organization owner controls whether those facts may be disclosed to the verified requesting application. Visibility within the organization and outside it are separate choices, both off by default. An explicit denial cannot be bypassed by the caller’s role.

For our studio, that means the owner can allow a particular integration to learn membership facts without opening the same information to every application. Permission to disclose information does not add someone to the team or give the receiving product access to the studio’s resources.

Let each product decide the action

Suppose the tracker receives a current studio membership. It can use that fact in its own access rules. The review tool still needs to decide whether this person may approve this design. Receiving an organization role does not make that decision automatically.

The organization’s stable principal reference serves a different purpose: recognizing an enduring organization identity through lifecycle and ownership changes. That reference does not authenticate an organization, enroll it in a product or authorize a person to act for it.

Keeping recognition, membership, disclosure and permission distinct lets a team reuse its identity while each product keeps responsibility for its own actions.

Check current membership when it matters

The documented lookup uses current membership. After someone leaves or is removed, that membership is omitted on the next lookup. The organization’s enduring identity remains.

That does not mean every previously issued token or product session changes immediately. A receiving product needs a clear policy for when it checks fresh facts and how it handles an existing session.

For a builder, the practical starting point is small: choose the organization facts your product needs, confirm that the owner allows disclosure, and define the actions those facts can inform. For a team owner, the benefit is equally concrete: the same team can be recognized in more than one place, with control over what each place learns.