Roles and permissions: clear rules with business examples

The real problem: people seeing data they should not

A “data leak” at work often looks boring. A support agent opens a customer profile and sees the full payment history. A client logs in and spots internal notes like “Offer 20% if they complain” or the real cost and margin on an invoice. Nobody stole a password. The app simply showed the wrong thing.

Most leaks happen by accident. Permissions get added late, a new screen ships quickly, or someone copies an old role that was “good enough” for testing. Then a small change, like adding a new field to a table, quietly becomes visible to everyone.

That’s why roles and permissions should be a first-class part of the app, not a last-minute checkbox. Most small businesses end up with the same four role types: Owner, Manager, Staff, and Client.

The goal is simple: each person should see only what they need to do their job, and nothing else. That includes the data behind the scenes, not just the screens you expect.

If you’re building quickly in a no-code platform like AppMaster, this matters even more. Speed is great, but it also makes it easier to accidentally expose private notes, pricing rules, or other customers’ records if access isn’t designed up front.

Roles, permissions, and scope: simple definitions

Roles and permissions are the rules that decide who can do what inside an app.

• A role is a job label like Owner, Manager, Staff, or Client.
• Permissions are the specific actions that role is allowed to take.

An access level is the practical result of those rules. Two people can both be “Staff,” but one has a higher access level because they can approve refunds while the other can’t.

A reliable way to prevent mistakes is to start with minimum access, then add only what the person needs to do their daily work. If someone never edits invoices, don’t give them edit rights “just in case.” It’s easier to add access later than to undo a data leak.

Most permissions boil down to a small set of actions: view, create, edit, delete, and a few higher-risk actions like export or approve.

Scope answers a different question: “Which records can they do that to?” Someone might be allowed to view invoices, but only their own, not everyone’s.

Typical scope patterns are:

• Own records (only items they created or are assigned to)
• Team or location (their branch, department, or project)
• Whole company (all records across the business)

A sales rep might create and view their own quotes, but can’t export the full customer list. A sales manager can view the whole team’s quotes and approve discounts. The owner can view everything and export reports for accounting.

What owners, managers, staff, and clients usually need

Most apps end up with the same four groups of people. The details change, but the pattern doesn’t. If you start with clear roles and permissions, you avoid a lot of awkward “why can they see that?” moments later.

Owners typically need full visibility across the business. That often includes billing, security settings (like password rules and MFA), and audit history so they can review who changed what and when.

Managers need to run a team without being full administrators. They usually need oversight (see everything in their department), approve actions (discounts, refunds, time off, content changes), and read reports. They may need limited admin actions, like inviting staff or resetting a password, but not access to billing or global security controls.

Staff should be able to do day-to-day work fast, with minimal risk. A safe default is “only what I’m assigned.” A support agent sees only their tickets, a dispatcher sees only today’s routes, and a salesperson sees only their leads. Exports and bulk downloads should be off by default and enabled only when there’s a real need.

Clients should see only their own data, even if multiple people share an account. Let them do limited actions (create requests, pay invoices, update their profile), but keep internal notes, staff comments, and internal statuses hidden.

A set of defaults that works in many businesses:

• Owner: everything, including billing, security, and audit logs
• Manager: team data, approvals, reporting, limited user management
• Staff: assigned records only, no bulk export, no admin settings
• Client: their records only, no internal notes, limited actions

Break access down by data type, not just by screen

Many teams set roles and permissions by screen: “Staff can open the Orders page, clients can’t.” That helps, but it misses the real risk. The same data shows up in search, comments, notifications, exports, and attachments.

Start by listing your data areas, not your menus. High-impact areas usually include customer contacts, orders and delivery status, invoices and payment status, salaries and HR notes, and internal notes or analytics.

Then decide what each role can do with each data type: view, create, edit, delete, approve, and share. This is where field-level rules matter. The same object often needs a public view and an internal view.

Example: an Order might include customer name, delivery address, price, internal margin, and an internal note like “Customer complains a lot, offer discount.” A client should see the address and status, but never the margin or the internal note. A manager might see all fields plus the ability to approve discounts. Staff might see the fields they need to deliver, but not finance details.

Files and attachments deserve extra caution. Contracts, IDs, receipts, and screenshots often contain more sensitive info than the form fields. Treat them as a separate permission: who can upload, who can download, and who can view file previews. Also decide if attachments inherit access from the parent record (like an invoice) or have their own rules.

Finally, don’t treat exports and bulk actions as “included” just because someone can view a list. Make them explicit: export to CSV/PDF, bulk download attachments, bulk status changes (approve, cancel, refund), bulk messaging (email/SMS/Telegram), and admin actions like reassigning records.

