Overview
What it does
Section titled “What it does”Customer Portal provides an authenticated /portal dashboard for a customer’s profile, preferences, support requests, and self-service items contributed by installed companion packages. Staff manage support threads in Customer Portal > Support requests.
Setup requirements
Section titled “Setup requirements”Run the package migrations and configure the host application’s authentication before publishing the portal route. The route prefix defaults to portal; every shipped portal route uses the web and auth middleware plus any middleware in capell-customer-portal.middleware.
Set capell-customer-portal.site_id deliberately on a multisite installation. If it is not a positive ID, the package assigns authenticated accounts to the lowest-ID site in the database. It does not derive the site from the current frontend hostname or route. The first portal visit creates or reuses an account for that site by authenticated owner or normalised email.
Keep the application encryption key and the configured hash_secret stable. Email, display name, profile, preferences, support subject/message/context, replies, and attachment metadata use Laravel encrypted casts. The email lookup hashes use hash_secret, falling back to the application key. Changing either key without a planned key-rotation and data-migration process can make existing data unreadable or prevent account matching.
Configure application mail and keep a queue worker running. Support submission and status-change notifications implement Laravel’s queued notification contract. The package sends those emails to the requester; it emits a submission event for integrations, but does not ship a staff email or inbox notification for a new request. Staff must monitor the admin resource or add an event listener.
Customer account behaviour
Section titled “Customer account behaviour”The portal uses the host application’s signed-in user; it does not provide registration, sign-in, password reset, or an admin account-management screen. A newly resolved portal account is Active. Suspended and Archived accounts are denied every portal workflow until an integration changes their status.
Profile fields, preference options, dashboard cards, and self-service links can be supplied by registered companion-package providers. There is no Customer Portal screen for manually choosing or ordering them. Test the portal with a realistic customer account after configuring each owning package. By default, the dashboard returns at most 12 cards and 20 self-service items, with per-provider limits of 6 and 8.
Portal responses are private and marked no-store; do not put them behind public page caching or static export. Customers can only reply to support requests belonging to their resolved portal account. The dashboard displays the five most recently submitted requests and their complete stored reply threads; it does not provide customer-side pagination for older requests.
Triage support requests
Section titled “Triage support requests”Open Customer Portal > Support requests. The admin list and record policy restrict non-global administrators to assigned sites and require the generated ViewAny:PortalSupportRequest, View:PortalSupportRequest, and Update:PortalSupportRequest permissions as appropriate. Global administrators bypass those checks.
Use Reply to store a team response and move the request to Waiting on customer. A customer reply moves it to Waiting on team. Mark waiting on customer and Mark resolved use the same status workflow; editing Status also records the Resolved or Closed timestamp through that action. Status changes queue an email containing the request subject and old/new status, but not the reply body. Customers read the reply itself in the portal.
If a queued notification fails, recover it through the application’s normal failed-job tooling. Customer Portal has no separate delivery log or retry screen. There is also no immutable support audit table: the request stores its current status and resolved/closed timestamps, while replies preserve the conversation.
Privacy and retention
Section titled “Privacy and retention”When Privacy Center is installed, Customer Portal contributes subject export and erasure. Matching uses the authenticated owner identity and email hash. Exports omit internal model IDs, relationship IDs, owner morph values, and email hashes. Erasure hard-deletes matching portal accounts, support requests, and replies.
Customer Portal does not schedule retention or automatically close, archive, anonymise, or delete old accounts and support threads. Define an organisational retention process for the encrypted database records and also review queued mail payloads, delivered email, logs, backups, and any companion-package provider data; those stores are outside the package eraser.
For how to use Customer Portal, see the admin guide. For developers: see the README.