Staff & Permissions
Bearbeitung vorschlagenGive each staff member only the admin permissions needed for their work and verify those permissions in practice.
On this pageJump to a section
Create accountable staff access without sharing the owner account or confusing staff with customer/seller roles.
Start with individual accounts
Use a separate staff account for each person who needs admin access. Keep the owner/administrator account for authorized administration and recovery rather than everyday shared use. A customer account or approved seller is not automatically an admin account.
Admin navigation is permission-controlled. Hiding a menu is not the only protection: server-side authorization must also prevent an unauthorized action. Test with the assigned staff account.
Plan access by responsibility
| Role example | Typical need | Usually not needed |
|---|---|---|
| Catalog editor | Products, categories, media and inventory within scope | Payment configuration or staff administration |
| Order operator | Order review, permitted fulfillment actions and customer contact | Theme code or broad system settings |
| Support staff | Relevant customer/support/order information | Unrestricted exports, credentials or deployment access |
| Administrator | Approved configuration and staff management | Shared credentials across the entire team |
These are planning examples, not fixed built-in role names. Use the roles and permission groups actually available in your release.
Create and verify a staff account
- Open the staff/roles area in Administration using an authorized administrator.
- Create the account with a work email and the role/permissions needed for the job.
- Use the supported password/invitation flow; do not paste temporary credentials into a public chat or shared document.
- Sign in as that staff member in a separate session and verify the required screens/actions work.
- Attempt an action outside the intended role to confirm it is denied, then review access with the responsible owner.
Shop scope and sensitive data
In multishop environments, permissions and the selected shop/context must both match the task. Verify that the staff member is editing the intended store and does not accidentally change another shop’s prices, customers, or settings.
Exports, customer details, payment-related information, support messages, and configuration deserve particular care. Grant access based on need, minimize copies of personal data, and avoid downloading a full customer export to answer one order question.
Maintain access over time
- Review permissions when responsibilities change.
- Disable access promptly when a person leaves or no longer needs the system.
- Review privileged accounts and available activity/audit records periodically.
- Use stronger account protections where the installed admin supports them.
- Keep recovery information with the authorized owner, not in public documentation.
Troubleshoot a missing screen
Confirm the person is using the admin URL and the right account, then check role permission, shop context, feature enablement, and any relevant extension. Do not solve a single missing action by permanently granting every permission. If a denied action appears despite a visible menu, capture the error and verify server authorization.