Customer accounts

Your storefront has its own customer accounts, entirely separate from staff logins. Shoppers register with an email and password, and the account binds to the record in Manage → Customers — a shopper who once ordered as a guest and registers with the same email brings their history with them.

The five account forms

The Form element's Ready-made panel carries them all: Login, Register, Password reset request, Reset password, Verify email. Drag one out and it works — they post straight to the account system and never pass through the submissions store, so a password is never anywhere you (or anyone else) could read it.

Two things worth knowing early:

• An account form's type is locked at creation. You cannot turn a Login form into a Contact form or back — because if you could, one click would turn it into a password collector feeding the submissions list. Want a different kind? Create a new form.
• The Log out button is not a form: attach the Log out customer action to any button.

A signed-in shopper also gets Contact-group fields prefilled on every other form, and orders they place (the whole-cart kind included) attach to their account automatically.

Email verification — optional, with one exception

In Manage → Settings, switch on Require customer email verification and registration only completes after entering a code sent by email. It ships off — the least friction for shoppers.

One deliberate exception: registering with an email that already has a customer record (say, from a past guest order) always requires verification, whatever the switch says — that account is about to see the old record's name, phone and order history, so it has to prove the email is really theirs first.

Codes go out through the platform's mail server, or through your site's own SMTP if you configure the Mail app.

The /account page

The create-page dialog offers an Account page type — it serves at the fixed path /account, and it is a real page: decorate it like any other. It is created with three elements already in place:

Account info — the signed-in shopper's name, email and phone, with three self-service buttons. Edit changes their own name and phone. Change password requires the current password, and a successful change signs every other device out of that account, keeping only the browser that made it. Change email also requires the current password, then mails a confirmation code to the new mailbox — the login email only moves once that code comes back, so nobody can move an account onto a mailbox they do not own. A signed-out visitor sees a sign-in prompt (the wording is yours to edit). Order history — that shopper's own orders, newest first, with order status, payment state and totals in the site's language. Both states are shown because they are independent, and somebody who paid online yesterday is asking about the second one. An order with products opens on click into its detail: each item with its options (colour, size…), quantity and line total — click again to close. Address book — the shopper's saved addresses: add, edit, delete, and mark one as the default. Deleting takes two clicks on the same button, so a stray tap cannot erase an address. Ten addresses at most.

A shopper with no account can still look their order up

Most of a Vietnamese store's buyers never sign up: a cash-on-delivery order asks for a phone and nothing more. For them "sign in to see your orders" is advice they cannot follow — so that spot no longer offers only advice.

When the viewer is signed out, Order history shows two boxes and a button: the order number and the phone or email used to place it. Get both right and the order appears — drawn with the same row the signed-in list uses, so it wears the design you built.

Where the shopper gets the number: the thank-you after checkout prints it, alongside what is left to pay.

Four rows in the inspector control it: Order lookup turns it on or off, and three text rows word the two boxes and the button. A members-only shop switches the first off and the other three go with it.

The answer deliberately withholds the address and the email. Neither credential is strong — order numbers run in sequence and a phone can be guessed — so what comes back is the status, the money, the items and a tracking number if there is one. Somebody who guesses a pair gets nobody's home address. The number must also match exactly: "#100" does not find "#1001".

Turn returns on and Order history grows one more door: the shopper picks items and quantities to send back, right on the order row — see Returns. To let them revisit what they hearted, add the Saved items element (also in the Account group): Save for later.

With the Loyalty Points app installed, the element panel gains a Points card (under the Apps tab) to place on this page — shoppers see their balance, redeem points for discount codes and read their points history right there.

The default address is also what forms prefill for a signed-in shopper: street and postal code are written straight into their boxes, and the province and ward are picked in their lists — confirming instead of retyping.

You can create several account pages; the ★ in page settings decides which one serves at /account — exactly how the checkout page picks the page for /checkout.

Two blocks that follow the viewer

The other two elements in the Account group build nothing on their own. Their job is to let the rest of the page know who is looking.

Show by sign-in (vi: Ẩn/hiện theo đăng nhập) is a container with exactly one choice: Show to → Members or Guests. Put anything you like inside it, and only the audience you picked sees it. The common shape is a pair at the top of the page: a Guests block holding Sign in / Register, a Members block holding a greeting and a Log out button.

Member name / email (vi: Tên/email thành viên) is a piece of text that sits inside a line: the signed-in shopper's name, email or phone. Text before and text after are typed right in the panel, so "Hi, Nam!" is one element rather than three pieces stuck together — and it wraps like an ordinary sentence on a narrow screen. Signed-out text is what replaces the whole thing for a visitor who is not signed in; leave it empty and nothing shows.

Both ask who is looking after the page has appeared, so a signed-in shopper may see a Guests block flash for a beat and vanish. In exchange the page waits for nobody before it draws, and with JavaScript switched off everything settles on exactly what a signed-out visitor should see.

Put a block inside a block for the opposite audience and nobody can see it — the outer one has already hidden it from one audience and the inner one hides it from the other. The builder marks that block in red rather than leaving you to find it on the live page.

Hidden is not private

A show-by-sign-in block hides content, it does not withhold it: what is inside still sits in the page source for anyone who opens it. That is right for changing the face of a page — a greeting, a different button, an extra note. It is wrong for a private discount code, a download link, or anything that loses its value once seen. Those belong to Members only just below, which stops the visit at the server before a single word is sent.

Members-only pages

In any page's settings, switch on Members only. A signed-out visitor opening it is sent to /account to sign in (or to the homepage if no account page exists yet). The pages list marks these pages with a lock icon.

The gate runs on the server, per visit — this is not CSS hiding that anyone curious can step around. The builder's Preview button is the one thing it never blocks: you own the site, you can always see your own pages.