Permission Set for the Repository Model

The Repository Model permission set decides who can read, create, and change the documentation of your integration landscape in the Repository Model. Architects can maintain Integrations, Systems, and Services, support teams can keep Knowledge Base Articles current, and everyone else can read what they need.

• ✅ Role-based access control for every Repository Model entity
• ✅ Separate Access (read), Create, and Modify rights
• ✅ Self-service documentation without administrator rights
• ✅ Global defaults with per-entity overrides

C4 Diagram Sets have their own permission set, see Permission Set for C4 Diagram Sets. How end-users browse the Repository is covered in Getting Started with Repository.

Understanding the Repository Model Permission Set

The global Access right on Repository is the gate: without it, the Repository menu isn't shown at all. Below it, each entity has its own Access, Create, and Modify rights: Access on the entity's Access row, Create and Modify on its Permissions for all row.

Blue = the global Repository gate, orange = the per-entity rows, teal = read access, purple = rights that change the documentation.

Set permissions on Roles. Each value is one of:

• Inherited – Default (not allowed unless the end-user is part of another Role where this grant is set).

  Note

  Inherited is NOT the same as Deny! It means the inheritance chain is honored.

• Allow – Access is granted.
• Deny – The feature is blocked. Use this setting only for special cases.

Note

Regardless of other permission sets, a Deny always wins. Since entities are assigned to Roles, you should rarely need Deny. Instead, consider removing the entity from the Roles.

Access (read-only)

If the permission is set to Allow, the end-user can see the entity's items, read-only.

Create

If the permission is set to Allow, the end-user can create new items of the entity in the Repository Model.

Modify

If the permission is set to Allow, the end-user can change existing items of the entity in the Repository Model.

Entities in the Permission Set

Access Repository

To use the Nodinite Repository Model, the User must be a member of a Role granted (Allow) access to the Repository.

The Repository Permissions tab in the Role editor. The Repository group's Access row is the global gate; each entity group, such as Integrations, has an Access row and a Permissions for all row with Create and Modify.

If the Role is denied access to the Repository Model, the Repository item isn't shown in the main menu:

Without Repository access, the menu shows no Repository item.

Integrations

Members of Roles with Access on Integrations can view Integrations in the Web Client; Create and Modify let them add and change them.

Example: the Integrations permissions on a Role.

Systems

Members of Roles with Access on Systems can view Systems; Create and Modify let them add and change them.

Example: the Systems permissions on a Role.

Services

Members of Roles with Access on Services can view Services; Create and Modify let them add and change them.

Example: the Services permissions on a Role.

Contracts

Members of Roles with Access on Contracts can view Contracts; Create and Modify let them add and change them.

Example: the Contracts permissions on a Role.

Important

The UseContracts System Parameter must be set to true; otherwise, the Contracts feature is disabled.

Message Types

Members of Roles with Access on Message Types can view Message Types; Create and Modify let them add and change them.

Example: the Message Types permissions on a Role.

Endpoints

Members of Roles with Access on Endpoints can view Endpoints; Create and Modify let them add and change them.

Example: the Endpoints permissions on a Role.

Articles

Members of Roles with Access on Articles can read Knowledge Base Articles; Create and Modify let them write and change them.

Snippets, Templates, and Document Profiles follow the same standard and share these Articles permissions: a Role that may create or modify Articles may also create or modify them. Reading Articles from a Monitor View is a separate right, View Articles, in the Permission Set for Monitor Views.

Example: the Articles permissions on a Role.

Custom Fields

Members of Roles with Access on Custom Fields can view Custom Fields; Create and Modify let them add and change them. Custom Fields are legacy; prefer Custom Metadata, and see DisableCustomFields.

Example: the Custom Fields permissions on a Role.

Custom Metadata

Members of Roles with Access on Custom Metadata can view Custom Metadata; Create and Modify let them add and change the definitions.

Example: the Custom Metadata permissions on a Role.

BPMs

Members of Roles with Access on BPMs can view BPMs; Create and Modify let them add and change them. A BPM also needs Log View and Monitor View rights to show live events, see What permissions does a BPM need?

Example: the BPMs permissions on a Role.

Domains

Members of Roles with Access on Domains can view Domains; Create and Modify let them add and change them.

Example: the Domains permissions on a Role.

Next Steps

Add or manage Role
Permission Set for C4 Diagram Sets
Repository Model

Related Topics

Log View permission set
Monitor Views permission set
What is a Role?
Access Management
Getting Started with Repository
Users
UseContracts and DisableCustomFields – Turn Repository entities on or off