Login Context and Impersonation
A sublogin signs in through Magento's normal customer login page. The session keeps the parent customer identity and the current sublogin identity together so checkout, orders and add-ons can apply the correct restrictions.
Direct sublogin sign-in
The email must be unique within Magento's customer account-sharing scope. The account must also be active, unexpired and, when enabled, confirmed by email.
When a sublogin is active, the session can affect:
- address availability;
- payment and shipping methods;
- cart and wishlist ownership;
- order ownership and history;
- permissions contributed by Role and other add-ons;
- budgets, catalogs and approval state.
Stale or invalid sublogin context is cleared rather than carried into an unrelated customer session.
Main-account impersonation
With Allow impersonate sublogin account enabled, the main customer can select Login beside a sublogin. The storefront displays the active sublogin context and a link back to the main account.
Use impersonation to reproduce a buyer's storefront view or help build a cart. It does not reveal or replace the buyer's password.
Before leaving the session, return through the context banner and confirm the main account identity is restored. Shared cart or wishlist changes made during impersonation remain shared when those features are enabled.
Admin impersonation
Magento administrator permissions are controlled by Admin ACL, and managing a Sublogin record is not the same as acting as that buyer in the storefront. Administrators can, however, start an impersonation session from Admin: the Login as Sublogin button on the Admin sublogin edit page opens the storefront logged in as that sublogin.
The button is available only on an existing record and requires the MageB2B_Sublogin::save ACL resource. It uses Magento's Login as Customer infrastructure (Magento_LoginAsCustomer*): the admin request generates a one-time secret and redirects to the storefront loginascustomer/login/index route with the sublogin ID attached, on the store view that matches the sublogin's scope and Magento's account-sharing configuration. The resulting session carries the sublogin context, so role, catalog, budget and address restrictions apply exactly as they do for the buyer.
The optional Sublogin API manages records under its own Web API ACL resources. It does not turn a customer storefront session into a general integration credential.
Diagnose the wrong context
- Sign out completely and start a fresh browser session.
- Confirm the email belongs to the intended customer website scope.
- Check active, expiry and confirmation state.
- Inspect the visible impersonation banner.
- Confirm the order or quote carries the expected sublogin ID.
Related: Multi-Account Management and Permission Problems.