Plan requirement
| Subscription | Suite Enterprise or higher, Support Enterprise |
| Access | Admin |
A role built to fit an actual job. Start from what somebody must not do, not from what they need.
Create one
- Open the roles in Admin Center.
- Create a role, or clone the closest standard one.
- Name it for the job it describes.
- Set the permissions.
- Assign one person and have them work a real day with it.
Clone rather than start empty
Beginning from the agent role and adjusting is faster and less error-prone than assembling permissions from nothing, where it is easy to miss something ordinary.
Name it for the job
"Team lead" or "Billing agent", not "Agent role 3". A role nobody can interpret gets assigned by guesswork, and it survives every reorganisation unquestioned.
Design from the prohibitions
What must this person not be able to do? Delete tickets, export data, change triggers, see another team's work. Those are the decisions; everything else can stay as the standard agent has it.
Starting from "what do they need" produces roles that grow until they are admin in all but name.
Test it with a real day
Assign it to one willing person and let them work normally. They will find the missing permission within an hour, and that is far better than a checklist review.
Keep the number small
Four or five roles for most organisations. A role per person is not access control, it is a maintenance burden that nobody will keep accurate.
Write down why it exists
One line per role: who it is for and what it deliberately withholds. In a year that note is the difference between adjusting it confidently and leaving it alone.
Comments
0 comments
Article is closed for comments.