--- title: Roles and Permissions | Shopware Community Hub description: >- Learn how roles group permissions in a B2B company account, and how roles can be managed in the storefront or from the customer’s Company tab in the… canonical_url: >- https://hub.shopware.comhttps://hub.shopware.com/learn/unit/roles-and-permissions --- # Roles and Permissions - Understand why B2B permissions are grouped in reusable roles. - Identify which company-account actions B2B role permissions can control. - Create a role, assign permissions, and assign the role to an employee. - Understand that roles can be managed in the storefront and from the customer's Company tab in the administration. # Roles and Permissions A company is not a flat list of identical buyers. Some people may only prepare orders, others approve them, and a few manage the whole account. If you tried to configure each person individually, large companies would become unmanageable and inconsistent. Roles provide the solution. A **role** is a reusable bundle of permissions that you assign to employees. Instead of answering "what can this person do?" for every individual, you answer "what can a buyer do?" once, and every buyer inherits it. This learning unit shows you how to design roles, assign them to employees, and understand where roles can be managed: In the storefront by authorized employees, or from the customer's Company tab in the administration. ## Continue in Your Learning Environment Use the learning environment from the previous unit to follow the role configuration flow. If you have not opened it yet, open it here before you continue. For this learning unit, use a B2B-enabled customer account with Employee Management active. You can follow the role workflow in the storefront as an authorized employee or in the administration from the customer's **Company** tab. ## Why Roles Instead of Per-Person Settings The core idea is inheritance: > A role defines a set of permissions once. Every employee assigned to that role inherits those permissions. Change the role, and every employee in it changes with it. This approach offers three practical benefits. 1. Setup is faster because you configure a responsibility once and reuse it. 2. Consistency improves because every buyer has identical access by definition. 3. Maintenance is simpler because adjusting one role updates everyone in it instead of requiring per-person edits. That is why thoughtful role design pays off. The role is the place where a responsibility becomes a reusable access model. Depending on the active B2B modules, roles can also become relevant for assigned addresses, budgets, and quotas. You will meet those settings later in this learning path. In this learning unit, focus on the permission model: A role groups access rights, and employees inherit them through their assigned role. A small amount of planning upfront makes role management much easier later. Most companies only need a handful of well-designed roles that can be reused as employees join, leave, or change responsibilities. ## What Permissions Cover B2B role permissions are focused on the company account itself. Depending on the active B2B modules, permission groups can include areas such as: - **Employee management**: Who may add, edit, or remove employees. - **Role management**: Who may create and change roles. - **Orders**: What an employee may do with orders, such as placing them or acting within the approval process. - **Quote and approval workflows**: Who may request quotes, change quotes, or approve pending orders. - **Organisation units and addresses**: Who may view or change units and related addresses. - **Budgets and order subscriptions**: Who may view or manage budgets and recurring orders. Not every company needs every permission group. Start with the responsibility of the role, then select only the permissions that match that responsibility. Keep the boundary clear: These permissions govern actions inside the **storefront company account**. They are unrelated to the permissions of your own administration users. A buyer with order permissions can act in their company's storefront account; they have no access to your administration. B2B role permissions only affect what an employee can do inside their company's storefront account. They never grant access to the Shopware Administration. Keep the two permission systems mentally separate. ## Create and Assign Roles Roles belong to the B2B customer's company account. They can be managed in two places: - Authorized employees can manage roles from the storefront **Roles** area. - Shop administrators can manage roles from the customer's **Company** tab in the administration. The following steps use the storefront workflow first, because this is the customer-side role management experience. ### Create and Assign Roles in the Storefront 1. Log in to the storefront as an employee who may manage roles. 2. Open the account menu and open **Roles**. ![Storefront: Account Overview: Roles Section](assets/images/storefront_customer_overview_roles_tab_overview_create_role_button.jpg) 3. Create a role for one responsibility, for example **Buyer**. Select the order permissions this role needs. If the company uses Organisation Units, prefer scoped permissions that limit access to the assigned Organisation Unit. Add further permissions only when this buyer should handle another task, such as quote requests. ![Storefront: Create New Role Part 1: Config](assets/images/storefront_customer_overview_roles_tab_overview_create_new_role_1.jpg) ![Storefront: Create New Role Part 2: Save Button](assets/images/storefront_customer_overview_roles_tab_overview_create_new_role_2.jpg) 4. After saving the role, assign it to an employee. Open the **Employees** tab and select the employee who should receive the role. ![Storefront: Account Overview: Employees Section: Edit Employee Button](assets/images/storefront_customer_overview_employees_tab_edit_employee.jpg) ![Storefront: Edit Employee: Assign Role](assets/images/storefront_customer_overview_employe_assign_role.jpg) ![Storefront: Account Overview: Employees Section: Role Assigned](assets/images/storefront_customer_overview_employe_role_assigned.jpg) That's it. You have now created a role and assigned it to an existing employee. Because employees inherit the role, you do not configure access for each employee individually. Assigning the appropriate role is enough. The **All permissions** option is only suitable for a role that should manage the whole company account. Do not use it as a shortcut for normal buyer or viewer roles. Every employee assigned to that role receives the selected permissions. ### Manage Roles in the Administration As a shop administrator, you can also create, edit, assign, or verify roles from the customer's **Company** tab in the administration. Open the customer, select **Edit** in the top-right corner, and then work with the role options in the **Company** tab. ![Administration: Account Overview: Company Tab: Verify Employee and Role](assets/images/administration_customer_company_tab_employee_and_roles_verify.jpg) If role options appear disabled in the administration, first check whether the customer profile is in edit mode. Select **Edit** in the top-right corner before you assume that the role settings are read-only. As a customer's organisation grows, authorized employees or shop administrators can continue reusing existing roles or introduce new ones without restructuring the entire company account. A well-designed role model scales naturally with the business. ## Example: Three Roles for One Company Return to the company with Mara, Tom, and Lena. You design three roles: | Role | Employee Management | Role Management | Order and Approval Permissions | |---------|----------------------|------------------|-----------------------------------------| | Manager | Yes | Yes | View orders and approve pending orders. | | Sales | No | No | View orders and request quotes. | | Viewer | No | No | View orders only. | Other companies may need different roles: - **Department approver**: can approve pending orders for their team, but cannot manage employees or roles. - **Accounting viewer**: can view orders and documents, but cannot place orders or change the company setup. You assign Mara the manager role, Tom the sales role, and Lena the viewer role while she is in training. Later, when Lena joins the sales team, you simply change her role from viewer to sales, and she immediately gains the sales permissions. You did not touch any other employee, and you did not reconfigure individual permissions. This is the benefit of a role-based design: staffing and responsibility changes become single, safe actions. ## Quick Check Before you continue, use this quick check to verify that you understand why role-based permissions are easier to maintain than individual permission changes. A trainee is promoted to buyer. With well-designed roles, what is the cleanest way to update their access? Edit each individual permission on the trainee's employee account one by one. Change the employee's assigned role, so they inherit the new role's permissions. Grant them an Administration user account. ## Common Pitfalls Before you finalize a role model, check whether it still reflects real responsibilities instead of individual shortcuts. ### Pitfall 1: Giving Everyone the Manager Role If every employee can manage employees and roles, the structure collapses and approval becomes meaningless. Grant management permissions only to those who genuinely need them. ### Pitfall 2: Confusing B2B Roles With Administration Users A B2B role never grants access to the administration. If someone needs to work in the administration, that is a separate administration user, not a B2B employee role. ### Pitfall 3: Designing Roles per Person Instead of per Responsibility If you create a unique role for every individual, you lose the reuse and consistency that roles provide. Design roles around responsibilities, then assign people to them. ### Pitfall 4: Forgetting Order Permissions in the Approval Context Order permissions interact with approval rules. A role that should require approval still needs the ability to place orders; the approval rule then decides what happens next. You will configure that interaction in the ordering course. ## Summary In this learning unit, you learned: - Why B2B permissions are grouped in reusable roles. - Which company-account actions B2B role permissions can control. - How roles can be created, assigned, and managed in the storefront or from the customer's Company tab in the administration. - How employees inherit permissions through their assigned role. - Why roles should be designed around responsibilities instead of individual people. With this role model, employee access stays consistent and easier to maintain as the company account grows. Next, you will see how Organisation Units separate a larger company into independent parts.