Give an existing identity group the appropriate AI Fabrix role in the intended environment, then check the resulting access as an ordinary user. A group establishes membership; a role grants capabilities; dimensions and protection determine which business records are in scope.
Use Users, groups, and roles for the shared model and AI Fabrix roles to choose an existing platform role. Avoid creating a new role just to distinguish one customer's records from another's.
Prerequisites
- Administrator access to the Controller with permission to manage the selected role's group assignments.
- An existing role in the Role catalog and a provisioned target environment.
- An identity group whose membership is known and visible in AI Fabrix.
- One intended member and one non-member for a bounded access check.
If the group comes from Microsoft Entra ID, first complete identity connection and provisioning. If it is managed locally, confirm its current members before assigning business access. Decide whether the requirement is platform administration or a business capability; those responsibilities use the same catalog but different permissions.
Where it happens
Open the role in the Controller's Role catalog. Its Assigned Groups panel shows environment-specific mappings. Assign Roles opens the group-selection dialog when your account can manage assignments.
The dialog distinguishes assigned groups from the wider available list and supports group search. Environment columns identify where each assignment applies. An unavailable environment must be provisioned through the normal platform process; role assignment does not create it.
Steps
- Select the role whose permissions match the approved task. Review its purpose and permissions before changing membership.
- Inspect Assigned Groups and record the current group/environment mapping. This provides a clear baseline if you need to reverse your own change.
- Choose Assign Roles. Search the available groups and identify the intended group. Similar display names are a reason to inspect the group, not to select several possible matches.
- Select the required environment assignment. A development grant should not become a production grant merely because both columns are visible.
- Save the change and reopen the role. Confirm that the saved mapping appears in Assigned Groups, in the correct environment.
- Ask the intended member to start a fresh session and perform one permitted action. Then test a non-member or an unassigned environment to confirm that the same access was not granted there.
When correcting an assignment, remove only the mapping you intended to change and verify the result again. Some installation-administrator mappings are protected. Use the supported administrator process rather than attempting to bypass that protection.
What done looks like
| Outcome | Evidence to retain |
|---|---|
| Assignment saved | Role, group and target environment agree after reopening |
| Intended member can work | A named permitted action succeeds under that user's role |
| Boundary retained | Non-member or unassigned-environment access remains refused |
| Data scope understood | Record visibility is tested separately where the action reads business data |
Validate
Record who changed the mapping, the test time and the results of both access checks. Do not use Platform Admin as the only test subject: its broader permissions can hide a missing business-role assignment.
If the role is present but a record remains invisible, check dimensions and protection. If the role is absent, check group membership, synchronization and the environment mapping before adding more permissions.
Common mistakes
| Mistake | Correction |
|---|---|
| Group exists but employee is not a member | Correct membership and wait for synchronization |
| Correct role assigned in the wrong environment | Review the environment column and saved mapping |
| Role assignment treated as unrestricted data access | Test record scope separately |
| Creating duplicate roles for each team | Reuse the role and map the appropriate groups |
Limits
Available actions depend on your administrator permissions and installed version. This procedure changes group-to-role assignments; it does not edit a Connected System's capability permissions or certify every governed execution path. Keep production access changes within your organization's review process and retain a working administrator access path.