How to set employee permissions in business software

Start with responsibilities, not the “Admin” button

For each role, write three things: the task, the records needed, and the allowed action. “Update the checklist on assigned jobs” is clearer than “needs access to jobs.” Decide whether that includes just their own work, their crew’s work, or the entire company.

This follows the principle of least privilege: enough access to do the work, not every available permission. The University of Missouri’s workstation access standard uses that principle and treats administrator access as something needing a business reason. Its policy governs university computers; the useful lesson for a small business is to justify extra access rather than enable it by default.

• View: read a record without changing it.
• Create or edit: add information or change existing details.
• Approve: authorize a price, adjustment, refund, or other decision.
• Export or delete: take a copy of records out of the system or remove them.
• Administer: change users, access settings, integrations, or account ownership.

These may be separate switches in your software—or bundled together. Read the actual permission descriptions. A job title such as “manager” does not tell you what that account can do.

A sample permissions matrix for a service business

This is a starting example, not a universal policy or a promise that every product supports these controls. It assumes the owner handles financial approvals and the office handles scheduling and billing. Adjust it to your actual responsibilities.

On a small screen, scroll the table sideways. Keyboard users can focus the table area and use the arrow keys.

A bookkeeper may need financial records but not permission to manage employees or edit your website. A crew leader may need to review job completion without seeing wage rates. Give those people a specific role or documented exception, not blanket access.

“Request a change” also needs a real destination: name the person who reviews it. If your software cannot separate drafting from sending an estimate, an owner review rule is helpful, but it is not a technical restriction. Decide whether that limitation is acceptable before enabling access.

Set up the roles in your software

1. Inventory the tools. Include your operating system, email, file storage, scheduling, accounting, website, and payment provider. Access in one does not automatically control the others.
2. Create named accounts. Invite each person through the product’s account process. Avoid distributing the owner’s login to the whole team.
3. Choose the closest limited role. Look under settings such as Users, Team, Roles, or Permissions. Add only the required actions and record scope.
4. Review sensitive permissions separately. Check refunds, price changes, exports, deletion, bank details, user management, and third-party connections.
5. Protect sign-in. Turn on multifactor authentication where supported and keep account recovery under business control.
6. Record and test the result. Save who approved the role, any exception, and when it should be reviewed.

For a concrete example, Square’s permission-set instructions currently put these settings under Staff → Team → Permissions. Its documentation says changes to a permission set affect everyone assigned to it. Check the people attached to a role before editing it for one employee.

Square also notes that its shared team passcode does not track sales, time, or activity by individual team member. That is one reason to check how your product identifies each person instead of assuming any login provides individual accountability.

CISA recommends MFA wherever possible, starting with administrators and people handling sensitive data, and favors phishing-resistant methods. MFA helps protect the login; it does not decide which customer records that person should be allowed to open.

Test what works—and what must be blocked

Use a test account and fictional records in a safe test environment. Do not make test refunds, send real customer messages, or delete live records to check a permission.

Suppose a fictional pressure-washing employee can finish a job but cannot upload its completion photo. Fix that specific permission or workflow. Do not solve the problem by making the employee an administrator.

For custom software, ask the developer to verify restrictions on the server, including direct record links and file access. Hiding a menu item alone is not protection. OWASP’s authorization guidance calls for checking permissions on every request and testing that access rules are enforced. These tests belong on systems you own or are authorized to test.

Repeat the useful-work checks on the phones employees actually use. See what field employees need on their phones for the workflow side of that review.

Update access when someone’s work changes

Missouri State University’s employee access policy ties access to job responsibilities, calls for reevaluation when duties change, and ends authorization when the employment relationship ends. It is a university policy, not a rule imposed on your company, but it illustrates a useful access lifecycle.

When a field employee moves into the office, review the whole role rather than continually adding permissions. Temporary coverage should have an end date. As a practical starting habit, review your active-user list monthly and after role changes; use a schedule appropriate to the risk of your business.

When someone leaves, coordinate the handoff and revoke business access at the appropriate departure time. Reassign open work and ownership of business files, disable accounts, revoke active sessions where supported, remove shared-folder access, and review third-party connections. Change any shared credentials they knew. Check every tool on your inventory, not just the main operating system.

Removing access is different from deleting records. Preserve the job history, invoices, and other records your business needs under its retention requirements. Confirm with your provider what disabling an account does to its files and history before deleting it.

Copy this employee-access checklist

Keep this record in a restricted business location. Employees should know what they can do and whom to ask when a legitimate task is blocked.

The Pebble Creek approach: build around each person’s work

We built our operating system around the real work of our lawn and property-care business. The same philosophy applies to permissions: the owner, office, and field crew should not have to navigate an identical screen full of unrelated information.

A custom business operating system can be scoped around your roles, assigned jobs, approval steps, and existing tools. Those controls need to be designed and tested as part of the project—not assumed from a “custom” label.

If your current software already supports the access you need, configuring it properly may be enough. If it forces you to choose between blocking everyday work and giving everyone too much access, tell us which tasks and roles are causing the problem. We can evaluate what a better fit would involve.