USER ACCOUNTS · ROLES AND PERMISSIONS
Clear responsibility.
Access based on the actual job.
Permissions determine which parts of the administration a user can open and which actions they may perform. Organize them according to responsibilities so each person can do their job with the appropriate scope of access.
Available menus and actions depend on the account, vendor, configuration, and activated services. This guide provides a framework for agreeing on permissions, while the specific capabilities should be verified in your system.
Go through the guide
Account, affiliation, and permissions are not the same
User account
Identifies the person signing in and their access details.
Vendor or store
Defines the business context in which the person should work.
Permissions
Define the capabilities and actions available in that context.
If a person sees the wrong store, first check the affiliation and selected context. Adding more permissions does not necessarily resolve an incorrect vendor selection.
1. Write down the tasks before selecting permissions
For each person, specify which data they need to review, what they need to edit, and which changes must be approved by another responsible person. Distinguish between reviewing data and actions that change the business.
- Products: descriptions, images, prices, and availability.
- Orders: reviewing details, processing, and changing status.
- Content: pages, translations, and publicly published information.
- Business settings: available store, shipping, and payment settings.
- Users: assigning accounts, changing permissions, and revoking access.
The list describes business areas. It does not mean that each area has one separate permission or a role with the same name in every administration.
2. Have an authorized person approve the assignment
Access is assigned by a person with the appropriate permissions, or the request is coordinated with the Connect team. Specify the user, vendor, and required scope of work.
If the system offers user groups or predefined roles, check what they include before selecting one. The role name alone is not enough to determine all permitted actions.
Do not assign full access just because one action is unavailable. First determine which capability is needed and why.
3. Verify the result with the user
After the change, ask the user to reopen the required part of the administration and follow the instructions for refreshing access or signing in again if necessary. Compare the capabilities actually available with the agreed tasks.
Do not test the right to delete by deleting a real product or test the right to process by changing a real order without agreement. For such actions, define an appropriate verification method and test data.
- The user is working with the appropriate vendor.
- They can review the required data and perform the agreed actions.
- They understand which changes must be coordinated in advance.
- The person who approved the change and the related task have been recorded.
When to review existing permissions
Check access when a team member joins or leaves, when their tasks change, and when new business processes are introduced. Review temporary additional permissions again after the task is completed.
If the user still cannot see the required menu, also check activated services, filters, and the selected store. Send Support an example task and the system message instead of assuming that all permissions need to be enabled.
Frequently asked questions
Why do two team members have different menus?
They may have different permissions, vendor affiliations, or available services. Compare their tasks and context before requesting a change.
Does a visible menu mean I can change everything in it?
Not necessarily. The availability of individual actions may differ from the right to view them. Check the specific task and the messages displayed by the system.
Are the business roles from the guide ready-made permission packages?
No. The examples are intended to divide the work. Actual roles and capabilities depend on your administration settings.
