Two mechanisms
Functional roles answer "what kind of work may this person do" - resolved from the session for operations inside an organisation. Platform-wide operations are separate and require platform-administrator standing, which is not a role an organisation can assign to itself.
Resource grants answer "may this subject act on this specific object". A grant names:
| Field | Values |
|---|---|
| Grantee | A subject, a role, a group, or public |
| Access level | Read, write, owner, share |
No grant is a denial, not a fallback to a default. And the grant model is not per feature: semantic models, metrics, sites and pages are all resource types in the same table, so "who may see this" is one mechanism, not one per block.
Roles an application declares
An application can declare its own roles in its manifest - an identifier, a label and the permission it carries. On installation these become grantable to your own members, and their permissions merge into the ordinary permission set.
That is a general platform mechanism, not something the application enforces itself. An app ships the roles its domain needs - approver, warehouse operator, campaign manager - and your administrator assigns real people to them, in the same place they assign everything else.
What sits underneath
Grants decide whether an object is visible at all. Which rows of it, and which values in those rows, are decided separately and per query - see Row-level security and Column masking.
And whether the capability exists in this installation at all is decided before any of that, by licensing.