In brief: on a Multi-Org platform, two different settings decide what a person sees. The role says what they can do. The organization says on which data they do it. Confusing the two is the most frequent cause of "why can't I see this application".
Two settings, two different questions
Setting | The question it answers |
Role | Can this person edit an authorization, create a campaign, manage users? |
Organization | On which entity's portfolio can they do it? |
An Admin remains an Admin of their entity. They hold every platform right, applied to a data perimeter that is not the Group's.
Attaching a person to their organization
The Organization field appears in a user's form, below the role. It only exists if your platform runs in Multi-Org and domains are configured.
Settings then Roles and permissions then Users.
Open the person's record, or create it.
In Organization, select their entity.
Save.
From then on, the person works inside that entity's perimeter: the applications inventory, the Product Sheets, the dimension sheets, the prioritization matrix, the workflows, the custom themes and fields, and the perimeter Ask Beamy queries.
ℹ️ The assistant answers within the perimeter of whoever asks. Two people from two entities asking Ask Beamy the same question get two different answers, and both are right.
⚠️ The field is required when it shows. A person with no organization on a Multi-Org platform is a person whose perimeter is undefined: set it at creation, not at the first support ticket.
Opening the Group features
Below the Organization field, a switch carries the name of your root domain, usually Access to Group features. It opens two things, and only two:
Viewing all consolidated data on the platform, across every entity.
Defining governance rules to propagate to the entire organization.
The second point matters most. It is what allows a Group authorization to be set on top of the authorizations each entity defines for itself.
⚠️ The Group right is not a higher role, it is a lifted partition. It grants no new permission: someone who cannot edit an authorization inside their entity will not be able to at Group level either. The role still says what you can do; the Group right only widens the perimeter you do it on.
Keep it for the people who actually steer the common policy. Three or four per group is usually enough.
The diagnosis to run before opening a ticket
When someone says "I can't see this application", ask the questions in this order:
What is their organization? If the application belongs to a sister entity, the partition is working, this is not a bug.
Do they have the Group right? Without it, consolidated data stays closed to them, whatever their role.
What is their role? Only here does the right to edit rather than read come into play.