Design, assign and verify agent roles for a B2B support team

Updated Wednesday, October 28, 2026 · Marcel Gravelle

An agent role defines the Supportbench capabilities a staff member can use and the configured Division scope for case visibility. A useful role lets people complete their assigned work while making administrative and customer-data responsibilities explicit. Start with the job someone needs to perform, configure the smallest suitable permission set, then verify it through a representative agent session. Role creation, assignment and successful access testing are three separate steps.

At a glance

For: support administrators, operations leads and managers who approve staff access. Applies to: Supportbench Core.

Start here: Settings → Organization → Roles, then Settings → Organization → Agents

Separate permissions, Division and team · Translate the job into observable tasks · Prepare a controlled access change · Create or revise the role · Understand the consequential Division selection rule · Assign the role through the agent profile · Test real work and the intended exclusions · Example: an equipment specialist who collaborates with account support · Review roles when responsibilities change · Troubleshoot access without widening it blindly

Separate permissions, Division and team

Control	Operational purpose	Do not assume
Agent Role	Security permissions and administrative capabilities, with a configured Divisions scope.	A role name such as Supervisor automatically grants the intended permissions. Inspect its actual settings.
Role → Divisions	Limits the configured case-visibility scope.	An empty selection denies access, or Division membership is the only case-access rule.
Agent profile → Division	Keeps the agent’s category visibility and assignments aligned with their operational area.	It replaces the role’s permission and Division settings.
Agent profile → Primary team	Supports team organization, assignment, routing and dashboards.	Membership automatically creates a queue or grants every case/admin permission.
Customer role	Classifies customer relationships and participates in supported customer access/mapping configuration.	It is the staff agent role used in this procedure.

Case visibility also depends on permission and record-level rules. Core checks the case-view permission, and an agent’s own assigned case can be a separate access path. Therefore a role’s Division selection is not a complete description of all customer-data security. Test the actual record and action the person will use, including ownership exceptions.

Translate the job into observable tasks

Write a short access specification before opening the permission editor. “Front-line agent” is a useful role name only when the expected tasks are clear. Include the support area, required customer context, permitted case actions and which settings the person is responsible for maintaining.

Responsibility	Questions for the access design
Front-line case work	Can the agent find the intended cases, read relevant Company/Contact context, reply, add internal notes and hand off work? Which actions require supervisor involvement?
Specialist support	Which Divisions and queues supply the investigation work? Can the specialist collaborate without receiving unrelated administrative permissions?
Supervisor	Which team workloads and reports are needed? Which assignment, escalation and case-management actions are part of the job?
Knowledge contributor or reviewer	Which authoring, review and publication actions are required? A role alone does not replace the knowledge-review group configuration.
Configuration administrator	Which specific settings must this person maintain? Does viewing a page need a different permission from saving its records?
Temporary access	What task, scope, owner and review date justify the change? Plan removal through a deliberate role/profile review.

Prefer a small number of understandable roles over one unexplained role for every person. Conversely, do not combine unrelated responsibilities simply to avoid maintaining another role. A copied administrator role is not a safe shortcut for fixing one missing button.

Prepare a controlled access change

Identify the existing role and every agent who uses it. Editing a shared role affects more than the person who reported the problem.
Record the current role, Division scope and relevant profile assignments so the approved setup can be restored if the test fails.
Choose a representative test agent and approved test records. Include a permitted case, a case in an excluded Division and a case assigned directly to the agent where that exception matters.
Confirm role-edit permission for the administrator. Editing another agent’s profile requires the separate profile-edit permission; profile-view access alone is not sufficient.
Agree the required and prohibited actions with the operational owner. Include exports or administrative actions only where they are part of the real responsibility.
Keep a working authorized administration route while testing. Do not remove your own necessary administration access as an experiment.

Create or revise the role

Open Settings → Organization → Roles.
Choose New Role or open the exact existing role you intend to change. Check its current use before editing a shared definition.
In Role Profile, enter a recognizable name and description and review Active role. The name is required and allows up to 50 characters; the description allows up to 250.
If using Copy Role, select an appropriate active source in Copy from, then choose Apply. Applying copies permissions and Division scope; the target’s name, description and active state are retained. Review the copied result instead of treating the source role’s name as proof of suitability.
Open Divisions and choose the intended scope using the rules in the next section.
Open Permissions. Search the available groups and read the individual permission labels. Enable the capabilities required by the agreed tasks and review any broad administration or data-changing permissions.
Choose Save Changes. Reopen the role and confirm its saved profile, Divisions and permissions before assigning it to more people.

The configuration reference lists the permission catalog in detail. Use it to interpret the controls, then validate the workflow that matters to your team. A page appearing in navigation is not proof that every action on that page is authorized.

Understand the consequential Division selection rule

Select none does not mean deny all

