A consumer who registers on a storefront portal is not a lead — they are a customer who has not ordered yet. Self-signup provisions them as one: a single registration creates the customer account, the contact and the portal login, already linked, so the person can order the moment they finish signing up and the order lands against a record finance can invoice.
The two switches
Self-signup is configured per portal site, under Setup → Portals, with two settings:
| Setting | What it does |
|---|---|
| Self-signup enabled | Whether the portal offers registration at all. Off means sign-in is by invitation only. |
| Self-signup creates customer | Whether a signup provisions a customer account and contact, or only creates a login. On by default. |
With creates customer off, a signup produces an unlinked login: the person can sign in, but commerce reads answer that no customer account exists until an administrator links one. That mode exists for portals whose members are onboarded by a back-office process; storefronts should leave provisioning on.
What a signup creates
With provisioning on, one registration writes three linked records:
- A customer account typed as a consumer.
- A contact under it, carrying the person's name and email.
- An external portal login linked to that contact from creation, and recorded as a member of the portal it signed up on.
The login then enters the standard invitation pipeline — the person verifies their email and sets a password before the login is usable, exactly as an invited user would. The customer half is written first: if it fails, the signup fails whole, so a login is never created without the account it needs.
Signup never adopts an existing account
Self-signup always creates a fresh account and contact. It deliberately does not match the signup email against existing customers and attach the login to a match — a signup form is an anonymous surface, and linking a self-declared email to an existing account would let anyone claim that customer's history and terms by typing the right address.
Two consequences to plan for:
- A person who already exists as a customer and then self-registers exists twice. Merging is an administrator's decision, made from inside the tenant.
- To connect a known customer to the portal, use the invitation flow instead — an invited contact links safely because the tenant chose the linkage.
An email that belongs to an internal (staff) user is refused at signup.
The consumer experience
The account's type drives the portal the person gets. A consumer sees consumer banners, unit-first ordering and an account area of orders and addresses — none of the credit, outstanding, target and scheme-performance apparatus a trade partner sees. An account whose type the system cannot classify is treated as trade, not consumer: hiding a partner's credit position would be a worse failure than showing a consumer an empty statement card.
A consumer order is an ordinary order. It goes through the same cart, the same checkout and the same pipeline as everything else — see Direct-to-consumer selling.
Before signup: the landing page
Anonymous visitors get a public landing page: real product families at list prices, the portal's offer carousel, and a coverage check that answers whether the storefront delivers to a pincode — read from the same service-area data that order routing uses. Scheme eligibility is account-scoped, so no personalised offers are shown until someone signs in.
Common questions
What happens if the same person signs up twice?
They get two accounts. Signup never merges or adopts, by design — deduplication is an administrative action with evidence, not something an anonymous form is allowed to trigger. Support processes should search before creating, and merge deliberately when a duplicate is confirmed.
Can we run signup without creating customers?
Yes — turn self-signup creates customer off. Signups then create only a login, and an administrator links each one to a customer account before the person can transact. Most storefronts should keep provisioning on; a login that cannot order is a support ticket waiting to happen.
Do consumers see trade pricing or schemes?
No. A consumer account gets consumer pricing from the published catalogue and none of the trade apparatus. Trade schemes, credit and targets render only for trade accounts, and the portal decides which experience to show from the account's own type.