Six Doors Between a User and Your Data

Every ERP deployment reaches the same three questions, usually in the same month. Who can see customer balances? Can the warehouse keeper delete a saved stock issue? And why does a Jeddah rep see Riyadh invoices?

ERP user permissions in Nama are a chain of doors, and it helps to know that there are six of them rather than one.

1. Authentication — can this person enter at all? Password or LDAP, two-factor, session limits.
2. Menus and navigation — what do they see in the menu in the first place?
3. Type-level permissions — for each kind of record: view, edit, delete, print. And how many times.
4. Record-level visibility — among all the sales invoices in the database, which ones? Dimensions, records-they-created, extra filters.
5. Field, page and list-view permissions — inside a record they may open, which fields are hidden or locked, which tabs show, which list views run.
6. Actions and custom capabilities — may they trigger this specific button, and do they hold the named capability a feature checks for?

Layer four is the one most systems miss, and it is the one the Jeddah question is really about. Screen permission and record visibility are different questions, and answering only the first is how a sales rep ends up looking at another region’s pipeline.

Deny is the default

The order in which a permission check resolves is fixed and short:

• If the profile carries Full Authority, the answer is yes and nothing else is consulted. The built-in admin account works this way.
• Otherwise the user’s own lines are checked first. A line on the user decides, even where the profile says otherwise.
• Then the profile’s lines.
• If no line matches on either, the permission is denied.

That last rule is the one worth dwelling on, because the alternative — allow unless forbidden — is how permission systems rot. It means a new document type, a new module, a screen nobody thought about, all start closed. Someone has to open them deliberately, and the record of who did is the profile itself.

Within each set of lines, a rule naming the specific type wins over one naming a list of types, which wins over the wildcard. So a profile can read: permissive in general, stricter on financial documents, very specific about journal entries.

Roles that scale, exceptions that don’t spread

A Security Profile is a reusable template — typically one per job role, “Accountant”, “Warehouse Keeper”, “Sales Supervisor” — carrying its permission lines, field settings, page security, list-view rules, custom capabilities, extra filters, action security and menu control.

The user record then holds its own local copies of those same tables, and anything defined there overrides the profile for the matching type. The profile gives the role its defaults; the user record makes one exception for one person without loosening the role for everybody who shares it.

Cover, without sharing a password

The purchasing manager is on two weeks’ leave and approvals must keep moving. The common answers — share the password, or promote the stand-in and forget to demote them — are both worse than the one the system provides.

A Temporary Additional Permissions document delegates one user’s permissions to another between two dates. It is a union, never a subtraction: the stand-in keeps everything they had and gains what was delegated, the system asks the delegators only when the user’s own answer is no, and the delegation expires by itself. One document can cover several people or several periods.

At the door itself

Authentication can run against Active Directory or another LDAP directory, with per-user and per-profile exceptions for the service accounts that must stay local — the admin account never authenticates that way. Two-factor authentication accepts an authenticator app, a one-time code sent to the user, or Estidamah, the Saudi identity-verification integration, with individual users exemptible where a shared terminal makes it impractical.