Understand the access model

If you want the shortest possible version first, read Rights in 2 minutes.

The Boldo access model combines a global level, business responsibilities, and a scope where those responsibilities apply.

note

On plans without granular governance, only the global user type applies. The role + access domain model described below is not available, and access depends mainly on the user's global type.

How access is evaluated

To know whether a user can act on shared content or on an asset, Boldo reads four layers in order:

1. the user type gives the global level
2. the role defines what the user can do
3. the access domain defines where those rights apply
4. the domains carried by the object being accessed decide whether the rule applies in that case

If several role + access domain pairs match, the highest level wins.

Two practical exceptions:

• personal items in your personal space are not controlled by shared item rights
• items or assets without an access domain follow the "No access domain" system row

User type

Every member starts with a global user type:

• Viewer
• Editor
• Administrator
• Owner

Always start with this layer. It sets the general frame, not the detail of business responsibilities.

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, is not offered in the UI to assign 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

Roles define what the user is allowed to do.

Access domains define where those rights apply.

Users can have one or more roles.

Boldo does not rely on one without the other. The real permission unit is the role + access domain pair.

Without an access domain, a role is too broad. Without a role, an access domain does not do anything on its own.

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

You can manage both from Organization settings.

• Decide your access perimeters first.
• Then create the roles you need and configure their rights.
• Create access domains before large imports or before organizing shared content.

These configuration areas depend on granular governance features in your plan. If your plan does not include them, Boldo falls back to a simpler access model based mainly on the user's global type.

Types of rights

Inside each role-access-domain pair, Boldo stores two families of rights:

• shared content in the catalog
• assets in the knowledge base

In this page, an item means shared catalog content: folder, view, nested map, diagram, or chart.

Shared content

Item rights apply to shared catalog content. They are not split by content type and apply to all shared catalog content.

The access levels for items are cumulative - each level includes all the previous ones:

Level	Meaning
view_item	See the item
edit_item	Create items and edit their names (includes view)
delete_item	Remove items (includes edit and view)
edit_access_domain	Change the access domains on items (includes all above)

Asset rights

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

The access levels for assets are cumulative - each level includes all the previous ones:

Level	Meaning
view_asset	See assets of a given asset type
edit_asset	Create assets and edit their names (includes view)
delete_asset	Remove assets (includes edit and view)
edit_access_domain	Change the access domains on assets (includes all above)

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

Property levels

For properties, Boldo uses three levels:

Level	Meaning
Hidden	The property is not visible
View	The value is visible but cannot be changed
Edit	The value can be changed

Property access is capped by the general asset access level. For example, a user with only view_asset can see properties at most at the View level. Edit on a property requires at least edit_asset on the asset type.

Flow access

When an asset type has flow enabled, you can configure flow access separately from other asset rights. Flow access is set per role-domain pair, just like asset and item rights.

In the UI, this appears as a dedicated Flow access column in the asset rights table for that flow-enabled asset type, in both Organization -> Roles and Organization -> Domains, when granular governance is available.

The flow access levels are:

Level	Meaning
No access	The flow tab is not visible
Read flow	The user can read and explore the flow
Edit flow	The user can modify the flow if they also have at least the Editor user type

Flow access is capped by the general asset access level. A user with only view_asset can have at most Read flow. Edit flow requires at least edit_asset on the asset type, plus a user type of at least Editor.

tip

Flow access only appears for asset types where flow is enabled. If you do not use flows, you can ignore this section.

Default values

Rights tables include two system rows that control default permissions.

The "No role" row defines the permissions that apply when a user has no role assigned. Use it to set a baseline for users who have not yet been given any role.

The "No access domain" row defines the permissions that apply to items or assets that carry no access domain. You control this behavior explicitly in the rights table.

When the "No access domain" row does not grant edit_asset for a given asset type, Boldo requires a domain on every asset of that type. Users must assign at least one access domain when creating or editing such assets.

info

Review both system rows when you set up your access model. They determine the default experience for unassigned users and uncategorized content.

Diagnose access

When access looks confusing, walk this checklist:

1. What is the user's global type?
2. Which roles are assigned?
3. Is the object personal, shared, or without an access domain?
4. For shared content, which domains are on the item? For assets, which domains are attached to the asset itself?
5. Among the matching role + access domain pairs, what item or asset rights are configured?
6. Do the "No role" or "No access domain" system rows affect this scenario?
7. Does the current plan use granular governance, or the simpler legacy model?

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: edit_asset level
  • Server asset rights: view_asset level
  • the needed property 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: edit_item level 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
• assuming items or assets without access domains are always public (check the "No access domain" system row)
• ignoring the "No role" system row when onboarding new users
• 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
• overlooking flow access when asset types have flow enabled

Appendix: default rights when creating

When you create a new entity in the access model, Boldo initializes default rights automatically. This reference is mainly useful during the initial setup.

Created entity	Default rights
New role	Full access on the "No access domain" only: edit_access_domain on all asset types, edit_property on all properties, edit_flow on flow-enabled types, and edit_access_domain on items. Other domains start with no access configured.
New access domain	No access configured. Rights entries are created for all existing roles, but no access levels are set. You must configure rights explicitly before assigning the domain to items or assets.
New asset type	edit_access_domain for all existing role-domain pairs on the "No access domain" only. All other domains start with no access for this asset type.
New property	edit_property for all role-domain pairs where the role has at least edit_asset. If the role only has view_asset, the property defaults to view_property.

warning

A new access domain starts with no access configured. If you assign it to assets before configuring rights, users may lose access to those assets.