What are user permissions, and who sees what?

Not everyone in your business software needs to see everything. A sales rep needs their own customers, a warehouse lead needs stock movements, and the finance manager needs cash and bank balances. Salaries and cost prices, on the other hand, should be open only to people whose work requires them.

User permissions are the software’s answer to “who sees what, and who can do what.” They’re usually attached to roles that match job functions, such as “Accounting” or “Sales,” rather than to individual people. A user who’s given a role inherits its permissions, so when someone changes jobs, you change their role instead of hunting down permissions one by one.

Roles, permissions, and scope

In an ERP, access usually comes down to three questions:

• Permission: What can the user do? Viewing, creating, editing, approving, and exporting are separate permissions.
• Scope: Which records? Only their own, their team’s, a branch’s, or a whole company’s.
• Field: Which details of a record? A user might see a customer but not its tax ID or IBAN, or see a product but not its cost price.

A role bundles all three. When a person holds several roles, their access combines those roles. That’s why it matters whether an explicit denial in one role overrides a permission granted by another.

Segregation of duties

Permission design isn’t only about narrowing access. It also keeps one person from handling a transaction from start to finish alone. If the person who issues invoices also records the collections, or the person who approves orders also ships them, that’s an internal control risk.

The four-eyes principle requires the person who creates a record and the person who approves it to be different people.

How it relates to KVKK

Article 12 of Law No. 6698 on the Protection of Personal Data (KVKK), Turkey’s data protection law, requires data controllers to take the technical and administrative measures needed to prevent unlawful access to personal data.

Turkey’s Personal Data Protection Board has prepared a Personal Data Security Guide. It recommends giving employees access only as far as their work, duties, authority, and responsibilities require, and setting up an access authorization and control matrix. The guide’s table of technical measures also lists an authorization matrix, authorization checks, access logs, and data masking.

User permissions in IWB

In IWB, you define roles in Settings and choose an access level for each module: No access, Views, Edits, or Full access. You assign roles to people and departments, and built-in role templates such as Manager, Accounting, Sales, and Warehouse come with the installation.

Which records a person sees is limited by record owner (all records, their own, their team’s, or their subordinates’), by branch, and by company. None of these can widen the visible records on its own, and when roles are combined, a denial takes precedence over a permission. Record rules add conditions to which records a role sees.

For each role, you can set any field to Hidden, Masked, Read-only, or Edits. A hidden field doesn’t appear on screens, in lists, exports, or printouts, or in IWB AI’s answers; statutory outputs such as the general journal and general ledger are exempt. Sensitive details such as national ID numbers and IBANs are hidden by default.

For segregation of duties, IWB comes with 15 built-in rules: 10 conflict rules and 5 four-eyes rules. For example, someone who issues invoices can’t record collections, and someone who approves orders can’t ship them. Each rule either just warns or blocks the action.

The “Who can see what” screen explains step by step why a user can or can’t see a record. Changes to roles, assignments, and field settings are written to the Security Log.