Who Should See What: User Roles and Permissions in a Custom Business System

A new business system goes live on Monday. By Wednesday, a junior technician has opened the full customer list, a cost price has been read out to a customer at the counter, and nobody can say who changed a quoted discount, because everyone shares one "admin" login. None of this needed a hacker, only a system where access was never decided.

This guide is for owners and managers who are about to commission a custom business system, or who already have one and suspect that too many people can do too much. It explains who should be able to see, create, edit, approve, delete and export what, what to decide before the build, how to write and test it, and how to keep it right as staff join, move and leave. It is general guidance, not legal advice, and does not describe any one supplier's product.

Why "who sees what" is a business decision, not a technical one

A developer can build almost any access rule you ask for, but cannot know which rules your business needs: whether a technician should see the customer's full address, whether a branch manager may give a discount, whether the bookkeeper may export every invoice. Those are questions about trust, money and habit.

If you do not answer them, the default is usually one of two extremes: everyone can do everything, because that is quickest to build, or access is so tight that staff share a password just to get work done. The cheapest moment to decide is on paper, before a single screen exists.

Owner, manager, staff: what each role usually needs

Most small businesses can start from three or four roles and add more only when duties genuinely differ. A role is a named bundle of permissions attached to a job, not a person; a new joiner gets the role instead of a new set of rules.

Why least access beats everyone-is-admin

Least access, often called least privilege, means each person gets only the access their job needs, and extra access is added when a real need appears. Giving everyone admin rights feels easier on day one, because nobody is ever blocked. The costs arrive later.

• Honest mistakes get bigger. A person who can delete a customer record will eventually delete the wrong one.
• Sensitive information spreads. Cost prices, margins, staff pay and customer phone numbers are what most often leave with a person, by accident or on purpose.
• Accountability disappears. If everyone can change a price, "who changed it?" has no answer.
• One leaked password opens everything. The more powerful the account, the more it costs you, and a leaver with admin rights is a bigger risk than one with a narrow role.

Least access is not distrust. It is the same reason a shop keeps the cash drawer and the safe key with different people. Good staff are protected by it, because there is no doubt about who touched what.

The six actions to decide for every kind of record

"Can access the system" is far too blunt. For each kind of record (customers, quotations, invoices, jobs, stock, staff files), decide separately who may do each of these:

• See. Open and read it. This can be limited to your own records, your branch, or everything.
• Create. Add a new one.
• Edit. Change an existing one, often limited by stage: free as a draft, locked once approved.
• Approve. Give the final yes: a discount, a refund, a purchase, a leave request.
• Delete. Remove it. Voiding or archiving, with a reason, is usually safer than erasing.
• Export. Download a list or report. It is the permission most often forgotten, and a spreadsheet copy leaves the system and its controls entirely.

What to decide before the build starts

These decisions cost an afternoon now and a change request later. Bring a rough draft to the first conversation; what to prepare before a first conversation shows where it fits.

1. List the roles. Name them by job, not by person, in the smallest set that reflects genuinely different duties.
2. List the records. Customers, quotations, invoices, payments, jobs, stock, suppliers, staff files, reports.
3. Fill in the six actions for each role and record. A one-page grid is enough.
4. Decide the scope. Everything, only their branch or department, or only records they created or are assigned?
5. Mark the sensitive fields. Cost price, margin, staff pay and customer contact details often need tighter rules than the record that holds them.
6. Set the approval rules. Who approves a discount, refund, credit note or price change, up to what amount, and who steps in when that person is away?
7. Name the administrators. Who can add users and change roles, and who is their backup?
8. Decide the exit rule. Who removes a leaver's access, and by when?

A role-by-permission example for a small service business

Below is a made-up grid for a small repair and servicing business. It illustrates the format and is not a recommendation for your business; every cell is something you would adjust.

Notice the patterns: money-moving actions are split into "prepare" and "approve" between different people; the technician sees only what a job needs; the accountant can read and export but not change operations; and only one role manages users. A real grid would also name a second administrator, covered below.

Scope, sensitive fields and approvals

Branch and department scope. A role is only half of the rule; the other half is how far it reaches. A branch manager might see only their own branch's sales and stock, while head office sees all. A sales team might see only the customers assigned to them. Say so for each role, because "manager" means different things in a one-outlet shop and a multi-branch company. For several outlets, see multi-outlet management.

Money, cost and contact fields. Field-level rules let a person open a record yet not see certain fields in it. Typical candidates: cost price and margin, salary and bonus, bank details, and customers' phone numbers and addresses. Asking "which fields would hurt us if they walked out the door?" quickly produces the list.

Discounts and refunds. Decide the limits in plain numbers: for example, staff may offer nothing, a manager up to a limit you set, and anything higher needs the owner. Just as important, nobody approves their own request; a refund that one person both raises and approves is the classic gap. For how quotes become invoices, see quotation to invoice automation.

Writing it into the specification

Access rules that live in a conversation get forgotten or argued about. Put a short section in the specification so they can be built, tested and held to:

• A role list with a one-line description, and the permission grid attached as a table.
• Scope rules in sentences: "A branch manager sees only records where Branch equals their own branch."
• Field and approval rules: which fields are hidden from which roles, the approval limits, and that nobody approves their own request.
• Administration rules: how many administrators, how users are added and removed, and what a new role requires.
• A change clause: adding a role later is a quoted change, so know the cost. See bugs versus change requests for how that line is drawn.

Also check what you can change yourself. Some systems let an administrator edit roles on a screen; others need the developer for every adjustment. Ask which before you compare two custom software quotes, because the answer affects running cost for years.

