Role-Based Access for Business Software

A role-based access system decides what an authenticated user may do, to which records, under which business scope. Hiding a menu item is not access control. The backend must enforce the same rule when a user opens a direct URL, changes a request, imports a file, calls an API, or uses a mobile app.

For an Indian SME with owners, managers, billing staff, sales users, warehouse operators, accountants, and multiple firms or branches, a good permission model protects data without making daily work unnecessarily slow.

Authentication and authorisation are different

Authentication answers: Who is this user?

Authorisation answers: May this user perform this action on this record now?

A valid login does not grant access to every company, customer, invoice, report, or configuration. Password, OTP, session, and multi-factor controls strengthen identity, while permissions enforce business boundaries after identity is known.

Model permission as object, action, and scope

Every rule should identify three parts.

Object

The business record or capability: customer, lead, product, purchase, invoice, payment, expense, report, user, company setting, backup, or export.

Action

View, list, create, edit, approve, cancel, delete, restore, export, assign, post, refund, share, configure, or impersonate. "Manage invoices" is usually too broad.

Scope

Own record, assigned records, team, branch, location, selected company, all permitted companies, or system-wide. Two managers may share the same role but belong to different branches.

An enforceable permission resembles:

A billing user may create an invoice for the currently selected company using active products from that company, but may not change company GST settings or view another company's invoice.

Role versus permission

A permission is one allowed capability. A role is a reusable collection of permissions. Users receive roles within a context.

Avoid hard-coding every decision as if role === manager. Over time, one manager may approve discounts while another manages stock. A permission layer supports change without scattering role-name checks across the codebase.

Some systems need attributes in addition to roles: record owner, branch, amount threshold, document status, or relationship to the customer. This does not invalidate RBAC; it means the final decision uses role plus context.

Example owner-manager-staff matrix

This is an example, not a universal policy. Build the matrix from actual duties and separation requirements.

Security principles to adopt

The OWASP Authorization Cheat Sheet recommends principles directly relevant to business apps: least privilege, deny by default, validation on every request, appropriate access-control models, logging, and authorisation tests.

Least privilege

Grant only the capabilities needed for current duties. Do not give full admin access merely because a narrower role has not been designed.

Deny by default

When no explicit rule allows an action, deny it. New routes or modules should not become accessible accidentally.

Validate every request

Enforce permission server-side on list, detail, create, update, delete, import, export, report, file, and background actions. Frontend checks improve UX but cannot be the security boundary.

Check object-level access

Permission to view invoices does not imply permission to view every invoice. Verify company, branch, ownership, or other record scope for the requested object.

Keep decisions consistent

Web, mobile, API, export, and scheduled jobs should use the same policy meaning. Duplicate rule implementations drift.

Company and tenant isolation

In multi-company software, the selected company should be validated by the backend against the user's membership. Never trust a company ID sent by the browser merely because it came from a hidden field or local storage.

Queries should be scoped before records are returned. Checking permission after a broad list is loaded can expose counts, names, or documents.

Important company-scoped records include customers, vendors, products, stock, invoices, purchases, payments, expenses, reports, templates, backups, files, and audit events.

Cross-company master copying should be a deliberate authorised operation. It must not copy transaction history, dues, or stock unless that behaviour is explicitly designed.

State and amount restrictions

Permissions often depend on record state.

• Staff may edit a draft invoice but not a posted invoice.
• A manager may approve a discount up to a threshold.
• A refund may require payment status and a second approver.
• A purchase cannot be deleted after stock is received; it needs reversal.
• A former employee's records can be reassigned but audit authorship remains.

Represent these as business rules with clear error messages. Do not use role checks to bypass transaction integrity.

Segregation of duties

For higher-risk actions, one person should not create, approve, execute, and reconcile the same transaction without oversight.

Examples:

• purchase creator and purchase approver;
• payment recorder and reconciliation reviewer;
• user inviter and high-privilege role approver;
• refund requester and refund approver;
• stock counter and large-adjustment approver;
• backup initiator and destructive restore confirmer.

Small teams may not have enough people for complete separation. Use thresholds, owner notifications, strong logs, and periodic review as compensating controls.

User lifecycle

Joiner

Verify identity, assign company membership and least-privilege role, require secure credential setup, and record who approved access.

Mover

When duties or branch changes, remove obsolete permissions before or when new permissions are added. Reassign active leads, tasks, approvals, and operational ownership.

Leaver

Disable access promptly, revoke sessions or tokens, remove integration credentials, transfer owned work, preserve audit history, and confirm that shared accounts are not being used.

Temporary access

Support, accountant, auditor, or contractor access should have purpose, scope, approver, start, expiry, and review. Expiry should be automatic where practical.

Audit logs

Record security-relevant events such as:

• login and authentication changes;
• invitation, role, permission, company, or branch changes;
• exports and bulk operations;
• invoice, payment, purchase, stock, refund, and approval changes;
• backup, restore, configuration, and integration changes;
• access denials where useful for investigation;
• impersonation or support access.

