Roles & Permissions in Depth

Design least-privilege role sets so people can do their job — and nothing they should not.

4 lessons 35 min 5-question assessment 80% to pass

What you’ll learn

Explain why roles and permissions exist in AWRA

Apply the principle of least privilege

Design role sets that mirror real job functions

Avoid permission sprawl and over-granting

Lesson 1 of 4 Reading 8 min

Roles, permissions, and why they matter

A permission is the right to perform a specific action — view a report, approve a purchase, issue a refund. A role bundles permissions into a job-shaped set, so you assign a person a role rather than wiring up dozens of individual rights. AWRA uses roles to decide what each user can see and do.

Access control is not bureaucracy; it is protection. The right permissions let people work without friction, while the wrong ones expose data, invite mistakes, and weaken the audit trail.

Notice the difference between read and write within the same area, because that is where most over-granting hides. A branch manager almost always needs to see the cost and margin report (read) but rarely needs to edit catalogue costs (write); bundling both into one “manager” role because they sound related is how a viewing right quietly becomes an editing one. Split read from write whenever the action moves money or changes a master record.

Key takeaways

A permission is the right to do one specific action.
A role bundles permissions into a job-shaped set.
Good access control protects data and prevents mistakes.
Separate read from write — seeing a cost report should not carry the right to edit costs.

Lesson 2 of 4 Reading 9 min

Least privilege

The principle of least privilege says each person should have exactly the access their job needs — no more. A cashier does not need to edit supplier contracts; a buyer does not need to delete financial records. Granting only what is needed shrinks the damage any one mistake or compromised account can do.

Least privilege is the single most useful access habit. When in doubt, grant less: it is far easier to add a permission someone asks for than to discover, too late, that everyone could do everything.

The “temporary” grant is where least privilege quietly dies — someone covers for a colleague on leave, gets the extra access, and it never comes off. Make temporary actually temporary: note an end date when you grant it and put a reminder to revoke. A compromised cashier login can only refund or void; a compromised account that still carries last quarter’s stand-in admin rights can do real damage.

Key takeaways

Least privilege means exactly the access the job needs, no more.
It limits the blast radius of mistakes and compromised accounts.
When unsure, grant less and add on request.
Make temporary grants genuinely temporary — set an end date and revoke, or cover-for-leave access becomes permanent.

Lesson 3 of 4 Practice 9 min

Designing role sets

Good roles mirror real job functions — cashier, store manager, buyer, finance officer. Start from what each function actually does day to day, then assign the permissions that support exactly those tasks. Resist the urge to create a near-identical role for every individual.

A small number of clean, well-named roles is easier to reason about than dozens of one-off sets. If two people do the same job, they should usually share a role.

When one person genuinely wears two hats — say a store manager who also covers cashiering — assign them both the manager and cashier roles rather than inventing a bespoke “manager-who-also-tills” role. Stacking standard roles keeps the building blocks reusable: change what a cashier can do once and it updates everyone, including the dual-hat manager, instead of leaving a forgotten custom role behind.

Key takeaways

Roles should mirror real job functions, not individuals.
Assign permissions that support each function’s actual tasks.
Few clean roles beat many near-identical ones.
For dual-hat staff, stack two standard roles rather than minting a bespoke one, so the building blocks stay reusable.

Lesson 4 of 4 Reading 9 min

Avoiding permission sprawl

Over time, access drifts: people change jobs, temporary grants become permanent, and "just give them admin" creeps in. This sprawl quietly erodes control until no one is sure who can do what. Periodic review — does this person still need this? — keeps roles honest.

The danger of over-granting is that it is invisible until something goes wrong. A tidy, reviewed permission structure is a control that pays off precisely on the day you wish you had it.

Tie the review to events you already have: every time someone changes role or leaves, adjust or disable their access that same day — the leaver whose login still works months later is the textbook breach. A quarterly “who has admin?” check takes ten minutes and almost always turns up one or two people who no longer need it. Disable rather than delete departed users, so their historical actions stay attributable in the audit trail.

Key takeaways

Access drifts over time toward over-granting.
"Just give them admin" is how control quietly erodes.
Periodic review keeps roles aligned with real need.
Adjust access the day someone changes role or leaves, and disable rather than delete so their history stays attributable.

| AWRA OpsHub

Roles & Permissions in Depth

What you’ll learn

Course content

Roles, permissions, and why they matter

Least privilege

Designing role sets

Avoiding permission sprawl

Finished the material?

More in this path

Workflow Builder Basics

Approval Workflows

Security & Data Protection

Need a quick answer while you read?

AwraIQ