Business example 1: sales and invoicing app

Imagine a small service business: the owner sells projects, managers supervise jobs, staff do the work, and clients approve quotes and pay invoices. The fastest way to avoid awkward mistakes is to agree on roles and permissions before anyone logs in.

Start with money details. Pricing can be visible to more people than profit. A common rule is: staff can see what to charge, but not why you chose that price. A technician might need line items to explain an invoice, but they don’t need internal margin, supplier cost, or the special discount you gave to win the deal.

Client data is another hotspot. Many teams want multiple people to view contact details (so they can call the right person), but only a few to edit them. Otherwise you get accidental overwrites like the billing email being replaced with a personal email, and invoices stop reaching accounting.

A simple setup that works well for many teams:

• Owner: sees everything, including margin and discount history, and can change payment status
• Manager: can create quotes and invoices, approve discounts, and edit client contacts
• Staff: can view assigned client details and invoice line items, but can’t edit pricing rules or see margin
• Client: can only see their own quotes and invoices, and can pay or request changes

Lock down high-risk actions. Marking an invoice as paid, issuing a refund, or changing a payment method should be limited to the owner (or a trusted finance role).

Business example 2: support desk with internal notes

A support desk looks simple: customers send messages, your team replies, and tickets get closed. The problems start when the same ticket view is reused for everyone. One wrong setting, and clients can see internal notes, tags, or even staff performance stats.

Picture a small e-commerce business with a shared support inbox. A ticket includes the customer message, order details, shipping status, and internal notes like “possible fraud, verify ID” or “VIP, prioritize.” That internal context helps the team, but it should never be visible to the customer.

A clean split that keeps sensitive data safe:

• Client: sees their own messages, public status updates, and the final resolution. No internal tags, no staff-only notes.
• Staff agent: sees customer messages and only the customer data needed to solve the issue, like order history. Can add internal notes and tags.
• Manager: sees everything staff sees, plus reassignment controls and SLA overrides.
• Owner/admin: sees all tickets across the business and high-level reporting.

Client PII is the next trap. Support often needs a phone number or address, but not on every ticket. A good rule is: show sensitive fields only when the workflow requires them. For example, show the address only after the agent selects “shipping issue,” and hide it again when the ticket closes.

Keep internal metrics separate from the customer experience. Things like “time to first reply,” “agent score,” or “escalated to legal” belong in staff and manager views only.

Business example 3: operations and delivery tracking

Picture a warehouse and field team running deliveries all day. One person plans routes, another picks items, and drivers complete stops. If your app shows the wrong details to the wrong people, it’s not just awkward - it can expose customer addresses, pricing, or internal notes.

Start by separating what each group needs every day.

Staff (pickers and drivers) usually need a tight, task-focused view. A driver should open the app and see only today’s assigned jobs, with the stop order, contact details for that stop, and delivery instructions. They shouldn’t be able to browse the full customer list or see jobs assigned to other drivers. If they cover a shift, a manager can reassign a job instead of giving broad access.

Managers need the wider operational picture. They should see schedules for all teams, inventory counts, and what’s going wrong right now (late deliveries, failed drops, damaged items, missing signatures). They also need tools to resolve exceptions: reassign a stop, split a route, or approve an inventory adjustment.

Clients need the smallest view: their own delivery status only. They can track the ETA, see proof of delivery, and get updates like “out for delivery” or “delayed.” They should never see other customers, route maps for the whole day, or internal exception notes.

A simple way to enforce roles and permissions here is to scope data by assignment and by customer account. For example, a Delivery Job record can be readable only by (1) the assigned staff member, (2) managers, and (3) the client tied to that order.

Step by step: how to design roles and permissions

Start by naming your user groups in plain language. “Owner”, “Manager”, “Staff”, and “Client” are a good start, but only if they match how your business works. For each group, write what success looks like in one sentence, like “Managers can assign work and see team performance without seeing payroll.”

Next, map actions to data areas. Don’t think in terms of screens first. Think in terms of what data exists, and what people can do with it. A simple grid on paper is enough:

• List your roles and the data areas (customers, orders, invoices, tickets, reports).
• For each role, write the actions they need (view, create, edit, approve, export).
• Decide scope for each action (own, team, or all).
• Define “team” clearly (branch, region, project, or direct reports).
• Mark any “never” items (for example, clients never see internal notes).

Then test your draft using real tasks, not guesses. Walk through common flows like “create an order”, “resolve a ticket”, and “download a report”. If a task forces you to give broad access, you probably need a missing permission (like “view totals” without “export”).

