---
title: "Planning RBAC Infrastructure"
slug: "planning-rbac-infrastructure"
tags: ["troubleshooting"]
updated: 2026-07-17T15:02:33Z
published: 2026-07-17T15:02:33Z
canonical: "docs.unqork.io/planning-rbac-infrastructure"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unqork.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Planning RBAC Infrastructure

RBAC (role-based access control) limits what end-users can see or do based on their assigned role. When planning an RBAC infrastructure, thorough testing is essential to confirm the configuration works correctly before deployment. Begin by listing all end-users, then map out which submissions each account requires.

## Creating Test Accounts

As a best practice, use two accounts for every role and group. That way, each role and group can be tested twice to confirm the RBAC is correct. For this example, two agencies exist: **Agency 1** and **Agency 2**. Each agency requires **City Admin**, **Agency Admin**, **Program Manager**, and **Client** roles. For testing purposes, create two accounts of each role for each agency. For example, Agency Admin 1A and Agency Admin 1B for Agency 1. Then, Agency Admin 2A and Agency Admin 2B for Agency 2.

To test the RBAC infrastructure, create unique logins for each account. As a best practice, use variations of the same email address for ease of testing. Begin with the email address, then add a **+** followed by a unique string between the username and the **@** sign. This string should clearly represent the account. For example, the email address for the **City Admin A** account can be `your_email+caa@unqork.com`.

The following table shows an example email address for each account:

| Name | Email |
| --- | --- |
| City Admin A | `your_email+caa@unqork.com` |
| City Admin B | `your_email+cab@unqork.com` |
| Agency Admin 1A | `your_email+aa1a@unqork.com` |
| Agency Admin 1B | `your_email+aa1b@unqork.com` |
| Agency Admin 2A | `your_email+aa2a@unqork.com` |
| Agency Admin 2B | `your_email+aa2b@unqork.com` |
| Program Manager 1A | `your_email+pm1a@unqork.com` |
| Program Manager 1B | `your_email+pm1b@unqork.com` |
| Program Manager 2A | `your_email+pm2a@unqork.com` |
| Program Manager 2B | `your_email+pm2b@unqork.com` |
| Client 1A | `your_email+c1a@unqork.com` |
| Client 1B | `your_email+c1b@unqork.com` |
| Client 2A | `your_email+c2a@unqork.com` |
| Client 2B | `your_email+c2b@unqork.com` |

## Mapping Submission Access

Next, determine which submissions each role should be able to access. Map this out before configuring RBAC; use a spreadsheet, planning document, or any format that works for the team.

The example below shows the completed access map for this infrastructure. Use ✓ to indicate access and leave cells blank for no access. Adapt this structure to match your own role hierarchy and submission types.

| Role | City Admin submissions | Agency 1 submissions | Agency 2 submissions | Program 1 submissions | Program 2 submissions |
| --- | --- | --- | --- | --- | --- |
| City Admin | ✓ | ✓ | ✓ | ✓ | ✓ |
| Agency Admin 1 | ✓ | ✓ | — | ✓ | — |
| Agency Admin 2 | ✓ | — | ✓ | — | ✓ |
| Program Manager 1 | — | — | — | ✓ | — |
| Program Manager 2 | — | — | — | — | ✓ |
| Client 1 | — | — | — | ✓ | — |
| Client 2 | — | — | — | — | ✓ |

## Creating Groups and Assigning Roles

Lastly, create groups and decide which roles should belong to each one. Include only roles that need access to specific submissions in each group. For this example, the groups are **dept-labor-admin**, **agency-1**, **agency-2**, **program-1**, and **program-2**.

The following table shows the role, group, and email assignments for this example:

| Account Name | Email Address | Role | Group(s) | Description |
| --- | --- | --- | --- | --- |
| City Admin A | `your_email+caa@unqork.com` | CityAdmin | dept-labor-admin, agency-1, agency-2, program-1, program-2 | Only City Admins are part of the **dept-labor-admin** group. As admins, they also need access to submission data in all other groups. |
| City Admin B | `your_email+cab@unqork.com` | CityAdmin | dept-labor-admin, agency-1, agency-2, program-1, program-2 | Only City Admins are part of the **dept-labor-admin** group. As admins, they also need access to submission data in all other groups. |
| Agency Admin 1A | `your_email+aa1a@unqork.com` | AgencyAdmin | agency-1, program-1 | An Agency Admin 1 must have access to **agency-1** and **program-1** submissions, but not those in the agency-2 or program-2 groups. |
| Agency Admin 1B | `your_email+aa1b@unqork.com` | AgencyAdmin | agency-1, program-1 | An Agency Admin 1 must have access to **agency-1** and **program-1** submissions, but not those in the agency-2 or program-2 groups. |
| Agency Admin 2A | `your_email+aa2a@unqork.com` | AgencyAdmin | agency-2, program-2 | An Agency Admin 2 must have access to **agency-2** and **program-2** submissions, but not those in the agency-1 or program-1 groups. |
| Agency Admin 2B | `your_email+aa2b@unqork.com` | AgencyAdmin | agency-2, program-2 | An Agency Admin 2 must have access to **agency-2** and **program-2** submissions, but not those in the agency-1 or program-1 groups. |
| Program Manager 1A | `your_email+pm1a@unqork.com` | ProgramManager | program-1 | A Program Manager 1 must have access to **program-1** submissions, but not those in the program-2 group. |
| Program Manager 1B | `your_email+pm1b@unqork.com` | ProgramManager | program-1 | A Program Manager 1 must have access to **program-1** submissions, but not those in the program-2 group. |
| Program Manager 2A | `your_email+pm2a@unqork.com` | ProgramManager | program-2 | A Program Manager 2 must have access to **program-2** submissions, but not those in the program-1 group. |
| Program Manager 2B | `your_email+pm2b@unqork.com` | ProgramManager | program-2 | A Program Manager 2 must have access to **program-2** submissions, but not those in the program-1 group. |
| Client 1A | `your_email+c1a@unqork.com` | Client | program-1 | A Client 1 must have access to **program-1** submissions, but not those in the program-2 group. |
| Client 1B | `your_email+c1b@unqork.com` | Client | program-1 | A Client 1 must have access to **program-1** submissions, but not those in the program-2 group. |
| Client 2A | `your_email+c2a@unqork.com` | Client | program-2 | A Client 2 must have access to **program-2** submissions, but not those in the program-1 group. |
| Client 2B | `your_email+c2b@unqork.com` | Client | program-2 | A Client 2 must have access to **program-2** submissions, but not those in the program-1 group. |

> Add a password column to manage temporary passwords for each account.

Test RBAC before building the full application. Using a simple test application, like the form and dashboard from this example, is an effective way to verify the configuration. Most of the work involves defining clear expectations and generating sample data for testing. This lets Creators confirm that roles and groups are configured correctly before building out the rest of the application.

---

**Changelog**

| Date | Change |
| --- | --- |
| 2026-07-16 | Initial publication. |

RBAC (Role-Based Access Control) is a method to control system access for authorized users. The role in RBAC refers to the levels of access employees have to a network.

Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform.