Overview
Every ERP deployment reaches the same three questions. Who may see customer balances? Can a warehouse keeper delete a stock issue that has already been saved? And why is a sales rep in Jeddah looking at Riyadh’s invoices?
Nama ERP answers them with a layered model — a chain of doors a user must pass through before a record reaches their screen. Each layer is configured independently, so you can be permissive where it costs nothing and strict exactly where it matters.
The layers
- Authentication. Can this person enter at all? Login and password, LDAP, two-step verification, session limits.
- Menus. Which menu items exist for them in the first place.
- Type-level permissions. For each record type — invoices, items, journal entries — what may they do? View, edit, delete, print, revise, and how many times.
- Record-level visibility. Of all the sales invoices in the database, which ones do they see.
- Field, page and list-view permissions. Inside a record they may open, which fields are hidden or locked, which tabs appear, which list views are allowed.
- Actions and custom capabilities. May they trigger a particular button, and do they hold the named capability a given feature requires.
Features
Profiles for roles, overrides for people
A security profile is a reusable template, normally one per job role — Accountant, Warehouse Keeper, Sales Supervisor — carrying its permissions, field settings, page rules, list-view rules, extra filters, action rules and menu controls. Assign it to as many users as hold that role.
The user record then carries its own local copy of the same tables, and anything set there overrides the profile for that type. So the role defines the norm and the person carries the exception — one buyer who may approve above the usual limit does not require a second profile that must be maintained forever after.
Visibility that follows your org chart
Almost every record carries five organisational dimensions — legal entity, branch, department, sector and analysis set — and each one either holds a value or is marked public, meaning “no restriction on this axis”. A user’s session carries the same five, so a document is stamped with them on creation and filtered by them on search. Record visibility is then narrowed through four independent mechanisms:
- Dimensions — the Jeddah rep sees Jeddah, because the record knows which branch it belongs to.
- Creator-only — a user sees only what they raised themselves.
- Extra filters — a row-level filter per type, for the cases the first two do not express.
- Record capabilities — tag individual records as requiring a named capability, for the genuinely sensitive few.
Because dimensions are part of the data rather than a reporting convention, a multi-company group runs in one database with each company seeing its own records — which is what makes consolidated reporting possible without merging anyone’s books.
Hide the field, not just the screen
Access does not have to be all-or-nothing at the document level. A field can be hidden or made read-only, a whole page within a record can be hidden or locked, and individual list views can be allowed or blocked — so a user can work with a document without seeing its cost prices or margins.
Delegation
Responsibilities can be handed to a stand-in for a period, and the rest of the system understands it — notifications reach the stand-in automatically, and approval steps can be delegated rather than stalling.
Read the full security documentation.
