Allow a customer type's post-login redirect to resolve to a page within that customer type's associated microstore, without requiring a separate hard-coded menu link per customer type.
B
Benjamin Long
Current behavior
The Login Redirect Link setting on a customer type works correctly for customer types not associated with a microstore. When the customer type is associated with a microstore, the microstore redirect and the customer type redirect conflict, and the customer lands on the microstore homepage regardless of what is configured. Observed chain: login.aspx?...r=%2f → 301 → Micro.aspx?MicroStoreID=10&r=/ → 307 → Micro.aspx?MicroStoreID=10&r=%2f → 302 → homepage. Microstore merge codes such as ##MSCUSTOM1## do not resolve inside the menu link URL field, so they can't be used to express a per-microstore destination in a single shared link. The only supported alternative today is one menu link per customer type, hidden from every other type.
Why the menu link approach doesn't scale
We expect to onboard potentially several dozen new customers, each needing their own microstore / customer type. That means a growing set of near-duplicate menu links, and because visibility is expressed as "hide for..." rather than "show only for...", every new customer type requires revisiting every existing customer-type-specific menu item to exclude it. A missed exclusion silently exposes one customer's link to another customer.
Requested behavior (any one of these would solve it)
- Have the microstore redirect honor the customer type's configured Login Redirect Link rather than overriding it (preferred since no new configuration needed).
- Support microstore merge codes (##MSCUSTOM1##–##MSCUSTOM8##) in the menu link URL field, so one shared link can resolve per microstore.
- Invert menu link visibility to an opt-in "visible only to these customer types" option, which would at least make the current workaround maintainable.
Log In