An audit event should include actor, time, action, target, scope, outcome, and relevant before/after values without storing secrets. Protect logs from ordinary modification and define retention.

Files, reports, and exports

Generated PDFs, attachments, reports, and backup files require the same access policy as the underlying data. A difficult-to-guess URL is not authorisation.

For customer-facing document sharing, use a purpose-built public-share token with expiry or verification, limited document scope, and revocation where required. Do not expose an authenticated backend file URL.

Export permission deserves special treatment because a user with read access to one record may not need bulk access to thousands.

Permission design workflow

1. Inventory users and duties

List job functions, companies, branches, teams, and high-risk actions. Observe actual work rather than copying organisation-chart titles.

2. List objects and actions

Break each module into granular actions. Include export, import, bulk edit, approve, cancel, restore, and configuration.

3. Add scope

Define own, assigned, team, branch, company, and cross-company visibility. Resolve what happens after reassignment.

4. Add contextual rules

Document amount thresholds, record states, relationships, and approval requirements.

5. Build roles

Group permissions into understandable roles. Keep a description and owner for each role.

6. Review conflicts

Find combinations that allow users to bypass approval or conceal mistakes.

7. Test and approve

Test allowed and denied paths using realistic records in different scopes.

The permission matrix template provides a structured worksheet for this process.

Authorisation test cases

For each critical action, test:

1. unauthenticated request is denied;
2. authenticated user without permission is denied;
3. permitted user can act within their company and scope;
4. the same user cannot access another company's record by changing an ID;
5. direct API and file access follows the same rule as UI;
6. disabled user or revoked session cannot continue;
7. state and amount restrictions are enforced;
8. bulk and export actions do not bypass row-level scope;
9. audit event records allowed and denied high-risk outcomes;
10. new endpoints deny access until policy is defined.

Tests should cover both horizontal access failures, such as one staff user reading another's record, and vertical failures, such as staff performing an owner action.

Example: multi-company billing suite

One owner manages three firms. Each firm has billing staff, one purchase manager, and an external accountant. Billing staff can create invoices and view their firm's customers but cannot edit company GST details or export all payments. The purchase manager can approve purchases within a threshold. The accountant can view posted documents and reports but cannot create operational transactions. The owner can switch companies and see consolidated platform usage, while transaction data remains company-specific.

The implementation needs membership checks, selected-company validation, company-scoped queries, action permissions, amount thresholds, state rules, protected exports, and audit logs. A navigation-only role menu would not provide this control.

Common mistakes

• using role names directly throughout frontend and backend code;
• hiding buttons without enforcing the API;
• checking module access but not record scope;
• trusting company, owner, price, or approval values from the client;
• giving administrator status to solve a missing permission;
• combining create, approve, cancel, export, and delete;
• retaining access after a user changes duties or leaves;
• exposing PDFs or exports through public predictable links;
• logging secrets or failing to protect audit logs;
• testing only successful owner actions.

Review checklist

• [ ] Authentication and authorisation responsibilities are separate.
• [ ] Objects, actions, and scopes are documented.
• [ ] Access is denied by default.
• [ ] Backend validates every request and target record.
• [ ] Company and branch boundaries are query-scoped.
• [ ] High-risk states and thresholds are enforced.
• [ ] Joiner, mover, leaver, and temporary access flows exist.
• [ ] Export, file, backup, and integration access is covered.
• [ ] Audit events have owners and retention.
• [ ] Allowed and denied tests include cross-user and cross-company attempts.
• [ ] Roles are reviewed periodically against current duties.

How VASUYASHII applies access control

VASUYASHII scopes role and permission requirements during custom software development, including company membership, record visibility, approvals, files, and audit needs. The public Business Suite is positioned around practical multi-company business management, with role capabilities stated according to current scope rather than as an enterprise-security overclaim.

For a permission review, share your roles, companies, branches, modules, approval thresholds, sensitive exports, and current exceptions through contact. Also review the broader web-app security guide.

FAQs

Is RBAC enough for every application?

Not always. Roles provide a useful base, but record ownership, company, branch, relationship, state, amount, and risk may also affect the decision. Use the model that represents the real policy.

Should owners have unrestricted access?

Owners often need broad business visibility, but destructive system operations, secrets, support impersonation, and platform administration can still require separate controls and confirmation.

Is hiding a button a security control?

No. It improves the interface but can be bypassed. The server must authorise the request and requested record.

How often should permissions be reviewed?

Review after role changes and departures, and periodically based on risk. High-privilege, temporary, dormant, and export-capable accounts deserve more frequent review.

What is the difference between role and scope?

The role grants capabilities; scope limits the records on which those capabilities apply. A manager role may view reports, while branch scope limits those reports to one branch.

Should denied actions be logged?

Log meaningful denials for investigation and monitoring without collecting unnecessary sensitive data. Avoid creating excessive noise that no one reviews.