Testing roles in user acceptance

Most acceptance testing checks that people can do things. Permission testing checks that people cannot do other things, and that part is easy to skip. Build it into the user acceptance testing plan:

1. Create one test user per role and walk the grid: for every cell marked "No", try it and confirm the system refuses.
2. Try the back doors. Paste a link to a restricted page, search for a customer you should not see, open a report, and try the export button.
3. Test the scope. As a branch manager, confirm another branch's records cannot be found in search or reports.
4. Test the approval limits just below, at and above the threshold, and confirm nobody can approve their own request.
5. Test the lifecycle. Disable a user and confirm they are locked out; change a role and confirm the new access applies.
6. Record the result against the grid and fix gaps before the final payment.

Shared logins, and why to avoid them

One login for the whole front desk is tempting, since it saves creating accounts. It also means you cannot tell who did what, cannot remove one person without changing the password for everybody, and cannot give people different access. Every leaver then forces a password change, which in practice gets skipped.

Give each person their own login, and fix forgotten passwords with a proper reset process rather than sharing. Where a counter terminal truly needs a shared account, keep it to non-sensitive functions, change its password whenever someone who knew it leaves, and write down who has it. The same rule applies outside the system: for the hosting side, see cPanel account security.

Admin accounts: how many, and who holds them

An administrator can add users, change roles and often see everything, so the account is the most valuable one you have. Three habits work well for small firms:

• Keep admins few, but never one. If the only administrator is on leave, ill, or has left, nobody can add a new hire or fix a locked account. Two named administrators, usually the owner and one trusted senior person, avoid that single-owner bottleneck.
• Separate admin from daily work. Each administrator keeps an ordinary account for everyday tasks.
• Do not give admin to the developer by default. A builder may need access during the project and for support, but it should be named, limited, time-bound and agreed in writing. Who ultimately controls the system is covered in source code and system ownership.

Record who the administrators are, where recovery details are kept, and who can replace one in an emergency.

When staff join, change role or leave

Permissions drift. A person covers a colleague's leave and keeps the extra access; a promotion adds rights but nobody removes the old ones; a leaver is forgotten. Build a small routine around the three moments.

• Joiners: assign a standard role and record who approved it.
• Movers: replace the role rather than adding to it, so old access does not pile up.
• Leavers: remove access on or before the last day, not weeks later.
• Every quarter, review the user list: does everyone still work here, and does each role still match the job?

A short offboarding checklist for the system:

1. Disable the account on the last working day, or earlier if the exit is unfriendly. Disable rather than delete, so the history stays attached to a name.
2. Reassign their open jobs, quotations and approvals to a named person.
3. Change any shared password they knew, and remove them from shared mailboxes.
4. Remove their access to connected tools, such as email, file storage and messaging groups.
5. Collect devices and exports they hold, and note the date and who did it.

The same tidy-up applies outside the system. If the leaver carried a digital card, see what to do with a digital name card when an employee leaves.

Signs permissions are too loose or too tight

Too tight costs too: people who cannot do their work invent workarounds such as spreadsheets, screenshots or borrowed logins, often worse than the risk you tried to prevent.

Questions to ask a developer

• How are roles set up: fixed in code, or editable by an administrator on a screen?
• Can permissions be set per action (including export), not just per page?
• Can access be limited by branch, department or "own records only", and can fields such as cost or pay be hidden?
• Can approval limits be configured, and can the system stop a person approving their own request?
• How are users added, disabled and removed, and does disabling keep their history?
• Can a second administrator be created without the developer?
• What access will you, the developer, keep after launch, and how is it recorded?

Treat vague answers as information: a developer who has built access rules before answers quickly and in plain words.

A short pointer: audit trails and backups

Roles decide who is allowed to act. Two related safeguards, a record of who did what and when, and tested backups so mistakes can be undone, deserve their own guide. For now, put both on your questions list for the developer.

A checklist before you sign off

• Roles named by job, with the six-action grid in the specification.
• Scope stated for each role, and sensitive fields hidden where needed.
• Approval limits written down, with no self-approval.
• No shared logins; two named administrators, each with an everyday account too.
• Every "No" in the grid tested in acceptance.
• A joiner, mover and leaver routine, a quarterly review date, and the developer's own access recorded.

Common mistakes

• Deciding roles after the build. Retrofitting access costs more than planning it.
• Forgetting export. A restricted list becomes unrestricted once someone can download it.
• Testing only what people can do. The "No" cells are where leaks live.
• Deleting leavers' accounts. The history then loses its names; disable instead.
• Making the owner the only administrator. It creates a bottleneck.

Where Gotka Technologies fits

Gotka's App & System Development service builds mobile apps, web apps and business systems, from an indicative RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once your needs are scoped. This guide is general advice and does not describe any role, permission or security feature of a Gotka system, so ask any supplier, Gotka included, to put the access rules they will build in writing. For the customer-facing side, see customer portals for service businesses; for what each role sees in reports, business dashboards and reporting; for staff records, attendance, leave and claims; and if you are moving old records in, data migration. The team is reachable through the contact page.

Key terms used in this guide

• Role: a named bundle of permissions attached to a job, such as manager or technician.
• Permission: a specific thing a role may do, such as view, create, edit, approve, delete or export.
• Least privilege (least access): giving each person only the access their job needs.
• Admin (administrator): an account that can add users and change roles, and often sees everything.
• Scope: how far a role reaches, such as all records, one branch or only own records.
• Field-level access: hiding fields such as cost price from roles that can open the record.
• Segregation of duties: one person prepares a task and another approves it.