Skip to main content
A user accesses Bold. A permission profile groups permissions. A permission enables a specific capability. Together, they form people’s access model for the application.

Entities

A user and employee can be linked, but they are different concepts. The user answers “who enters and what can they do?”. The employee answers “who works, records time or contributes to costs?”.

Capability types

Permissions distinguish capabilities with different effects: A permission defines access but does not remove data rules. For example, a document’s status can prevent an action even if the user has the corresponding permission.

Permission profiles by responsibility

Profiles represent reusable responsibilities. They do not need to mirror every person in the company.
Write permissions can change stock, costs or traceability. Temporary or external profiles should not include capabilities outside their responsibility.

Permissions by module

Some capabilities combine more than one module. For example, uploading evidence may require file access as well as permission for the functional element. Managing users, profiles and permissions requires an application administration profile. It is not an operational People permission.

Illustrative example

Marta can be both a user and an employee: If she only needed to record work through an operational identity, she could exist as an employee without a user with administrative access.

Access for integrations and automations

These identities are not interchangeable. See Integration keys and external notifications to learn about the scope of technical credentials.