Enterprise Security: Role-Based Access Control in Petriko CRM

As operational scope grows, access control becomes a governance problem - not just a security one. The early question of "who has access to the system" becomes a more complex set of questions: who can do what, in which part of the business, and with whose data?

In a single-entity operation with a small team, the distinction rarely surfaces. Everyone who needs access has it, and the trust model is simple enough to manage informally. But as the team grows and as the business expands to multiple entities, the informal model breaks down. A workshop mechanic shouldn't have access to payment records. A finance officer shouldn't be able to close subscriptions without review. A staff member scoped to one entity shouldn't be able to see or modify data belonging to another.

Generic admin/non-admin role models can't express these distinctions. They force a binary choice between too much access and too little. Petriko approaches this differently - access control is per-module, per-action, and per-entity from the start.

Five Permission Levels, Applied Per Module

Petriko's RBAC model applies five distinct permission levels - View, Create, Edit, Delete, and Approve - independently to each operational module. The modules are: Customers, Fleet, Subscriptions, Workshop, Payments, Staff, and Administration.

This produces a permission matrix rather than a simple role. A staff member can be configured with view access to fleet records, create and edit access to workshop jobs, view access to customer profiles, and no access to payment records or administrative settings. Another staff member might have view and approve access to payments but no write access to any other module. The configuration matches the actual structure of the job role, not a simplified approximation of it.

Role configuration is an operational task in Petriko, not a development one. Roles are managed through the admin panel, changes take effect immediately, and there is no deployment or configuration file involved.

The roles panel displays the permission matrix in full - every module, every level, clearly indicating what each role can and cannot do. New roles can be created for specific job functions, and existing roles can be adjusted as responsibilities change.

Practical Roles in a Fleet Operation

In a fleet subscription business, the practical role requirements are specific:

A workshop mechanic needs to see fleet records to understand the vehicles coming in, create and edit job cards, and view customer contact details for communication. They do not need to see payment history, modify subscription terms, or access administrative settings.

A finance officer needs to see subscription records to understand what's contracted, view and approve payment records, and access the Xero and Ezidebit integration status. They do not need to create fleet records, modify job cards, or manage staff access.

An operations manager needs a broad view across all modules - fleet, customers, subscriptions, workshop - but may not need write access to financial approvals or system configuration.

An entity administrator needs full access within their entity, cross-entity visibility, and access to system configuration including RBAC role management.

Each of these can be precisely expressed in Petriko's permission matrix without compromise.

Governance at Scale

The governance properties of a well-designed RBAC model compound as the business grows. When a new staff member joins, their access is provisioned from the role matrix - the role defines what they can do, and assignment takes minutes. When someone leaves, access is revoked from one place. There is no need to audit individual permissions or track down access that was granted ad hoc.

In a multi-entity business, entity scope adds another dimension. Staff can be provisioned for one entity, both entities, or specific modules within each - without requiring separate system logins. A staff member scoped to one entity sees only that entity's data. A manager with cross-entity access sees both. The scope is explicit, configurable, and enforced at the data layer - not a UI-level filter that can be bypassed.

The Approve permission level is particularly important in financial workflows. Payment approval - the ability to mark a collection for retry, write off a balance, or approve a suspension - requires explicit grant of the Approve level on the Payments module. View and Edit access to payments is not sufficient. This separation ensures that financial actions with significant operational consequences require deliberate provisioning, not just general system access.

Access control is infrastructure. When it's per-module, per-action, and per-entity from the start, it scales without becoming a governance liability as the business grows.