Extensions

Role-Based Access Control

Each person in your AI product's admin can see and change only what their role allows.

When everyone in the admin can change everything, one wrong click can rewrite your agent's answers or expose data that should stay private. This add-on adds roles and permissions to the AI product you already run. You decide the roles, such as viewer, editor and admin, and what each may see and change. Each role is tested, including actions it must not take.

Limits each person to what their role allows
Documents every permission in a written map
Tests each role against actions it must not take

$2,500 10–20 working days

Choose delivery and add to cart Ask an expert

Key board with differently tagged keys on hooks, each role given only the access it needs.

What it is

Role-Based Access Control adds user roles and permissions to an AI product you already run, or are buying now. You decide the roles, such as viewer, editor and admin, and what each may see and change, and the product enforces them. Each role is tested, including blocked actions.

Why businesses buy it

As more people use the product's admin, the risk of an accidental change grows: a new starter edits a live answer, or a contractor sees data meant for managers. Roles give each person the access their job needs and no more, which also makes compliance reviews easier. The written scope covers designing the roles with you, a written permission map, assigning people and tests for each role, including blocked actions. You know exactly who can do what before it goes live.

Problems this solves

Everyone with a login can change everything in the product

Role-Based Access Control adds roles such as viewer, editor and admin. You decide what each role may see and change, and the product enforces those limits.

Sensitive settings get edited by people who only needed to look

Viewers can read without editing, and only the roles you name can change settings. Each role is tested before launch, including the actions it should be blocked from.

Nobody is sure who is allowed to do what in the product

The roles and their permissions are written into the updated documentation. Managers can check who has access against one clear list, instead of guessing from memory or asking around.

Scope card SKU UPM-A0027

Role-Based Access Control

Everything this build includes, written down before you pay. Choose how you want it, own the code or license it yearly, then the delivery speed and any add-ons.

$2,500 one-time build price

What is included

Channel: As per the parent product
Integrations: As described in the add-on
Knowledge: As per the parent product
Workflows: Adds user roles and permissions to an existing product
Languages: As per the parent product
Testing: Tested together with the parent product
Revisions: 1 round
Handoff: Written handover report
Support: 14 days after launch

A good fit if

More than a few people use the product's admin, and today everyone can change everything.

Some staff should only view conversations or reports, not change settings or knowledge.

Sensitive records should be visible to a smaller group.

You can describe two or more roles and what each should be allowed to do.

Not the right fit if

You only need staff to sign in with the company login. Single Sign-On Setup handles sign-in.

You want to control what the AI agents themselves may access and do. AI Agent Permission System defines that.

You want role-based access across many AI tools and data sources at once. AI Access Control System is the wider build.

You need a record of who did what, not limits on what they can do. Audit Logging Add-on adds the record.

How it works

Roles are agreed. We list who uses the admin and group them into roles.
Permissions are mapped. For each role, what it can view, change, approve or export.
Roles are built into the product's admin, so screens and actions follow the permissions.
People are assigned to roles, or roles are taken from your identity provider if SSO is in place.
Each role is tested with the parent product, including attempts to do what it should not, then reviewed with one revision round.

What you provide within 72 hours

Your portal lists these the moment you order. Delivery starts the working day after everything is in and your access is checked.

The order reference of the product getting roles
A list of the people who use the admin and what they do
Which records or settings are sensitive
Your identity provider details, if roles should come from SSO groups
One person who approves the permission map

The 72-hour rule. Send everything on your checklist, including access, within 72 hours of ordering so your build starts on time.

Timeline

Start Users and sensitive areas listed

Week 1 Roles and permission map agreed

Week 2 Roles built into the admin

Week 2 Each role tested, including blocked actions

Week 2 Your review and one revision round

Go-live Roles live, permission map documented

Delivery options, in working days (Monday to Friday) from completed intake. They can extend because of national or public holidays, technical issues outside our control (such as platform outages, third-party changes, account approvals or access delays), or natural disasters and other events beyond our control. If a delay happens, we tell you in writing with a new date.
Option	Delivery time	Price
Standard	10–20 working days	$2,500

What you receive at handover

User roles and permissions added to your existing product
A role list showing what each role may see and change
A test report covering every role, including blocked actions
Updated documentation, a handoff note and a short written walkthrough

Expected benefits and how to measure them

Helps prevent accidental changes by people who only need to view
Makes access easier to review and explain
Can make it safer to give more staff access to the product

Unwanted changes: Count settings changes that had to be undone in the months before and after roles were added.
Users per role: Review the user list each quarter and confirm each person sits in the right role.
Access requests: Track requests for more access each month to see whether the roles fit how people work.

Before you start: List current users and what each one actually needs to do in the product. Note any recent changes that were made by mistake.

These are things to track, not promised results. Outcomes depend on your data, your team and your market.

Running costs

Roles add no running cost of their own, and anything the product already uses stays billed to your accounts as now. We charge once for the setup.

Ask about running costs

Custom requirements

Field-level permissions, approval chains tied to roles, or roles for customers rather than staff are beyond this add-on. Note them at checkout for a written Change Quote. Larger or bespoke projects go through the Custom AI request form instead.

Request a custom version

Keep it running

Roles are covered by the parent product's maintenance, which grows in line with the add-on's price. Adding a role or changing a permission uses its monthly change hours.

Adds $125/mo to maintenance

Covered by the main product's maintenance, which grows by this amount.

How maintenance works

How this compares

	Do it yourself with a SaaS tool	Hire a custom agency	Upmark Labs
Price	Role controls on a higher monthly tier	An agency quotes permission work	Ours is one fixed price, shown before you buy
Roles	Preset roles you cannot change	Agreed during the project	Ours are designed around your team
Proof	Trust the settings	Depends on the brief	Ours tests each role, including actions it must not take
Record	Settings screen only	Depends on the brief	Ours includes a written permission map

Questions about this product

How many roles can we have?

As many as your team genuinely needs, agreed at intake. A handful, such as viewer, editor, approver and admin, keeps the map simple, because every extra role is another thing to maintain. We help you group people so the map stays simple and each role is tested.

Can roles come from our SSO groups?

Yes, if Single Sign-On Setup is in place or bought alongside. People's roles can then follow the groups they belong to in your identity provider, so moving someone between teams updates their access without anyone editing the product. Without SSO, your admin assigns people to roles inside the product instead.

How do you test that a role cannot do something?

For each role, we sign in as a test user and try both the actions it should be allowed and the ones it should not. Blocked actions must be refused. The results for every role are in the test report you approve before launch.

Can roles be added after our product is already in use?

Yes. Roles are designed around your current team and applied to the product as it runs today, with everyone assigned before the switch-over. If you are buying the product now, the roles follow its delivery speed. Faster speeds are available, each with a fixed price and date shown before you pay.

Does this limit what the AI agent can do?

No. These roles limit what people can do in the product's admin. Limiting what the AI agent itself can access and do is a different job, handled by AI Agent Permission System or by the Approval Workflow Layer for selected actions.

Who looks after the roles after launch?

Your admin assigns people to roles day to day, using the walkthrough and the written permission map. Changes to the roles themselves, such as a new role or a changed permission, are handled under the parent product's maintenance. The permission map is kept with your documentation, so a new admin can see why each role exists.