What exists and what must not be inferred
The portal module requires customer_accounts. Current pages cover entry, login, signup, verification, password reset, dashboard, and profile. Modules can extend navigation and widgets.
Permission names for catalog, quotes, orders, and invoices, plus promotional landing cards, are not evidence of a complete process. Review the page, API, authorization, integration, and end to end journey before classifying it.
Customer access needs an explicit identity model
Staff and customer authentication are separate systems. Tenant, organization, CRM company, contact person, customer user, role, and feature are also distinct boundaries. Design the relationship and test denial for the wrong organization and another company.
A custom domain is a separate operating workstream
Current source covers domain registration, DNS and TLS checks, routing resolution, and retry jobs. A project still needs owners for the domain and DNS, certificate policy, environments, routing secrets, email links, monitoring, incident response, rollback, and decommissioning.
One journey is the unit of scope
For one persona and one outcome, record the system of record, identifiers, reads and writes, freshness, idempotency, retries, reconciliation, outages, retention, exceptions, evidence, and owners. Only then is the journey estimable and testable.
Supplier positioning is not deployment evidence
Public material uses terms such as self service, ordering, invoices, and fully branded portals. Here they provide search expectation context only. Capability state comes from current code, routes, APIs, tests, and evidence from the actual application.
Evidence boundary
Release, current source, and review date
- Latest verified public tag
- v0.6.5
- Current source revision
01911d00e28f44cf484d0b1d04860dcfef5370bf- Reviewed
Customer Accounts and Portal entered public release history in v0.4.8. Custom portal domains were announced in v0.6.1. The inventory below was checked against later current source at the exact revision shown, not inferred back into either release.
Portal foundation inventory
State describes the evidence boundary, not a promised outcome. Every row needs a fresh check for the actual application and enabled modules.
Open: Portal foundation inventory18 items
| Mechanism | State | Exact evidence | Release or current source | Safe inference | Boundary | Prerequisite | Accountable owner | Reviewed |
|---|---|---|---|---|---|---|---|---|
| Landing | available foundation | portal/frontend/[orgSlug]/portal/page.tsx | Current source at the reviewed revision; release history is stated separately | Public portal entry with sign in and signup links | Promotional cards do not prove an order or invoice journey | Enabled modules, configured application, and project acceptance | Portal product and delivery owner | 2026-07-14 |
| Customer login | available foundation | portal/login/page.tsx | Current source at the reviewed revision; release history is stated separately | Separate customer authentication entry | Production policy, email delivery, rate limits, and recovery still need deployment evidence | Enabled modules, configured application, and project acceptance | Identity and security owner | 2026-07-14 |
| Signup | configurable | portal/signup/page.tsx | Current source at the reviewed revision; release history is stated separately | A first party enrollment route exists | Invite only versus open signup is a project policy | Approved policy, configuration, server enforcement, and tests | Identity and security owner | 2026-07-14 |
| Email verification | available foundation | portal/verify/page.tsx | Current source at the reviewed revision; release history is stated separately | Verification route and token flow exist | Delivery, expiry, abuse handling, and support must be accepted locally | Enabled modules, configured application, and project acceptance | Identity and security owner | 2026-07-14 |
| Password reset | available foundation | portal/reset-password/page.tsx | Current source at the reviewed revision; release history is stated separately | Reset route exists in current source | The configured email and recovery journey still need an end to end test | Enabled modules, configured application, and project acceptance | Identity and security owner | 2026-07-14 |
| Dashboard | available foundation | portal/dashboard/page.tsx | Current source at the reviewed revision; release history is stated separately | Dashboard shell accepts injected widgets | It can be empty and does not prove any business widget | Enabled modules, configured application, and project acceptance | Portal product and delivery owner | 2026-07-14 |
| Profile | available foundation | portal/profile/page.tsx | Current source at the reviewed revision; release history is stated separately | Current profile, roles, and resolved features are visible | A profile is not complete company account administration | Enabled modules, configured application, and project acceptance | Portal product and delivery owner | 2026-07-14 |
| Navigation | configurable | customer_accounts/api/portal/nav.ts | Current source at the reviewed revision; release history is stated separately | Route manifests and feature grants shape navigation | A visible item is not server authorization or a completed journey | Approved policy, configuration, server enforcement, and tests | Portal product and delivery owner | 2026-07-14 |
| Notifications | available foundation | customer_accounts/api/portal/notifications.ts | Current source at the reviewed revision; release history is stated separately | Customer notification APIs exist | Business notification coverage and delivery reliability are project evidence | Enabled modules, configured application, and project acceptance | Portal product and delivery owner | 2026-07-14 |
| Invitations | available foundation | customer_accounts/api/post/invitations/accept.ts | Current source at the reviewed revision; release history is stated separately | Invitation and acceptance mechanisms exist | Who may invite, which role is assigned, and recovery remain policy decisions | Enabled modules, configured application, and project acceptance | Portal product and delivery owner | 2026-07-14 |
| Customer roles and features | configurable | customer_accounts/setup.ts | Current source at the reviewed revision; release history is stated separately | Seeded roles and wildcard aware feature checks exist | Feature names are access vocabulary, not page or workflow proof | Approved policy, configuration, server enforcement, and tests | Identity and security owner | 2026-07-14 |
| Session management | available foundation | customer_accounts/api/portal/sessions.ts | Current source at the reviewed revision; release history is stated separately | Users can inspect active sessions and current source supports revocation | Cookie policy, duration, support, and incident response remain deployment responsibilities | Enabled modules, configured application, and project acceptance | Identity and security owner | 2026-07-14 |
| Company user administration | configurable | customer_accounts/api/portal/users.ts | Current source at the reviewed revision; release history is stated separately | Same company user listing and role administration APIs exist | Company association must be correct and independently tested | Approved policy, configuration, server enforcement, and tests | Portal product and delivery owner | 2026-07-14 |
| Injection points | custom | portal/frontend/[orgSlug]/portal/dashboard/page.tsx | Current source at the reviewed revision; release history is stated separately | Modules can inject widgets and page content | Each injected journey needs implementation, authorization, and acceptance | Design, implementation, authorization, and acceptance | Portal product and delivery owner | 2026-07-14 |
| CRM links | configurable | customer_accounts/AGENTS.md | Current source at the reviewed revision; release history is stated separately | Customer users can link to CRM people and companies | Matching and ownership rules need project review and reconciliation | Approved policy, configuration, server enforcement, and tests | Portal product and delivery owner | 2026-07-14 |
| Organization bound routes | available foundation | apps/mercato/src/app/(frontend)/[...slug]/page.tsx | Current source at the reviewed revision; release history is stated separately | Protected routes compare session organization with the URL organization | Organization scope is distinct from CRM company scope | Enabled modules, configured application, and project acceptance | Portal product and delivery owner | 2026-07-14 |
| Controlled rollout | configurable | customer_accounts setup and feature checks | Current source at the reviewed revision; release history is stated separately | Roles, features, and account activation can constrain access | A safe pilot still needs environment, monitoring, support, and rollback owners | Approved policy, configuration, server enforcement, and tests | Portal product and delivery owner | 2026-07-14 |
| Custom domains | configurable | customer_accounts/api/admin/domain-mappings.ts | Current source at the reviewed revision; release history is stated separately | Registration, DNS checks, TLS checks, routing, workers, and schedules exist | Domain ownership, DNS, certificates, email links, monitoring, rollback, and decommissioning remain operational work | Approved policy, configuration, server enforcement, and tests | Domain and operations owner | 2026-07-14 |
B2B journey matrix
Open: B2B journey matrix18 items
| Business journey | Reviewed state | What must be decided or proven |
|---|---|---|
| Account access | available foundation | Choose invitation or signup, verification, recovery, and session policy |
| Profile | available foundation | Define allowed changes, evidence, and support |
| Company user management | configurable | Require company association, delegated roles, and negative scope tests |
| Catalog visibility | not evidenced | A seeded permission name does not establish a first party catalog page |
| Customer specific assortment | custom | Define entitlement source, price and product ownership, and denial behavior |
| Price lists | custom | Define source of truth, effective dates, currency, and reconciliation |
| Quote requests | custom | The permission vocabulary is not an accepted quote journey |
| Cart | not evidenced | No complete first party cart route was found in the reviewed portal tree |
| Order creation | custom | Requires product, price, validation, approval, idempotency, and fulfillment contracts |
| Order history and status | integration required | Requires a system of record, identifier mapping, freshness, and outage behavior |
| Invoice access | integration required | Requires document authority, authorization, retention, and failure handling |
| Documents | custom | Define storage, classification, visibility, retention, and missing document behavior |
| Returns | custom | Define eligibility, approval, inventory, payment, and exception paths |
| Delivery tracking | integration required | Carrier or order system acknowledgement and reconciliation are required |
| Support requests | custom | Define case ownership, routing, service policy, escalation, and evidence |
| Notifications | configurable | The foundation exists, but each trigger, channel, preference, and failure path is project scope |
| Payments | integration required | Requires gateway, checkout, idempotency, webhook, reconciliation, and refund evidence |
| Approvals and partner journeys | custom | Define roles, separation of duties, state transitions, and accountable owners |
Identity and authority boundaries
Open: Identity and authority boundaries8 items
| Boundary | Meaning | Manager check |
|---|---|---|
| Staff authentication | Internal operator identity | Do not reuse it as customer identity evidence |
| Customer authentication | Separate customer user, credentials, sessions, roles, and features | Must be tied to the intended tenant and organization |
| Tenant | Top data partition in the reviewed application model | Does not define the commercial customer account by itself |
| Organization | Operational scope used by routes and authorization context | Is not automatically the CRM company or account |
| CRM company or account | Business customer relationship record | Must be linked and reconciled with customer users deliberately |
| CRM person | Business contact record | Is not the same object as a login account |
| Customer user | Portal login identity that may link to person and company | Lifecycle and recovery need an owner |
| Role and feature | Access vocabulary used by server checks and navigation | UI visibility never replaces server enforcement |
Account and journey decision path
Name one measurable customer outcome and one persona. Stop if the portal is still one undifferentiated estimate.
Choose invitation only or open signup. Record who approves activation and what verification evidence is retained.
Choose password, magic link, or both. Define reset, session revocation, inactive account, and recovery paths.
Define tenant, organization, customer company, person, and customer user relationships. Test wrong organization and cross company denial.
Assign the default role, delegated portal administrator, allowed features, and server side enforcement point.
Choose the organization URL or a custom domain. Assign domain, DNS, TLS, email link, monitoring, incident, rollback, and decommission owners.
Define deactivation, role removal, session revocation, password reset, account recovery, and retained evidence before onboarding users.
For the chosen object and action, name the system of record, identifiers, read and write direction, freshness, and retention.
Classify the journey as foundation, configurable, custom, integration required, or not evidenced. Do not promote it from UI text.
Define retry, idempotency, reconciliation, outage, stale data, duplicate submission, and missing document behavior.
Assign business, delivery, security, privacy, integration, support, domain, and exit owners.
Accept one thin end to end journey in a controlled environment before expanding the portal.
Staged delivery and acceptance
Open: Staged delivery and acceptance7 items
| Stage | Entry evidence | Owner | Pass | Stop | Containment | Evidence retained |
|---|---|---|---|---|---|---|
| Foundation verification | Identity and route inventory | Delivery owner | Exact route and API evidence reviewed | Missing account model or environment | Contain scope and keep access closed | Inventory and decision log |
| Thin journey | One persona and outcome | Business owner | Normal and denied paths pass | Unknown system of record or authority | Disable the journey | Test trace and reconciliation sample |
| Controlled pilot | Named pilot group and support | Operations owner | Exceptions are handled within policy | Scope leak, unresolved incident, or no support | Revoke pilot access | Pilot log and incident notes |
| Business reconciliation | Source and portal records | Data owner | Counts, states, and exceptions reconcile | Unexplained difference | Pause writes and investigate | Signed reconciliation report |
| Operational rehearsal | Monitoring, domain, email, backup, recovery | Service owner | Alert, recovery, and support paths work | No owner or failed recovery | Return to test environment | Rehearsal evidence |
| Go or no go | All blockers and residual risks | Authorized sponsor | Every blocker closed or explicitly rejected | Any critical criterion open | No launch | Dated approval record |
| Incremental expansion | One additional journey at a time | Product owner | New journey passes the same gates | Prior journey unstable or unowned | Do not expand | Updated inventory and acceptance pack |
Open: Portal scope worksheet
Local planning tool
Portal scope worksheet
Use abstract role labels and evidence references only. Do not enter credentials, personal data, customer or company names, commercial secrets, record identifiers, tokenized URLs, infrastructure addresses, or production configuration. Data stays in this browser and is never submitted by this page.
Privacy: this page does not submit worksheet content, place it in the URL, or store it in cookies.
Hypothetical examples
Open: Synthetic examples2 items
Synthetic example
Hypothetical distributor order status
- Persona or role label
- Buyer role A
- Customer account boundary
- One fictional distributor account
- Measurable outcome
- See accepted order state without calling support
- Entry and authentication method
- Invitation only and verified email
- Object and action
- Read order status
- Data shown or changed
- Synthetic order state only
- System of record
- Order system A
Synthetic example
Hypothetical service document request
- Persona or role label
- Service customer role B
- Customer account boundary
- One fictional service account
- Measurable outcome
- Request a missing document and track ownership
- Entry and authentication method
- Password plus recovery policy
- Object and action
- Create support request
- Data shown or changed
- Abstract document category and message
- System of record
- Case system B
Project acceptance evidence
Open: Project acceptance evidence15 items
- normal journey
- denied action
- cross company access
- wrong organization
- expired or revoked session
- unverified or inactive account
- integration outage
- duplicate submission
- stale data
- missing document
- inaccessible widget
- mobile at 360 px
- keyboard only
- reduced motion
- JavaScript disabled
Poor fit and stop conditions
- A turnkey storefront is required without product development.
- The customer account, company, person, user, tenant, or organization model is undefined.
- No owner exists for the system of record, personal data, integration, reconciliation, support, domain, testing, or rollback.
- Permissions exist only as UI labels or navigation hiding.
- An external system, exception path, test environment, or containment plan is missing.
Selected verification sources
Links are contextual evidence. They do not replace review of the actual application.
Method, assumptions and limitations
Reviewed 14 July 2026. Product facts were checked against both the public code at the cited repository revision and official documentation. Where documentation and code differ, this guide describes behavior supported by code. Interpretations and recommendations concern implementation work, not product guarantees.
This material is not a quote, audit, certification, or legal, tax, or accounting advice. Edition, enabled modules, configuration, custom code, infrastructure, data, third-party providers, and operating practices affect the outcome.
Primary source collections: code repository, documentation, public releases.