Customers

A customer is a site member seen from the admin: a record of a model that has accounts enabled, identified by its identity (usually an email). There is no separate customer table. If your workspace has two account models - say members and wholesale - the Customers area lists both, with a tab per model.

The area lives next to Commerce and Team in the admin navigation. It shows up once at least one model has accounts enabled; before that it points you to Models.

The list

Search by identity, filter by status, and by company when the model declares one. Each row shows the display field of the record (or the identity when it is blank), the model, the status, the last sign-in, the join date and - with orders:view - the number of live orders and what the customer has spent, per currency. Spend is never summed across currencies.

• active - can sign in.
• pending - registered, email not verified yet. Only exists when the model requires verification.
• suspended - sign-in refused, every live session ended.

A lockout after too many failed attempts is not a status: the row shows locked until and it expires on its own.

Click a column header to sort: identity, status, last sign-in, joined, orders. The sort is in the address bar, so a sorted view can be bookmarked or shared. Sorting by orders needs orders:view.

Add customer creates an account record from the admin, on the model of the current tab or one you pick, so you can set someone up before they ever visit the site. Export CSV writes every customer matching the current search, filters and sort - not just the page - with the order columns included when you may see orders. Cells that start with a formula character are escaped so the file opens safely in a spreadsheet.

Tick rows to suspend or reinstate in bulk, up to 100 at a time. Customers that cannot make the change - not verified yet, already in the target state - are skipped and counted, the rest go through.

The detail page

The account card, an Order history card (live orders, spend per currency, last order; needs orders:view), then three tabs: Profile (the record's fields, read-only, with relations shown as the related record's label; Edit opens the same record dialog as Models), Orders and Carts of this customer. The profile is the record, so editing it needs the models:edit permission; the two tabs need orders:view and carts:view.

Suspend and reinstate

Suspend blocks sign-in and invalidates every access and refresh token the customer holds - the next request with an old token is refused. Orders, carts and the record itself stay. A pending account cannot be suspended: verifying it would otherwise turn into a way of activating it.

Reinstate lets the customer sign in again and clears any lockout. Both actions refuse when the account is already in the target state, so an agent retrying a call cannot flip it twice.

Password reset, verification and unlock

The account card offers the action that fits the status. Send password reset emails an active customer a link to set a new password; it works for one hour. Resend verification sends a pending customer a fresh link and retires the previous one. Unlock appears only while a lockout is running: it clears the failed-attempt counter and the sign-in throttle, so the customer can try again right away. A suspended customer gets none of these; reinstate first.

The two emails go out through the workspace mail settings and need the public site URL, because the link points at your site. When the link was issued but the mailer refused the message, the admin says so instead of pretending. Each customer can receive at most five of these emails an hour, so a stuck form cannot flood an inbox. A password reset is refused on a model that has no password sign-in.

Orders and guests

An order placed by a signed-in member is attached to that member. A guest order is attached later, when the guest registers and verifies the same email - so "my orders" fills in retroactively. From the order detail you can also attach or detach a customer by hand. The Orders list searches by the customer's identity and by the company name frozen on the order, and it can be narrowed to one company.

Companies (B2B)

On the account model's Capabilities tab you can name a company field (a relation to your company model) and a company role field (a select such as buyer / approver). The Customers list then shows a Company column and filter, orders and carts can be listed by company, and an order freezes the company name at checkout so a later rename does not rewrite history. Nothing about the company is exposed on the public API. A visitor cannot pick a company at sign-up either: register refuses a payload that sets the company or company role field, so only the admin (or an agent through update_record) places a customer in a company.

Permissions

• customers:view - see the area, the list and the detail, export the CSV. Seeded on the Viewer role.
• customers:manage - suspend and reinstate (one or in bulk), add a customer, send a password reset, resend verification, unlock. Seeded on the Editor role.
• orders:view - the order columns, the order sort and the order history card.

Attaching a customer to an order is an order change, so it needs orders:manage.

From MCP and Spotlight

The same surface is available to agents: list_customers (model, status, search, company, paging), get_customer (summary plus the record's data), suspend_customer and unsuspend_customer, send_customer_password_reset, resend_customer_verification and unlock_customer. Every customer an agent reads carries orderStats - live orders, spend per currency, last order - or null when the token may not see orders. There is no bulk tool on purpose: an agent confirms one customer at a time. get_model returns the model's auth config, and update_model sets the company fields. list_orders and get_order return customerId, companyId and companyName (null on guest orders), and list_orders takes a companyId filter and a search that matches the frozen company name, so a company's orders reach an agent the same way. See the tool catalogue.

Next steps

• Member authentication - the sign-up and sign-in flow your site implements.
• Commerce - orders, carts and checkout.
• Members and roles - who on your team gets which permission.