Separate logins solve identity. Roles and groups solve responsibility. They determine who may see prices, maintain users, prepare a cart, place an order, or review activity across a department.
In SoftwareSilo Sublogin, basic subaccount management belongs to the core extension. The more detailed permission model described here uses the optional Permissions & Roles add-on.
Start with jobs, not checkboxes
A useful role represents work someone actually performs. A typical setup might contain:
| Role | Practical responsibility | Typical access |
|---|---|---|
| Buyer | Finds products and prepares purchases | Catalog, product details, cart and own orders |
| Approver | Reviews purchases before release | Relevant orders plus approval actions |
| Branch manager | Oversees a local team | Same group and lower groups |
| Account administrator | Maintains the customer's setup | Users, groups, roles and broad order visibility |
Avoid creating a unique role for every employee. Start with three to five roles, test them with real tasks, and add an exception only when the business can explain why it exists.
What groups add
Roles answer what a user may do. Groups answer whose data the user may oversee. SoftwareSilo can arrange groups in a customer-specific hierarchy and scope group-management permissions to all groups, the same group, or lower groups.
That distinction matters for companies with regions, branches, departments, or cost centres. A branch manager can supervise the local team without automatically becoming an administrator for the whole account.
Permission areas to decide explicitly
The add-on covers more than an "admin" switch. Decisions can include catalog lists, product details and prices, cart actions, coupons, checkout totals, order placement, wishlists, order history, invoices, and management of roles or groups.
Use least privilege as a starting point, but do not make normal work painful. A buyer who can build a cart but cannot see the total, address, or status may need constant help. Test complete journeys rather than isolated menu items.
Roles are not approvals
A role can allow or block an action. It does not by itself create a purchase approval process. If a submitted order must wait for a named reviewer, use the Order Approval add-on. If spending limits matter, use the Budget add-on. These controls can work together, but they answer different questions.
A sensible rollout
- List the people who buy, review, administer, and only observe.
- Map their normal tasks from login to completed order.
- Create the smallest useful role set.
- Add groups only where oversight boundaries really exist.
- Test each role with a representative user and realistic products.
- Document who may assign roles and review access later.
Review access when employees change teams or leave. A clean offboarding process is as important as the initial permission design.
Related reading
Last reviewed: August 9, 2026.