Understanding access
A user's access is granted through exactly two mechanisms — user groups (userGroupUids) and permissions (permissions[].uid). Everything else — profiles, application groups, assets, report groups — is not a separate concept; it's just a permission with a different type/subType.
Permissions by type
| What you grant | type | subType | Controls |
|---|---|---|---|
| Profile | PROFILE | — | Functional scope; some apps (Keep, Model) use it for access rights |
| Application access | SCOPE_GROUP | APPLICATION | Which applications the user can open (e.g. document storage via stonal.application.platform) |
| Company | ASSET | COMPANY | A company and the assets it owns |
| Portfolio | ASSET | PORTFOLIO | A portfolio and its assets |
| Facility | ASSET | FACILITY | A facility |
| Building group | ASSET | BUILDING_GROUP | A building group |
| Building | ASSET | BUILDING | A single building |
| Report group | REPORT_GROUP | — | The underlying reports |
allAssets: true is the shortcut for "all assets" instead of listing ASSET permissions.
Permissions are hierarchical — the API exposes level, parentUids, and children { count, uids } (e.g. a company contains its buildings); the lookup reference shows how to walk the tree.
For completeness, the full enums: type ∈ ASSET, PROFILE, SCOPE, SCOPE_GROUP, REPORT, REPORT_GROUP; subType ∈ BUILDING, BUILDING_GROUP, FACILITY, PORTFOLIO, COMPANY, APPLICATION, RIGHT, POWERBI, METABASE.
Authorization at a glance
Next: look up the groups and permissions you'll assign, then create or update a user.