Fidar Users & Access stacks six permission layers: active modules and roles, then branch, record, field and amount limits. Every decision is made on the server, and the “Why can they see this?” tool shows the exact reason.
Free in every subscription’s core · two-factor sign-in and passkeys on every plan
Problem and solution
Most software only asks whether a user can open a section or not. In reality a sales rep should see their own customers, not everyone’s — and a discount above five percent should go to a manager for approval, not be forbidden outright.
To let a rep do their job, they get full access — including an exportable list of every customer.
Record rules define which records each role sees: own, team, subordinates in the org chart or the whole branch — applied identically in lists, search, reports, exports and the API.
Unit cost, salaries and national IDs appear in every form and report.
Field security has three states per role — hidden, read-only or editable — and the server response is filtered, not just the screen.
A special discount is approved with a chat message and leaves no trace.
Limits and conditions send a document that exceeds a discount or amount limit into a multi-step approval flow instead of rejecting it, with every step recorded.
When an auditor asks why a user could open a document, nobody has a precise answer.
The “Why can they see this?” tool shows the role, scope and rule that granted or denied access for any user and record, and every permission change stays in the immutable audit log.
Capabilities
Start from each module’s system roles and only copy and customise them where there is a real difference. Ten well-defined roles are far easier to maintain than fifty near-identical ones.
Build record rules from the question “who must not see this?” rather than “who should?”. One or two rules such as “owner or team member” and “own branch only” usually cover most needs.
Review the access matrix and the inactive-users-with-roles report every quarter. That is the periodic review auditors ask for, and with Excel export it takes minutes in Fidar.
Integration
Every Fidar module declares its permissions when installed, and all of them pass through one central authorisation service. A rule you write for CRM today will work with the same logic for invoices, inventory and payroll.
The full security architecture is described on Security & access.
Reports
With these reports a periodic access review takes minutes, not days.
Access
Managing access is itself access-controlled. A branch admin only manages users in their branch, and nobody can grant themselves a role above their own.
Security and user accessSubscription (is the module active?), role (may the user perform this operation?), org scope (in which company or branch?), record rule (which records?), field security (which fields?) and limits (up to what amount?). Every request must pass all six. The core idea is explained in what is RBAC.
No. The final decision is always made on the server; record rules and field security apply to lists, search, reports, Excel exports and the API. Hiding buttons is only a convenience.
Yes. Each role assignment has its own scope — for example sales manager in the Tehran branch and sales rep in Isfahan.
One-time codes from authenticator apps, SMS codes and passkeys. Admins can make it mandatory for everyone or for sensitive roles. More in what is MFA.
Nobody. The audit log is append-only and each entry is chained to the previous one, so any tampering is detectable. Retention depends on your plan.
Their account is deactivated, sessions on all devices are closed and their work history stays in place. Records they owned are reassigned to someone else with one bulk action.
Pipeline, leads and deals, kanban stages and revenue forecast.
Pivots, charts and drag-and-drop dashboards on all your data.
One shared list of people and companies for every module.
Turn modules and add-ons on with one click.
Start with the default roles and refine record rules and field security over time — without writing code.