Manage customer join and shop sharing

Customer join lets signed-in users use the same account in multiple shops. Their identity and credentials remain global, while every shop keeps its own membership, profile, customer data, and consent records.

Neither customers nor tenant administrators need System Tenant membership for this workflow. System permissions remain reserved for system-wide administration.

Configure a join offer

Open CRM > Settings > Customer join. Reading the page requires tenant_join_offers:read; separate permissions protect offer updates, sharing grants, and selections.

Enter a public name and a short description, then enable self-service joins. The existing registration switch and configured default customer segment remain authoritative. Workspace does not admit new members if either prerequisite is missing.

Enable Show in the central shop directory only when the shop should appear on the central platform page. Allowing self-service join does not publish the shop automatically.

Present other shops on your shop surface

Sharing deliberately requires two independent decisions:

  1. The target shop grants one source tenant permission to present its offer.
  2. The source tenant selects that approved offer for its own surface.

The target shop appears only while both decisions are active. A shared owner or administrator does not imply approval. Revoking either side hides the offer but does not remove memberships that already exist.

Administrators who manage several tenants select the source tenant by name; they do not need to enter technical tenant IDs.

Customer join flow

The central public/shops page lists only offers explicitly published to the central directory. On a shop domain, the same component lists that shop's own offer and mutually approved partner offers.

The user signs in with their global identity, accepts every required consent item for the target shop, and starts the join. Workspace creates only a local membership, active profile, and new external person in the target tenant. It does not copy or link customer data from another shop.

If the target shop requires two-factor authentication, the user must confirm the join with the code sent by email. Workspace creates no target membership, customer record, consent entry, application entitlement, or target session before that confirmation. A second factor already proven by the current login is retained only for its remaining lifetime and is never extended.

On the central platform or the target shop's own domain, a successful join can continue with a target session. When the join starts on another shop's domain, the source session remains active and the user signs in to the target shop or uses the explicit tenant handoff.

Joining is a personal browser action. API keys and impersonation cannot replace that sign-in.

Repeating the action for an active membership is safe. A later join is allowed after a voluntary leave completed in Workspace. A suspended, revoked, or ambiguous binding is never reactivated automatically. This includes old inactive profiles without explicit leave evidence. A tenant administrator must explicitly lift the block; doing so restores no previous role, group, or permission.

Invite a specific user

An authorized tenant administrator can invite a user into the currently selected tenant. The target tenant comes from the server-side session context and cannot be replaced in the request. Workspace checks the inviter's current authority and the intended roles, groups, and segments both when issuing and when redeeming the invitation.

An impersonation session cannot issue invitations. End the support session before creating one. For a federated sign-in, the current upstream authority must also remain valid when the invitation is issued.

If the inviter loses the required membership, API key, or assignment right before redemption, the invitation fails safely. Issue a new invitation with the current authority when appropriate.

Redemption attempts are limited persistently per browser, invite token, and shop host. Email addresses, tokens, and passwords are not included in audit metadata or public error messages.

If the target shop requires two-factor authentication, Workspace sends a six-digit code after the initial check. It creates the tenant membership and related shop data only after that code has been confirmed. For a previously unknown email address, the global account is also deferred, so a stolen invitation token cannot reserve the address. Workspace rechecks the password, invitation, and inviter authority during completion. For an invitation through a configured upstream OIDC connection, Workspace may resolve the global provider binding earlier, but membership, shop data, and the session remain deferred until the code has been confirmed.

If the target identity is already an active member with the same role, Workspace adds only missing groups, segments, and application entitlements that remain authorized. A different existing role causes a conflict and is never overwritten silently. The same rule applies to invitations redeemed through a configured upstream OIDC connection.

Customer join does not create a newsletter subscription. Likewise, newsletter consent does not create an identity or tenant membership. Continue to manage newsletter lists and double opt-in in the Newsletter area.