Configuring Role-Based Permissions Across Every Module: An Implementation Manual

Who this manual is for

This manual is for whoever owns access control on your SAVHN organization — usually an administrator, IT lead, or operations manager. It assumes your organization has already been created (see the organization setup implementation manual) and walks through designing roles, assigning per-module permissions, and confirming screen-level visibility behaves the way you expect before you roll access out to the full team.

Getting this right matters more than it looks. Under-permission your team and you'll spend the first month fielding "why can't I see this" tickets. Over-permission it and you've built a system where a Sales rep can see Payroll figures, which is a trust and compliance problem that's much harder to walk back once people are used to having that access.

Prerequisites

• Your organization and department structure already set up.
• A list of the modules you plan to enable (Module Marketplace configuration can happen in parallel with this, but you need at least a working list before assigning per-module permissions).
• A rough map of your actual job functions — not job titles, functions. "Sales rep," "Sales manager," "Finance clerk," "Finance approver," "HR administrator," and "Read-only executive" are functions; job titles on business cards often blur several of these together.
• Agreement from department leads on who needs access to what. This is a people conversation as much as a system configuration task — don't try to design the permission model alone if you can help it.

Step 1: Inventory the roles you actually need

Before touching the system, write down the distinct roles your organization needs — not the org chart, the access patterns. Two people with different titles who need identical system access are the same role for this purpose; two people with the same title who need meaningfully different access (a senior vs. junior finance clerk, say, where only one can approve invoices) are different roles.

A reasonable starting inventory for a mid-sized organization looks something like: Organization Admin, Department Manager, Sales Rep, Finance Clerk, Finance Approver, HR Administrator, Support Agent, Project Lead, and Read-Only Executive. Your list will differ, but the discipline is the same — keep the number of distinct roles as small as it can be while still capturing real differences in access needs. A role for every person is unmanageable; a single role for the whole company defeats the purpose.

Step 2: Create your roles in the system

For each role identified in Step 1, create it in SAVHN's role management. Give each role a clear, function-based name (avoid internal nicknames) and, where useful, a short description of who it's for — this becomes valuable later when someone new is doing the assigning and needs to know the difference between "Finance Clerk" and "Finance Approver" without asking around.

Step 3: Assign per-module permissions to each role

This is the core of the work. For every module your organization has enabled or plans to enable, go through each role and set what that role can do within that module. SAVHN's permission model works at the module level, so a role's access to CRM is configured independently of its access to Payroll, Projects, or any other module — a Sales Rep role can have full access to CRM and zero visibility into Payroll, which is exactly the point.

Within each module, think in terms of the standard permission tiers: no access, view-only, create/edit, and full administrative control (including sensitive actions like deletion or configuration changes). Assign the narrowest tier that lets each role do its job. It's much easier to widen a permission later when someone hits a real wall than to walk back access someone has already gotten used to having.

Pay particular attention to modules that carry sensitive data by nature — Payroll, Finance, and HRMS chief among them. These should default to no access for any role outside the function that owns them, with explicit, deliberate grants for anyone who needs visibility (a CEO wanting read-only visibility into Payroll totals, for instance, is a legitimate and common request — grant it explicitly rather than by accident through an overly broad role).

Step 4: Configure screen-level visibility

Module-level permissions control whether a role can enter a module at all and what actions it can take there. Screen-level visibility goes a layer deeper — within a module a role can access, specific screens or sections can still be hidden. A Support Agent role might have access to the Tickets module but no visibility into a Billing or Escalation Cost screen inside that same module, if that's not information their function needs.

Walk through each role's module access and confirm that the screens exposed within each module match what that role actually needs to see, not just what the module-level permission technically allows. This step is where over-permissioning most often quietly happens — a role gets broad module access because it needs one screen, and ends up seeing three others nobody thought about.

Step 5: Test each role with a real (or test) account

Before rolling roles out broadly, create a test account for each newly configured role, or ask a real early user in that function to confirm what they can and can't see. Have them attempt the two extremes: something they should clearly be able to do, and something they should clearly be blocked from. Both need to behave correctly — a permission model that only blocks things is as broken as one that only allows things.

