Start with a clean list of every work app and account
Before you introduce single sign-on, list every application the team uses for day-to-day work. That includes accounting systems, file storage, CRM tools, payroll, project tools and any shared logins used by contractors. If your team is split between Woodstock, Johannesburg, Durban or remote offices, ask each manager for their own list because hidden accounts often sit with one person or in an old inbox.
Capture who owns each account, who pays for it, and whether it supports SSO already. This first pass also helps you spot duplicate subscriptions, old trial accounts and personal logins that should be moved into a business process.
- App name and purpose
- Current owner or admin
- Number of users
- Whether it needs SSO on day one
- Any shared access that must be removed
Decide which users need which level of access
Not every staff member should see every system. Set access rules before setup so permissions reflect real jobs, not guesswork. For example, finance may need direct access to banking and invoicing tools, while sales may only need CRM and quotes. The clearer this is upfront, the less time you will spend fixing access later when someone changes roles or leaves.
A practical method is to group people by function and location, then define access for each group. If you run a small team in Cape Town with support in Pretoria or Gqeberha, your access map should still work the same way across branches.
- Full admins
- Managers with approval rights
- Standard staff users
- Temporary or contractor access
- New starter access and exit access
Check your identity setup before any rollout
SSO depends on having a reliable identity source for each user. Confirm that every staff member has one correct work profile, one active email address and a mobile number or recovery method that is up to date. If someone has two profiles or an old personal message still linked to systems, sort that out before moving ahead. It is far easier to fix this now than after users start logging in and getting blocked.
Also check how you want to handle password reset requests, lost phones and new device sign-ins. Load-shedding and weak connectivity can interrupt work, so recovery steps should be simple enough for staff to follow without waiting hours for help.
Define your approval process for new access and departures
Single sign-on makes access easier, but only if your admin process is tight. Decide who approves new user access, who can add apps and what happens when someone leaves. A good offboarding process should remove access on the same day, not at month end. That matters when staff have access to finance, supplier portals or customer data.
Write the steps down in plain language. Include the person responsible, the approval needed, and the order of actions. If the process is clear, your team will spend less time chasing permissions and more time doing actual work.
- New hire request and approval
- Role-based access assignment
- Temporary access for interns or project staff
- Immediate removal when employment ends
- Review of shared accounts and saved passwords
Prepare your team for training and the first week after go-live
Even a simple change needs user training. Staff should know what SSO is, how to sign in, what to do if they get locked out, and who to contact for help. Keep the training short and practical. Show them the login steps on benchtop and mobile, then explain what changes from their current method. A short session with examples from real tools works better than a long policy note.
It helps to plan the first week carefully. Expect a few password resets, a few confused users and some support questions. That is normal. Assign one internal contact per branch or team so issues can be answered quickly, especially when people are working from home or between sites.
Use a short checklist before you switch the whole team
Right before rollout, run one final check. Make sure the app list is complete, user groups are correct, admin rights are assigned, and recovery options work. Test with a small pilot group first, then move the rest of the team once the process is stable. A staged approach reduces disruption and gives you time to sort out small issues before everyone joins.
If your business operates across South Africa, this step also helps with practical realities like different support hours, local internet issues and staff working from phones during travel. A little preparation here saves a lot of admin later.
- All users listed and grouped correctly
- Critical apps confirmed for SSO
- Backup access for admins
- Recovery methods tested
- Pilot users briefed and ready
