Two different apps share the word “dashboard”
An internal dashboard shows your team metrics about the whole business — revenue, orders, churn. A customer dashboard is a self-service portal: each of your customers signs in and sees only their own orders, invoices, downloads or requests. They look similar but are built around opposite rules — aggregation for the team, isolation for the customer.
This page covers the customer-facing portal. If you want the internal metrics view, the dashboard builder guide covers metric definitions, charts and filters.
Reference documentation
Every record belongs to exactly one customer
Design the data so each order, invoice, file or request carries the owning customer’s account id, and every query filters by the signed-in account. There is no “all records” view in a customer portal — even the list behind a search box must be scoped to the caller.
Decide what the customer can change. Most portals are read-only for orders and invoices, with a small set of allowed actions: updating contact details, downloading a file, or submitting a request. Each allowed action needs validation and a clear confirmation, because the person using it is not your staff.
Start with a specific customer-dashboard prompt
Replace the business and record types with your own. Ask for a managed database and sign-in explicitly, and use two fictional customers until isolation has been checked.
Build a customer dashboard for a small printing service. Each customer signs in and sees only their own records: orders with a status (received, in production, shipped), invoices with an amount and paid or unpaid state, and downloadable proof files. Add a support request form whose submissions appear in that customer’s own list with a status. Every query must filter by the signed-in customer’s account; there is no view of other customers’ data. Require sign-in, keep accounts isolated, and save everything in a managed database so records survive reloads. Include clear loading, empty and error states, and a helpful empty state for a brand-new customer with no orders yet. Include mobile layouts. Keep sample customers and orders clearly labeled.Open the app builder
Test isolation before anything else
Create two test customers with different orders. Sign in as the first and note the order references, then sign in as the second and confirm none of the first customer’s orders, invoices or files appear — including through search and direct links. This single check matters more than any visual polish.
Then check the lifecycle: a brand-new customer sees helpful empty states, a submitted support request appears in their list with its status, and a failed request preserves the form without a false success message.
- Sign in as two test customers and verify neither can see the other’s records.
- Reload and confirm orders, invoices and requests persist per customer.
- Try a signed-out visit: it must redirect to sign-in, never show data.
- Test the support form with a failed network request and a duplicate submission.
- Use a phone to sign in, open an invoice and submit a request.
Publish after isolation is proven on the public URL
For supported managed apps, BrainHalf builds and verifies a saved version before activating the public release. Production has its own database and sign-in; development test customers are not copied. Repeat the two-customer isolation check on the public URL before inviting a real customer.
Real customer data raises the stakes for account recovery and privacy: decide how a customer resets access and how records are deleted before launch. The privacy overview describes what the platform itself stores.