Role	What to verify they CAN do	What to verify they CANNOT do
Sales Rep	Create and update leads/clients in CRM	View Payroll or Finance figures
Finance Clerk	Enter and edit invoices in Finance	Approve or finalize invoices (if that's a separate role)
Support Agent	View and respond to Tickets	See internal HR notes or HRMS records
Department Manager	View team's Projects and Timeline activity	Edit another department's role assignments
Read-Only Executive	View Reports and Dashboards across modules	Edit any underlying record

Step 6: Assign roles to users as you invite them

With roles built and tested, assign them as part of the invitation process rather than inviting people first and configuring access after the fact. Every new user should land in the system already scoped to exactly the role their function requires, from their very first login.

Step 7: Schedule a periodic access review

Set a recurring cadence — quarterly is reasonable for most organizations — to review role assignments against who's actually still in each role. People change departments, get promoted, or leave, and access tends to accumulate rather than shrink unless someone deliberately reviews it. This doesn't need to be elaborate: a department lead confirming their team's current role assignments still match reality is enough for most organizations.

Designing for growth, not just for launch day

A permission model built only for the team you have on day one tends to strain within a few months. Think ahead to the shape your organization is likely to take: if you expect to add a second regional office, a new product line, or a support tier structure within the next year, design roles that can accommodate that growth without requiring a full redesign. This doesn't mean building roles you don't need yet — it means naming and structuring the roles you do build in a way that a new department or team can plug into later (see the department onboarding implementation manual), rather than needing bespoke roles invented from scratch every time the organization changes shape.

It also means resisting the temptation to create a one-off role for a single unusual situation. If someone genuinely needs a permission set that doesn't fit any existing role, ask whether that need is likely to recur elsewhere in the organization before building a role that will only ever have one person assigned to it. A permission model with dozens of single-person roles is nearly as hard to maintain as no permission model at all.

How this connects to module rollout

Role design and module rollout are not sequential, one-and-done tasks — they inform each other continuously. Every time a new module is enabled through the Module Marketplace, revisit your role inventory and ask which existing roles need access to it, and at what tier. A module enabled without a corresponding pass through role assignments tends to end up either invisible to the people who need it, or visible by accident to people who don't. Treat permission configuration as a standing item on your module rollout checklist, not a separate project that happens once at the start.

Common Pitfalls

Designing roles around job titles instead of access needs. Titles are political and inconsistent across departments; access needs are concrete. Build the permission model around the latter.

Granting module-level access without checking screen-level visibility. A role technically restricted to "view-only" in a module can still see more than intended if screen-level visibility isn't separately reviewed — the two layers work together, not as substitutes for each other.

Defaulting sensitive modules (Payroll, Finance, HRMS) to broad access "to be safe." This is backwards — broad access to sensitive data is the risk, not the safety net. Default to narrow, and grant explicitly.

Skipping the test step. Configuring permissions and assuming they work as designed, without a real account confirming both what's allowed and what's blocked, is how permission gaps go unnoticed until someone stumbles into one.

Never revisiting role assignments after initial rollout. Access accumulates. A recurring review is the only reliable defense against a permission model that quietly drifts from what it was designed to be.

Frequently Asked Questions

Can one user hold more than one role?

Yes. Users who genuinely span two functions — a Department Manager who is also a Finance Approver, for instance — can be assigned multiple roles, and their effective permissions combine across them. Use this deliberately rather than as a shortcut to avoid designing a proper role.

What's the difference between module-level permissions and screen-level visibility?

Module-level permissions control whether a role can enter a module and what actions it can take there (view, create/edit, or full administrative control). Screen-level visibility controls which specific screens or sections within an accessible module a role can actually see. A role can have edit access to a module overall while still being blocked from a specific sensitive screen inside it.

How do we handle a role that needs read-only visibility into a module it doesn't otherwise use, like an executive wanting to see Payroll totals?

Create an explicit view-only grant for that specific role into that specific module, scoped as narrowly as the actual need — for example, visibility into summary Reports rather than individual employee Payroll records. Don't solve this by adding the executive to a broader role that happens to include Payroll access as a side effect.

What happens to a user's access if we delete or rename a role?

Renaming a role has no effect on the users assigned to it or the permissions it carries — it's a label change. Deleting a role removes it from every user who held it, so before deleting a role, reassign anyone still on it to its replacement (or to no role, if that's intentional) to avoid an unplanned access gap.

Getting started

A well-designed permission model is worth the upfront time — it's far easier to build correctly at rollout than to retrofit after people have gotten used to access they shouldn't have had. SAVHN offers a 7-day free trial if you want to build and test a role structure before committing your whole team to it. When you're ready to move forward, use the pricing configurator to line up your module selection with the roles that will need access to them, or reach out to the developer team for help designing a permission model for your specific organization.