Current Core stores an unrestricted Division scope when the selected set is empty or contains all active Divisions. To create a narrower role scope, select a proper subset: some active Divisions, but not all. Do not use Select none to lock a role out of every Division.

Saved selection	How to interpret it
Some, but not all, active Divisions	A restricted configured Division selection. Selected roots include descendants; test a case outside those selected branches.
All active Divisions	Unrestricted Division scope, rather than a permanently fixed allow-list of today’s names.
No Divisions selected	Also normalizes to unrestricted scope. It is not a deny-all configuration.
Case owned by the agent	Ownership can be a separate access path, subject to the required permission and other rules. Test it explicitly.
Case without a Division	Uncategorized cases (category 0) are a separate admitted path in the current case-access check. Verify the actual case-view permission and record result.

When a new Division is introduced, review roles with unrestricted scope as well as roles with selected Divisions. A configuration that was appropriate for one department may be too broad after another business line joins the same account. Recheck actual behavior after configuration refresh rather than relying on an old screenshot of the selection.

Assign the role through the agent profile

Open Settings → Organization → Agents and select the intended agent. Verify the identity before changing an account with a similar name.
Open Assignment & routing in the profile.
Set Role to the reviewed role. Review Division and Primary team separately; choose values that match the person’s operational assignment. Review Manager where applicable.
Save the profile and reopen it to confirm the intended values. Adding a new agent and editing an existing one require their respective profile permissions.
Have the test agent refresh their session or sign in again before checking the new result. Compare the assigned role and saved permissions if the existing session still shows old behavior.
Complete the positive and negative workflow checks below before broad assignment.

Do not change a Contact or Company Customer role when the problem is a staff member’s permission. Those are separate identities and may affect customer-facing access rather than the agent workspace.

Test real work and the intended exclusions

Test	Expected evidence
Open an allowed case	The representative agent can find and read the intended record through the normal workspace.
Perform the required case actions	The relevant reply, note, assignment or other authorized action is available and completes correctly on approved test data.
Open an excluded-Division case	Use a record outside all selected Division branches that the agent does not own. Separately test child Divisions, directly assigned cases and uncategorized cases.
Attempt an unneeded administrative action	The role does not provide capabilities outside the agreed responsibility. Use a read-only permission check or safe test; do not make destructive changes to prove access.
Review Company/Contact context	The customer context required for the job is available without assuming the case Division alone defines every customer-record boundary.
Use reporting or export where required	Check the visible scope and actual output audience, not just that the menu item exists.
Use knowledge review where required	Verify the role permission plus the configured reviewer/submitter eligibility and actual article workflow.

Record the tested role, agent, saved scope, record IDs, session refresh and observed outcomes. If a test fails, change the specific responsible permission or scope and repeat the affected check. Do not grant broad administration to make an unexplained error disappear.

Example: an equipment specialist who collaborates with account support

Define the handoff and access together

A specialist investigates recurring equipment failures while account support owns customer communication. Operations lists the specialist’s needed case and asset context, the relevant Division and the permitted collaboration actions. The administrator creates or revises a role, assigns it to a representative specialist and tests the normal case path plus a directly assigned exception. The handoff still states who owns the customer update; access to a case does not automatically accept operational ownership.

If the specialist cannot find an expected case, compare the actual record, ownership, Division and required permission before changing the role. If the problem is queue membership or assignment eligibility, correct that configuration rather than expanding unrelated role permissions.

Review roles when responsibilities change

Review shared roles when a new Division, integration, reporting process or administrative feature is introduced.
When a person changes teams, review Role, Division, Primary team, queue participation and outstanding case ownership as distinct items.
When temporary work ends, remove the unnecessary capability through the approved role/profile change and verify the result.
Keep descriptions current so a future administrator can understand why the role exists. Use available audit information to investigate changes without claiming every action is represented by one record.
For offboarding, use the dedicated account-offboarding process. Deactivating or renaming a role is not a complete offboarding workflow.

Troubleshoot access without widening it blindly

Symptom	Checks and next action
Agent can see more Divisions than expected	Check whether the saved selection is empty or all-selected, then review the assigned role and ownership exceptions.
Agent cannot save a record they can view	Check the specific edit permission, not only navigation or view access.
Changing the profile Division did not produce the expected restriction	Review Role → Divisions and record-level case access separately.
Role was copied but access is broader than intended	Inspect both copied permissions and Division scope; the target name does not limit the copied capabilities.
Assigned role appears unchanged in the session	Reopen the saved profile, confirm the role, then refresh permissions/sign in again and repeat the same record test.
Agent has the role but receives no queue work	Review queue membership, assignment candidates, availability and routing independently.
Knowledge review is unavailable	Check author/reviewer permissions, review-group eligibility, article state and audience.
A customer access problem is reported	Use the customer portal/Contact/Company role guides. Staff roles are not the customer authentication configuration.

Was this article helpful?