In short and in plain language
This text is about orders by phone, fax and email. Staff often type them straight into the ERP. The ERP is the program for stock, orders and invoices. The shop then knows nothing about the order.
Shopware has a feature for this. A staff member logs in to the shop as the customer. Then they order for the customer. The order then shows up in the customer's account.
Not every staff member should be allowed to do this. Decide who may. Shopware does not write down who logged in as a customer. An add-on has to do that.
Such a list stores data about staff. Talk to the works council and the data protection officer first. Decide when the data will be deleted.
We set up the feature with roles, a list and a flag on each order.
One buyer calls, another sends an order by fax, a third types twelve line items into an email. In B2B trade, orders like these often go straight into the ERP, and the shop does not learn about them: customer prices, approvals and order history are maintained in two places, and the customer account shows the customer only part of their orders. Since version 6.6.5.0, Shopware ships a built-in feature that can close this gap: an admin user with the api_proxy_imitate-customer permission logs in to the storefront as the customer and orders there on their behalf (Shopware Release Notes). This article shows how to assign the permissions, what Shopware records and what it does not, which questions data protection and the works council will raise, how the inside sales channel becomes visible on the order and which metric tells you whether it works.
Key takeaways
- Since Shopware 6.6.5.0, admin users with the api_proxy_imitate-customer permission can log in to the storefront as a customer from the customer detail page and place orders on the customer's behalf (Shopware Release Notes).
- In Shopware's role management, the permission is part of the customer module's editor level (Shopware source code): anyone who may edit customers may also log in as a customer. Set up separate roles for inside sales, marketing and support.
- The Community Edition does not record which admin user logged in as which customer, and it does not flag orders placed in a taken-over session (Shopware source code). The log and the order channel are a custom extension.
- A log of taken-over sessions stores data about your own employees: it needs a deletion period (Art. 5(1)(e) GDPR) and belongs on the agenda with the works council before launch (Section 87(1) no. 6 BetrVG).
- Orders received by fax or email are usually commercial letters received and must be kept for six years (Section 257 HGB), even after inside sales has re-entered them in the shop.
- The shop share measures which part of all orders is created in the shop, whether customers order themselves or inside sales enters the order in their account. Tracked monthly, it shows whether phone and fax orders really reach the customer account.
Why phone and fax orders bypass the shop
Measured by turnover, the online shop is still a small order channel in many companies. In 2024, EU enterprises with at least 10 employees generated 19.49 percent of their total turnover from electronic orders; 8.39 percent came via websites and apps and 11.07 percent via EDI (Eurostat). Only 23.59 percent of these enterprises made any electronic sales at all (Eurostat). The count only includes orders placed through channels built specifically for ordering. Everything else, meaning phone, fax, free-form email, field sales or the sales counter, falls outside this figure.
A look at how companies communicate fits this picture. In a survey of 602 companies in Germany with 20 or more employees, conducted in spring 2025, 100 percent said they use email very often or often, 93 percent the landline phone and 18 percent still the fax (Bitkom). Customer or employee portals stood at 53 percent, up from 47 percent in 2024 (Bitkom). The survey covers communication in general, not just orders, but it shows which channels are firmly established in day-to-day business. Portals are growing, phone and email remain. For a supplier, this means that even a well-used customer portal will not fully replace phone and email orders any time soon.
Whatever reaches inside sales is often entered directly in the ERP today. That is quick, but it has consequences: the shop does not know the order, the order history in the customer account has gaps, and pricing logic, minimum quantities or approvals maintained in the shop do not apply when the order is entered in the ERP, or they have to be maintained there a second time. If you already pass customer-specific prices from the ERP to the shop, as described in the article on ERP integration in B2B e-commerce, you have a shared data basis but still two entry screens with two sets of rules.
Another approach is to read incoming email and PDF orders automatically and write them straight into the ERP as orders. That helps with large numbers of uniform documents. This article covers the case next to it: inside sales enters the order themselves, but in the shop rather than the ERP, with the prices, rules and history the customer sees too. The order then takes the same route into the ERP as any other shop order.
What Shopware has built in since 6.6.5.0
With version 6.6.5.0, released on August 6, 2024, Shopware added logging in as a customer to the administration (Shopware Release Notes). The feature came in as a community contribution and is part of the core, meaning the Community Edition; no paid extension is required. It already existed in Shopware 5 and had been missing in Shopware 6 until then (Shopware Release Notes). An admin user selects a sales channel and a domain and logs in there as the customer. The prerequisite is the api_proxy_imitate-customer permission. The release notes describe the feature as compatible with headless sales channels as well (Shopware Release Notes). In version 6.7.15.1, however, the administration only offers active sales channels of the Storefront type with a domain (Shopware source code). For a headless frontend, the Store API provides its own route for logging in as a customer; the project then has to wire up the call from the administration itself (Shopware source code).
In the administration, the feature sits on the customer detail page: on the General tab, the Log in as customer button opens a window for choosing the sales channel, after which the admin user is logged in to the storefront on the customer's behalf. The documentation explicitly names both purposes: placing orders for customers and viewing data in the customer account (Shopware documentation). Guest customers and inactive customers cannot be taken over, and the button stays disabled for them (Shopware source code). If you have so far created phone customers as guests in the shop, convert them into registered customers first.
There is also a second, older route: via Add order in the order overview, inside sales enters an order directly in the administration, selects the customer and saves. The order confirmation is then sent to the email address stored in the customer account (Shopware documentation). Both routes have their place. The difference lies in what inside sales sees while entering the order and what stays attached to it afterwards.
| Feature | Create order in admin | Log in as customer |
|---|---|---|
| Where the order is entered | Order module in the administration | Storefront, seen from the customer's side |
| What inside sales sees | Customer list, products, options of the admin screen | Customer account, order history, customer prices and all storefront features |
| Storefront extensions | only if they also support the admin screen | available as for the customer, such as quick order or order lists |
| Order confirmation | to the address in the customer account | via the storefront checkout, in the default configuration also to the customer |
| Editor recorded on the order | yes, in the createdById field | no, not without an extension |
| Prerequisite | Permissions to create orders | api_proxy_imitate-customer permission, registered and active customer, active storefront sales channel with a domain |
For customers with their own price lists, order lists or quick order by item number, logging in as the customer is usually the better fit: inside sales works with exactly the features the customer uses and can explain on the phone where to find them next time. Creating the order in the administration remains useful for special cases it has dedicated tools for, such as a free-text line item, a manual credit or deviating shipping costs.
Assigning permissions: who may enter which customer account?
Logging in as a customer is a far-reaching permission. Whoever uses it sees the customer's addresses, orders and documents and can place binding orders in the customer's name. That makes it all the more important who gets it. In Shopware's role management, api_proxy_imitate-customer is part of the editor level of the customer module; on the Detailed privileges tab, it also appears as a separate entry, Imitate a customer login (Shopware source code). In the default setup, this means anyone who may edit customers may also log in as a customer. Before launch, check which roles carry the editor level in the customer module and which users have full administrator rights, since those may do everything anyway.
- Inside sales: view and edit customers, view orders, which includes logging in as a customer. Personal admin accounts instead of a shared login, so every session stays assigned to one person.
- Sales management and accounting: view customers and orders only. Anyone who does not enter orders does not need the editor level in the customer module.
- Marketing and content: no access to customer detail pages, as far as the task allows.
- External service providers: separate, time-limited accounts that are deleted when the project ends. Logging in as a customer only after explicit agreement.
- Departures: lock admin accounts on the last working day. An active account of a former employee is also access to every customer account that person was allowed to take over.
Administration roles are not the same as roles within the customer account, meaning buyer, approver and administrator on the customer side. How such structures are built in Shopware CE is described in the article on customer groups, roles and permissions. When inside sales logs in as a customer, they work with that customer account and its settings. If your portal has its own approval workflows with budgets, decide beforehand whether an inside sales order goes through approval or whether the customer's call already counts as approval.
Logging: what Shopware records and what it does not
For this article, we reviewed the source code of Shopware 6.7.15.1, released on October 7, 2026 (Shopware Release Notes). The result is clear: the Community Edition does not record which admin user logged in as which customer and when. The login triggers the same login event as a regular customer login, and its log data contains the customer ID and customer number but no reference to the admin user (Shopware source code). Only the running session knows the admin user.
Orders behave similarly. If inside sales creates an order in the administration, Shopware writes the admin user into the order's createdById field (Shopware source code). If they order in the taken-over storefront session instead, the result is an ordinary shop order without this reference. Afterwards, it cannot be told apart from an order the customer placed themselves.
A third side effect concerns reporting: logging in as a customer resets the last login time in the customer account (Shopware source code). If you measure portal usage by last login, you count inside sales sessions as customer activity.
Logging is therefore not a setting but a measure of its own. Technically, it is manageable: a small extension reacts to the login and to order completion, reads the admin user from the session and writes an entry into a separate table. The overview below shows which details such an entry should carry.
Admin user
The employee's personal account, not a role or department. A shared account for the entire inside sales team makes any log worthless.
Start and end
Time of logging in as the customer and of logging out or session end. This shows what happened in which session.
Customer and sales channel
Customer number and the sales channel the session ran in. If you operate several shops, include the domain.
Order number
Every order created in the session. Sessions without an order, for example to answer a question, remain visible as well.
Reason
Phone call, fax, email or customer inquiry, ideally as a picklist with the case number from the ticket system.
Deletion period
A defined retention period for the entries and automatic deletion afterwards. The order itself is not affected.
Logging out is part of the process
Data protection and co-determination
Even in a B2B shop, every customer account holds personal data: names, phone numbers and email addresses of contact persons, delivery addresses, orders. Anyone logging in as the customer sees all of it. The GDPR requires controllers to take steps to ensure that persons acting under their authority who have access to personal data process it only on instructions (Art. 32(4) GDPR). In practice, this means a written rule on when inside sales may take over a customer account, for example only to enter an order that has come in or at the customer's explicit request.
Then there is the principle of data protection by default: the accessibility of personal data, too, should be limited to what the specific purpose requires (Art. 25(2) GDPR). Separating roles as described in the section on permissions is the technical side of this principle. And because the controller must be able to demonstrate compliance with the principles (Art. 5(2) GDPR), a log of taken-over sessions is more than a convenience: it shows that access followed an instruction.
The log itself, however, processes data about your own employees. It needs a defined retention period, because personal data may only be kept in identifiable form for as long as the purpose requires (Art. 5(1)(e) GDPR). And it may touch on co-determination: the works council has a say in the introduction and use of technical devices designed to monitor employee behavior or performance (Section 87(1) no. 6 BetrVG). A log that records, for each employee, when they were in which customer account belongs in that review. Involve the works council and your data protection officer before the extension goes live, and define what the log will and will not be evaluated for.
That leaves informing customers. For business customers, there is an upside when inside sales enters a fax order directly in their account: the order then shows up in their history. A sentence in the portal's terms of use and a visible flag on every order entered by inside sales provide clarity.
Not legal advice
Flagging the inside sales channel on the order
An order that inside sales entered in the customer account looks like a self-service order in the ERP. That is not enough for commission accounting, for analyzing order channels or for handling queries. The solution is a flag on the order that is set automatically and travels with the order into the ERP. This is how to build it:
- Create a custom field Order channel on the order, with fixed values: self-service, inside sales in customer account, inside sales in administration, field sales, EDI.
- The extension sets the value at order completion: if the session holds an admin user, it enters inside sales in customer account plus the account. For orders from the administration, the existing
createdByIdfield provides the information. - The interface passes channel and editor to the ERP, so order entry, commission and statistics all use the same value.
- In the customer account, the order shows a short note saying it was entered by inside sales. This lets the customer see which orders they did not place themselves.
- The order confirmation gets a sentence about the order channel, such as your phone order, so the customer can match it to their call.
Passing it to the ERP works like any other custom field: it has to be part of the mapping in the interface between shop and ERP, otherwise it stays in the shop. Where the ERP has no suitable field, a flag or free-text field in the order header is often enough.
The original order does not disappear once it has been entered in the shop. An order by fax or email is usually a commercial letter received, because commercial letters are documents relating to a commercial transaction, and merchants must keep commercial letters received for six years (Section 257 HGB). The shop order therefore does not replace the original, it refers to it. A field on the order for the original's document number and an archive in which fax and email can be found under that number are practical. How documents are made available in the customer account and for how long is covered in the article on where order documents live and how long they stay.
The shop share metric: measuring what runs through the shop
Whether logging in as a customer is working shows in a dedicated metric: the shop share. It measures which part of orders or turnover was created in the shop, regardless of whether the customer ordered themselves or inside sales did so in their account. Next to it is the self-service share, meaning the part customers placed without help. Together, they answer two different questions: do all orders end up in the customer account? And are customers increasingly ordering on their own?
- A wholesaler receives 1,000 orders a month. Customers place 380 of them in the shop themselves, inside sales enters 270 in the customer account, and 350 still go directly into the ERP (worked example).
- The shop share is therefore 65 percent (650 of 1,000 orders), the self-service share 38 percent (worked example).
- Before the rollout, only self-service orders ran through the shop: at the same volumes the shop share was 38 percent, and 62 percent of orders were missing from the order history in the customer accounts (worked example).
Measure by the order channel from the previous section, not by last login, because last login also counts inside sales sessions. A monthly analysis per customer group makes sense. Customers whose orders are mostly entered by inside sales are candidates for a short introduction to the portal. Customers whose orders still go straight into the ERP show where inside sales is still working around the shop. Which other metrics matter in a B2B shop is described in the article on B2B shop analytics and KPIs.
Inside sales, field sales and self-service: drawing the lines
Logging in as a customer is a tool for inside sales at the desk. It replaces neither the field sales app nor the self-service portal; it closes the gap between them.
- Field sales: the rep sits with the customer, often without a stable connection, and needs an app with customer prices and stock levels that captures orders offline and syncs later. That is a project of its own, described in the article on the field sales app for mobile orders.
- Inside sales: the order comes in by phone, fax or email and is entered at the desk. This is where logging in as a customer fits, because the order appears in the customer account right away and goes through the same rules as a self-service order.
- Self-service: the customer orders alone. That is the goal for recurring orders. How sales works without a dedicated contact person is shown in the article on rep-free B2B and self-service.
Inside sales can be the bridge to self-service: whoever enters a fax order in the customer account can show the customer on the phone that the order is there and how to place the next one themselves. That is a step toward self-service without pushing the customer to switch. How sales processes can be digitized as a whole, from inquiry to delivery, is described in the article from fax to automated B2B ordering.
Rollout in five steps
- Survey order channels: for one month, count how many orders arrive by phone, fax, email, shop and EDI and where they are entered. That is the baseline for the shop share.
- Separate roles: personal admin accounts for inside sales, and the editor level in the customer module only where customer accounts are meant to be taken over. Convert guest customers with regular orders into registered customers.
- Put rules in writing: when a customer account may be taken over, how long logs are kept and what they are evaluated for, agreed with the data protection officer and the works council.
- Build the extension: log, notice band in the storefront, custom field Order channel and its transfer to the ERP.
- Measure and adjust: analyze shop share and self-service share monthly per customer group, and introduce customers with a high inside sales share to the portal in a targeted way.
We implement this kind of inside sales access in Shopware CE: role concept, log as a lean extension, notice band and order channel all the way into the ERP. If your customer portal is still being built, we plan the inside sales view from the start; for larger B2B portals, it belongs in the role concept. Which order channels bypass your shop today and where it pays to start is something we clarify in an e-commerce consultation or via the contact form.
api_proxy_imitate-customer permission. The customer must be registered and active; guest customers cannot be taken over (Shopware source code).Related Articles
XRechnung 4.0: Collective Invoices and Cash Discounts in B2B
XRechnung 4.0 adds several orders per invoice and early payment discounts as data fields. What shop and ERP data you need first, with timeline and tests.
B2B Shop for Businesses Only: Excluding Consumers Properly
How a B2B shop excludes consumers effectively: a notice on every page, a mandatory company field and a separate confirmation. What German courts have decided.
Annual Rebates in the B2B Shop: Show Tiers and Rebate Status
Annual rebates change VAT after the fact. How B2B shop and ERP handle rebate status, invoice reference and rebate document under Section 17 UStG in the account.