In this guide 6 sections
Plan roles before building. Keep one record for each person and one for the organisation. Define roles once in plain terms, then grant each role access site by site. Name an owner for approvals. This keeps one login for staff while each website shows only what that person needs.
Why several sites make roles harder
A business may run a public website, a dealer portal, a customer portal and an internal admin site. Each was often built at a different time. Each then keeps its own user list, its own role names and its own idea of who is allowed to do what.
The result is familiar. One leaver is enough to show it. A person leaves, and one site still lets them in. Someone changes branch, and three sites need an update. Nobody holds the full picture.
Planning roles once, before any site is built or joined to another, avoids most of this repeated clean-up work.
- Separate user lists on each site
- Different names for the same role
- No single place to remove a leaver
- No record of who approved access
Model the organisation first
Start with the structure, not the screens. Write down the organisation, its branches or departments, and any outside groups such as dealers, vendors and customers. Each group may need a different kind of access.
Give every person one identity. Only one. A staff member who also manages a dealer account is still one person with two memberships. Shared logins, such as one account for a whole branch, break this and should be avoided.
Record which organisation or branch each person belongs to. Many access rules depend on it.
Define roles once, then map them to each site
A role is a named set of actions. “Branch manager” can approve orders. “Sales executive” can create them. Write each role in a sentence that a non-technical person can read and agree to.
Then build a simple grid. Roles run down the side and sites run across the top. In each cell, write what that role may do on that site, or leave it blank for no access.
Keep the number of roles small. A dozen clear roles that everyone understands are easier to run than sixty close variations.
- One plain name and one sentence for each role
- A grid of roles against sites
- Scope by branch, region or customer where needed
- Separate rights to view, create, approve and export
Decide who owns access and who approves it
Every role needs an owner who is not the developer. Often it is a department head. That person decides who gets the role and signs off when it changes.
Set a simple joining and leaving routine. A request names the person, the role and the sites. An approver confirms. When someone leaves, one action removes all access.
Keep a log of grants and removals. It answers questions later, such as who gave a vendor access and when, without anyone searching through old emails.
A worked example and how to start
Take a manufacturer with a public website, a dealer portal and an internal admin site. Staff use one login across the admin site. Dealers log in only to the portal. A regional manager sees dealers in their region on both. A finance executive can export statements but cannot edit orders.
To start, list the sites and the user groups. Draft the role grid in a workshop with the department heads. Review it before any login screen is built.
GullySystem’s custom software work begins with this grid, so each website follows one agreed model.
Role and access grid
A spreadsheet with roles in rows and websites in columns. Each cell states the allowed actions and the scope, such as own branch or all regions. Extra columns name the role owner, the approver and the review date. Agree it with department heads before development.
Open a blank worksheet to printQuestions owners ask
Can staff use one login across several websites?
Yes, where the sites are built to share an identity. Each site still decides what that person may see. One login does not mean the same access everywhere.
Should every site have its own roles?
Share the role names where the work is the same. Add site-specific roles only where a site has a task no other site has.
How is this different from an access audit?
An audit checks what access exists today. Planning decides what access should exist before the sites are built or joined together.
Who should approve access for outside users?
The business owner of the relationship, such as the sales head for dealers. The technical team applies the decision but should not make it.