Understand the access model
Boldo combines several access rules. A user type determines families of available actions, while roles and domains govern data and content access when fine-grained permissions are enabled. An allowed action must also satisfy the plan, feature settings and resource state.
Separate the access layers
| Layer | Question it answers |
|---|---|
| Organization membership and sign-in | Can this account enter this organization with its current method? |
| User type | Is the action available to a Viewer, Editor, Administrator or Owner? |
| Plan and feature activation | Is the feature included, enabled and available within limits? |
| Roles | What may this member do with each asset type, property, relationship or content category? |
| Access domains | Which data or shared contents do those permissions concern? |
| Ownership and sharing | Is this person responsible for the asset, or entitled to use this personal or shared content? |
The organization Owner and an asset owner are different concepts. One administers the organization and subscription; the other carries responsibility for particular information.
Likewise, opening a visualization does not automatically grant access to the assets it displays. A readable dashboard can contain a widget whose source you cannot access.
Understand the user types
Viewers consult accessible content and can submit suggestions for changes. They can also comment where available. An owner who is a Viewer can attest a visible asset or request re-attestation when quality tracking permits it.
Editors contribute to data and visualizations within their permissions. Administrators manage members and organization settings. The Owner has additional organization and billing responsibilities, subject to the relevant billing access conditions.
Administrator does not mean universal business-data access. An administrator can have restricted roles and hidden properties. Ordinary editing still checks those permissions.
Without fine-grained permissions in the plan, Viewers receive read access and Editors or higher receive ordinary editing capabilities. Individual feature settings and other operation conditions still matter.
Combine roles and access domains
With fine-grained permissions, explicit roles determine permissions. A member without an explicit role uses the system No role, which can have permissions. It does not necessarily mean no access.
An asset without a domain uses No access domain. This can be permissive or restrictive; it does not mean the asset is public.
Permissions combine across applicable roles and domains. The highest applicable permission grants the action; None in one role does not cancel permission granted elsewhere. Adding a domain can therefore broaden access.
For example, an application has the Commerce and IT domains. A member's Commerce role grants View, while another applicable role grants Edit in IT. Hiding IT from the diagnostic table does not remove that effective editing permission.
Configure roles and domains before assigning them. New roles and new domains have different initial permissions.
Distinguish asset, property and relationship permissions
An asset's general permission, property permissions, process-flow content and relationship permissions are separate controls. Being able to edit an asset does not automatically make every property editable.
Relationship permissions are configured from the source asset type. Access to one endpoint alone does not establish access to the relationship. Relationship properties are also limited by the relationship's permission. Computed properties remain read-only regardless of additional roles.
Asset ownership adds specific responsibility-based actions. An owner can release their ownership even after losing read access. An administrator can request re-attestation for a visible asset without owning or editing it. Changing the owner list itself requires the appropriate asset editing permission.
Administrative file import is an exception: it is reserved to Administrators and the Owner and operates outside business-role restrictions. Do not generalize its reach to ordinary asset editing.
Check the context and access channel
Scenarios have their own visibility and management permissions, while data roles continue to apply inside them. Sharing a scenario does not reveal all its properties. See scenario access.
An API key uses its own roles. Its effective user type is capped by the lower of the key's type and its member's type. An external share link uses the roles stored on that link, rather than automatically using every current permission of its author.
The By user diagnostic describes a member. It does not describe every API key or external link they created. A subscription can also make an account effectively Viewer even when its recorded type is Editor or Administrator.
Use permission diagnosis to trace the applicable rule before changing access. Granting Administrator is not a universal fix for an unavailable action.