Start With Real Roles, Not Job Titles
Before you assign access, write down how work actually happens in the business. A job title can be useful, but permission settings should follow tasks. In a 12 person team, the person handling invoicing may also manage supplier records, while in another branch that job is split across two people. Start there, not with a generic chart.
For South African small businesses, this matters even more when staff work across Johannesburg, Pretoria, Durban, Gqeberha or from home. A sales rep, for example, may need customer details and quotation tools, but not payroll records or finance folders. An operations lead may need admin access to several systems, but not full ownership of every app.
- List each role and the systems used daily
- Note which tasks need view only access
- Mark anything that requires edit, approve or export rights
- Separate permanent needs from one off project access
Group Access By Function, Not By Person
It is easier to manage permissions when people are placed into groups such as Finance, Sales, Operations, Support or Management. That way, if someone joins or leaves, you update the group rather than editing ten different systems one by one. It also reduces mistakes, which is handy when teams are busy and power cuts interrupt the day.
A good group structure should reflect how your business runs. A Cape Town based team might have one group for customer service and another for field staff, while a national team could add region based groups for local reporting. Keep it simple enough to maintain, but clear enough that nobody wonders why they have access to the wrong folders.
- Create groups for departments first
- Add region based groups only when needed
- Use temporary groups for short term projects
- Avoid assigning permissions to individuals unless there is no other option
Match Each System To Its Own Access Rules
Not every application should follow the same permission pattern. Your accounting tool, file storage, CRM and internal chat all serve different purposes, so the access rules should differ too. A team member may need full edit rights in one system and read only access in another. That is normal and usually safer.
When you map permissions, look at the highest risk actions first. Can someone export data? Can they delete records? Can they approve payments or change security settings? Those are the permissions that need careful control. If a role does not need a certain function, remove it. Simple access is easier to manage and easier to audit later on.
- Identify admin, editor and viewer access levels for each app
- Restrict exports and deletions to a small group
- Limit payment and billing permissions to authorised staff
- Keep system owners separate from day to day users where possible
Build A Permission Map Before Rollout
A permission map is a plain list of who gets what, and why. It does not need to be complicated. In fact, the best ones are usually short, readable and easy to update. Include the role, the system, the access level and the reason for that access. If a manager cannot explain a permission in one sentence, it probably needs another look.
For businesses setting up across South Africa, this step saves time during remote onboarding. When staff in Durban and Stellenbosch need access on the same week, a clear map prevents confusion and keeps setup consistent. It also helps when someone is on leave and another team member has to step in quickly.
- Role name
- System name
- Access level
- Approval owner
- Review date
Plan For Joining, Moving And Leaving Staff
Permission mapping is not only about onboarding. It must also cover role changes and exits. People move between teams, take acting roles, or cover for colleagues during leave. If you do not have a process for those changes, access tends to pile up over time and no one knows who can see what.
When someone leaves, remove access on the same day where possible. That includes shared systems, saved login details and any admin rights used for setup. If a person changes department, review their access immediately so they keep what they need and lose what they do not. It sounds basic but many businesses only notice the problem after a customer query or an audit.
- Use a standard offboarding checklist
- Review access when a person changes role
- Check shared accounts and old sign ins
- Record who approved each access change
Review Permissions Every Quarter
Quarterly access reviews are one of the easiest ways to keep permissions sensible. Sit down with each team lead and ask a few simple questions: who still needs this access, what changed this quarter, and which rights can be removed? This is especially useful for seasonal teams, growing companies and businesses working across multiple branches.
Reviews also help when a system has been used in a rush and later forgotten. A password manager and single sign on setup works best when access stays tidy. Otherwise, the team starts collecting old logins, repeated passwords and unnecessary admin rights. That creates avoidable risk and slows people down when they should be working.
- Check all active users against current staff lists
- Remove access for former contractors and temporary staff
- Confirm who still needs admin rights
- Update the permission map after every review
Use A Simple Checklist Before You Switch On Access
Before you give anyone access, run through a final checklist. This keeps the setup practical and avoids mistakes during rollout. For small business teams, the aim is not perfection. It is sensible control that is easy to understand and easy to maintain.
At 1Pass, we work with teams that need a clean structure from the start, whether they are in Woodstock, Johannesburg, Pretoria, Durban, Gqeberha or working remotely nationwide. The key is to keep the process straightforward so staff can log in, get to work and avoid chasing passwords across too many systems. That saves time and reduces support calls later on, which is always better for a small team.
- Have roles been confirmed by the business owner or manager
- Are admin accounts limited to the right people
- Have temporary permissions got an end date
- Has the team been shown how to request changes
- Is there a review date booked in
