This scenario guides you through adding users to BRIX. You will add employees, set up your organizational chart, create user groups, and define access permissions for workspaces, apps, and data.
Access permissions in BRIX are configured on several levels. To onboard a user, add them to the system, grant access to required workspaces and apps, and set up permissions for data.
This scenario explains the overall setup logic and does not replace detailed instructions. At each step, you will find links to help articles with detailed descriptions of the steps and required parameters.
Prerequisites before configuration
Before creating users and assigning permissions, determine the following parameters:
- User list: Who will work in the system.
- User roles: What functions participants perform in business scenarios.
- Structure elements: Where departments, positions, and manager assignments are required in the scenario.
- Shared permissions: Which user groups share the same privileges.
- Component visibility: Which workspaces and apps are accessible to each group.
- Data operations: What actions on records are allowed for various roles.
These parameters form the foundation for final user, org chart, group, and access level configurations.
Organizational chart and user groups
To configure permissions properly, it is important to distinguish between the organizational chart and user groups:
- Organizational chart reflects company hierarchy: departments, positions, managers, and employees. Use it when business logic depends on an employee's place in the company.
For example, the org chart is needed to route requests to an author's supervisor, distribute tasks across departments, or alter workflow paths based on employee positions.
- User groups help assign identical permissions to multiple employees.
For example, you can create groups such as Procurement Initiators, Managers, and Procurement Department, then assign them access to workspaces, apps, and data.
The organizational chart and groups complement each other. Both mechanisms can be used within a single scenario.
For example, in the Procurement solution, you can configure the following settings:
- Use groups to control the visibility of the Procurement workspace and the Purchase Requests app.
- Use the organizational chart to identify which manager should receive a request for approval.
- Use both groups and organizational chart data to distribute tasks in a business process.
Начало примечание
Related articles:
- Organizational chart: Learn what an organizational chart is and how company department and position hierarchies are modeled.
- Groups: Learn what groups are and explore the group types available in the system.
Конец примечание
Step 1. Define the access model
We recommend starting your setup by outlining participant roles and their system privileges for the business scenario. Next, create corresponding groups, assign permissions to them, and finally set up individual users.
An example role model in the Procurement solution:
- Procurement Initiators: Create requests and track their status.
- Managers: Approve employee requests.
- Procurement Department: Process approved requests.
- Administrators: Manage settings, users, and access permissions.
After defining roles, determine which workspaces, apps, and data each participant requires.
Начало примечание
Related articles:
- Access permissions in BRIX: Learn how access levels work across workspaces, apps, and data.
- Combinations of access permissions: Learn how different access levels work together.
Конец примечание
Step 2. Add users
Add the employees who will work in the system.
You can add users manually or configure automatic synchronization with an AD/LDAP directory, which is convenient when managing a large number of user accounts.
Before adding users, check your license count and status. If licenses are insufficient, some employees will not be able to start working.
Начало примечание
Related articles:
- Users: Learn how to add, edit, and block internal users.
- Import internal users from AD/LDAP: Learn how to import users from AD/LDAP.
- Licensing: Check the number of active and assigned licenses.
Конец примечание
Step 3. Configure the organizational structure
Build your company hierarchy if your scenario involves departments, positions, managers, or other role-based employees.
The org structure defines relationships among company employees. Its data can be used to assign task performers in business processes, approval routes, and access configurations.
Even when primary permissions are distributed via groups, the org chart operates in parallel to determine managers or responsible departments at various process stages.
For example, in the Procurement solution, the organizational chart helps identify an author's supervisor to route requests for approval, as well as locate procurement department staff to assign request-processing tasks.
Начало примечание
Related articles:
- Organizational chart: Learn how to define departments, positions, and company employees.
- Swimlanes: Learn how to assign business process tasks based on the organizational chart.
Конец примечание
Step 4. Create user groups
Create groups matching the roles approved in your access model.
Groups enable bulk access management: when you add an employee to a group, they automatically inherit its permissions. A user can belong to multiple groups simultaneously.
When integrated with AD/LDAP, group memberships can be imported from an external directory.
For example, an employee can belong to the Procurement Initiators group, while a manager can belong to both Procurement Initiators and Managers. This enables the supervisor to submit personal requests while also approving subordinate documents.
Начало примечание
Related articles:
- Groups: Learn how to create groups and add users to them.
- System groups: Explore system groups available in BRIX.
- Import groups from AD/LDAP: Learn how to import groups from AD/LDAP.
Конец примечание
Step 5. Configure workspace access
Define left menu workspace visibility for your configured groups.
Workspace access allows users to open the workspace and navigate its nested apps. If access is denied, the workspace is hidden from the interface.
For example, grant the Procurement Initiators group access to the Procurement workspace so members can navigate to it and submit requests.
Начало примечание
Related articles:
- Access to a workspace: Learn how to configure workspace access for user groups.
- Workspace administration: Learn how to grant permissions for configuring workspaces.
Конец примечание
Step 6. Configure app access
Once workspace visibility is enabled, configure permissions for the apps within them. This level determines which apps appear to users and whether they can navigate to their pages.
For example, in the Procurement workspace, the Procurement Initiators group must see the Purchase Requests app. At the same time, administrative reference apps can remain restricted to administrators or procurement personnel.
Important: App access does not grant full access to app data. Users may see an app in a workspace without having permission to create, edit, or delete its items.
Начало примечание
Related articles:
- Access to an app: Learn how to configure app access for user groups.
- Arrange workspaces in the menu: Learn how to hide unused apps and reorder them in the workspace left menu.
Конец примечание
Step 7. Configure app data access
After granting access to workspaces and apps, define operation permissions for items inside apps. This level regulates record-level actions: view, create, edit, delete, and full data access.
For example, in the Purchase Requests app, initiators can create documents and view only their own records, managers can view pending approvals, the procurement department can view and edit all approved requests, and administrators hold full data access.
Select a restriction level based on how granular your access controls need to be:
- App level: Applied when an entire group shares identical permissions across all app items.
- Folder level: Used when data is distributed across folders requiring isolated permissions for each folder.
- Item level: Configured when access to a record depends on its parameters, such as the author, manager, or assigned person.
For instance, if procurement employees must view all approved requests, configure general group permissions. If initiators must view only their own requests, apply item-level restrictions.
Начало примечание
Related articles:
- Access to app data: Learn how to configure permissions for viewing, creating, editing, and deleting data.
- Restrict access to all app items: Learn how to set general permissions for all app items.
- Restrict access to folders: Learn how to define distinct permissions for app folders.
- Restrict access to specific app items: Learn how to restrict access to individual app items.
Конец примечание
Step 8. Verify group access permissions
After completing the configuration, verify access from the perspective of users in different groups.
Do not test scenarios exclusively using an administrator account. Because administrators have full access to all system objects, this test will not reflect how regular users experience the workflow.
For each group, verify:
- Workspace menu visibility.
- Availability of required apps.
- Ability to create new items.
- Visibility limited to permitted data only.
- Availability of required actions on records.
For example, in the Procurement solution, test the initiator, manager, and procurement employee roles separately. Ensure that initiators see only their own requests, while procurement staff can view requests assigned to them for processing.
If employees temporarily substitute for one another, configure and test substitution settings.
Начало примечание
Related articles:
- Substitute users: Learn how to set up user substitution.
- Create and work with substitutions: Learn how to create and manage substitutions.
Конец примечание
Step 9. Additionally verify business process access
If your scenario includes business process tasks, ensure assignees have access to the data displayed on task forms.
For instance, during the approval step, a manager must see request details on the task form. If opening a request page from the task is required, the user must have appropriate permissions for that app data.
We recommend configuring task and process instance permissions after completing the baseline setup for users, organizational chart, groups, workspaces, apps, and data.
Начало примечание
Related articles:
- Access to tasks and process instances: Learn how access to tasks and process instances works.
- Access to app data: Explore permission types available for different employees.
- App Item Permissions: Learn how to grant permissions within a business process to complete a task.
Конец примечание
Workflow summary
- Define business scenario roles and access level requirements.
- Add users manually or import them from an AD/LDAP directory.
- Set up the organizational chart for departments, positions, managers, and other roles.
- Create user groups to assign shared permissions.
- Configure group access to workspaces.
- Configure group access to apps.
- Configure access to app data.
- Verify final access settings across user groups and key roles.
- Optionally set up and test user access to required data within business process tasks.