Add approvals where money or sensitive changes happen. Staff can draft an invoice, but only a manager can approve or send it. Staff can edit delivery addresses, but changing bank details requires owner approval.

Common mistakes that cause accidental data leaks

Most data leaks in small teams are not hacks. They happen when the app quietly gives someone more access than their job needs. Roles and permissions fail when they’re set once and never revisited.

A common pattern is giving someone full admin access “just for setup”. The rush passes, but the access stays. Weeks later, that person exports a full customer list to “help with a report” and private data is sitting in a spreadsheet.

Mistakes that show up again and again:

• Making “Admin” the default role because it avoids support questions
• Allowing broad exports (customers, contacts, payouts, invoices) without limits or audit
• Sharing one login across a shift team, so you can’t tell who viewed or changed what
• Securing the main screens but forgetting side doors like mobile views, PDFs, email notifications, attachments, and auto-filled forms
• Not offboarding: ex-employees keep access to the app, email inboxes, or saved sessions on their phone

The side doors are the sneakiest. You might block staff from seeing a contract screen, but still email them the PDF as an attachment. Or your mobile layout might show extra fields that were hidden on desktop.

A practical fix is to treat exporting and downloading as separate permissions, not a normal “view” right. If a role needs a list, give them a filtered view instead of a full export.

Quick checks before you invite real users

Before you invite real users, assume someone will click the wrong thing, share a screen, or download a file they shouldn’t have. A few checks now can prevent a painful cleanup later.

Start with defaults. When a new user is created, they should land in the lowest role automatically, with no access to money, exports, or admin settings. If someone needs more, make it a deliberate change.

Next, test the client experience like a stranger would. Clients should only ever see their own records, even if they change URLs, search, or filter. A quick test is to log in as Client A and try to find Client B by name, invoice number, or support ticket ID.

Five fast checks that catch most leaks:

• Hide sensitive fields by default (salary, cost/margin, personal IDs, internal notes)
• Lock down exports and bulk actions
• Add approvals where mistakes are expensive (refunds, payouts, role changes)
• Confirm scope is enforced everywhere (screens, search results, API responses)
• Make sure you can audit changes: who changed what and when, including role updates and payment actions

Do an “accident test.” Ask a teammate to complete a real task using a staff account, then try the same task using the client account. If the client can see internal pricing, download full customer lists, or trigger a refund, your permissions are too broad.

A realistic scenario: one app used by staff and clients

A common request starts like this: a client wants a portal to “check status,” but your staff already uses the same system to run the work. Without clear roles and permissions, the portal can expose internal notes, other clients’ orders, or staff-only pricing.

Picture a custom printing company. One order goes from quote to production to delivery to invoice, all inside one app.

Here’s what each role should see in that workflow:

• Owner: everything, including profit, staff performance, and all client accounts
• Manager: all orders for their team, internal notes, and the ability to approve discounts and refunds
• Staff: only the orders assigned to them, the next step to complete, and the contact details needed to do the job
• Client: only their own orders, high-level status (Approved, In production, Shipped), delivery proof, and invoices they must pay

Two edge cases usually break the model.

First, a manager temporarily covers another team. Don’t switch them to Owner. Instead, add a time-limited scope, like access to Team B orders for 7 days. When the cover ends, the access expires.

Second, a VIP client asks for “more visibility.” Give more context without giving more data. Show an expanded timeline or a dedicated message thread, but keep internal notes (like “client is late on payments” or “reprint due to our mistake”) staff-only.

Responsibilities change, so treat access as something you review, not something you set once. When someone changes roles, avoid piling on permissions. Remove what they no longer need, then add the smallest set required for the new job.

Next steps: set a clear access policy and implement it

Start small. Pick one workflow that matters most, like “create invoice and take payment” or “log support ticket and reply.” Define roles and permissions for that single flow first, then expand.

Put the rules in one simple table and treat it like a living document: role, what they can do, what they can’t do, and any limits (like “only their own records” or “only their location”). When someone asks, “Can staff see client phone numbers?”, the table should answer in seconds.

A practical rollout:

• Draft the table for your first workflow (Owner, Manager, Staff, Client)
• Map each rule to specific data (including fields) and actions (view, edit, export, delete)
• Create demo accounts for every role and test real tasks end to end
• Launch to a small group, then expand once you see no surprises
• Review access quarterly, and immediately after org changes (new manager, new team, new vendor)

If you’re building on AppMaster (appmaster.io), it helps to plan roles alongside your data model and business logic so the same rules apply consistently across web apps, mobile apps, and API endpoints.

If you want, write your first access table today and try it on one workflow. That single step prevents most accidental data leaks.