Understand the access model

To understand the access model in Boldo, separate two questions:

• what level of authority does this user have in the organization?
• on which perimeter, and with which rights, can they act?

In practice, effective access comes from:

1. user type
2. roles
3. rights configured for each role-domain pair
4. the access domains carried by the shared item or asset being accessed

The short version

• user type sets the broad level of authority
• users can have one or more roles
• rights are configured by pairing roles with access domains
• each role-domain pair can contain item rights and asset rights
• for a given domain, if several roles apply, the highest level of access wins
• a shared item or asset is checked against its own access domains to decide which role-domain pairs apply
• if several access domains match, the highest level of access wins

In short: user type = baseline authority, role + access domain = permission set, item or asset access domains = where that set applies.

Two important exceptions also matter in practice:

• personal items in your personal space are not controlled by shared item rights
• shared items or assets with no access domains are treated as public inside the organization

User type

Every member starts with a global user type:

• Viewer
• Editor
• Administrator
• Owner

This is the broadest layer. It is a baseline, not the full permission model.

In practice:

• Editor is the minimum level used for create, update, and delete actions on content and assets
• Administrator or Owner is required for governance and administration pages
• Owner is reserved for the organization owner in self-service organizations, is tied to billing ownership, cannot be assigned manually to another user, and cannot be deleted
• user type should stay simple and should not be used to model detailed business responsibilities

Roles and access domains work together

Roles define what the user is allowed to do.

Access domains define the perimeter where those rights apply.

Users can have one or more roles.

Rights are configured on pairs of role + access domain and then matched against the access domains on items and assets.

That pair is the real unit that carries permissions. Without an access domain, a role is too broad. Without a role, an access domain does not do anything by itself.

If a user has several roles on the same access domain, Boldo keeps the highest level of access granted by those roles.

Use roles to model responsibilities such as:

• application maintainers
• read-only reviewers
• shared content contributors
• catalog managers

And use access domains to define business perimeters such as:

• Finance
• HR
• one project
• one geography
• one confidentiality perimeter

Where to configure roles and access domains

Create and manage both from Organization settings.

• Create the roles you need first, then configure their rights.
• Create access domains before large imports or before organizing shared content.

These configuration areas depend on advanced governance features in your plan.

Two rights families inside each role-access-domain pair

Inside each role-access-domain pair, Boldo stores two kinds of rights.

In this section, an item means any shared object stored in the catalog:

• a folder
• or a visualization

And in Boldo, a visualization means:

• a view
• a nested map
• a diagram
• a chart

You can also think of items as everything that is visible in the catalog.

Item rights

Item rights apply to shared catalog content:

• folders
• views
• diagrams
• charts
• nested maps

They cover actions such as:

• view
• create
• rename
• delete
• update domains

Item rights are not split by item type. They apply to shared catalog content as a whole.

Asset rights

Asset rights apply to the knowledge base itself. They are configured per asset type, and can be refined per property and per relationship type.

This includes:

• seeing assets of a given asset type
• creating assets
• renaming assets
• deleting assets
• changing an asset domain
• editing specific properties
• editing asset relationships of specific relationship types

Property and relationship rights are part of the granular governance model and depend on the plan.

Property and relationship levels

For properties, Boldo uses these levels:

Level	Meaning
Hidden	The property is not visible
Reader	The value is visible but cannot be changed
Editor	The value can be changed
Owner	Same editing level as Editor, often used for responsibility or notification logic

For relationships, Boldo uses these levels:

Level	Meaning
Hidden	The relationship is not visible
Editor	The relationship can be created or deleted

Access domains on items and assets decide whether rights apply

Once roles and rights are configured, Boldo still needs to know whether they apply to the object being accessed.

For shared content, Boldo checks the access domains of the item. For assets, Boldo checks the access domains of the asset and the asset type it belongs to.

If several access domains match, the highest access wins.

Two cases are important:

• personal items in your personal space are not controlled by shared item rights
• items or assets with no access domains are treated as public inside the organization

How to reason about effective access

When access looks confusing, ask the questions in this order:

1. What is the user's global type?
2. Which roles are assigned?
3. Is the object personal, shared, or does it have no access domains?
4. Which access domains are attached to the shared item or asset?
5. Among the matching role-access-domain pairs, what item or asset rights are configured?
6. If the issue is about granular governance, does the current plan include those features?

This order usually reveals the cause much faster than checking permissions randomly.

Example 1. Finance application editor

Goal:

• edit applications in Finance
• view servers in Finance
• do nothing outside Finance

Typical setup:

• user type: Editor
• assigned role: Application maintainer
• rights on the pair Application maintainer + Finance access domain:
  • Application asset rights for the needed actions
  • Server asset rights in read-only mode
  • the needed property and relationship rights when granular governance is enabled
• Finance assets carry the Finance access domain

Result:

• the user can contribute inside Finance
• the user cannot edit all asset types everywhere

Example 2. Shared diagram contributor

Goal:

• create and update diagrams in one shared perimeter
• not modify the whole knowledge base

Typical setup:

• user type: Editor
• assigned role: Shared content contributor
• rights on the pair Shared content contributor + Architecture workshop access domain:
  • item rights high enough to create and update shared catalog content
  • only the asset rights really needed to read the underlying knowledge base
• the shared items in that perimeter carry the Architecture workshop access domain

Result:

• the user can manage the visual content they are responsible for
• they do not automatically become a broad knowledge base editor

Common mistakes

• thinking that a user's access domains alone define effective access
• assuming that a role alone defines the result
• confusing item rights with asset rights
• forgetting that item rights apply to shared catalog content as a whole
• forgetting that items or assets with no access domains are public inside the organization
• using Administrator when an Editor with good roles would be enough
• creating roles before deciding access domains
• forgetting that some granular governance features depend on the plan