Loading workspace...
Auroranexis documentation
The client portal gives your customers a secure, branded view of deliverables and operational status you choose to share. Portal users sign in separately at /client-portal/login and see only data for their assigned client. Internal admins manage portal users from each client's detail page, publish reports after internal review, control incident visibility per record, and apply white-label branding from Settings → Branding.
The client portal is a dedicated external experience, separate from your internal dashboard. Client contacts authenticate at /client-portal/login with credentials tied to a single client record. They cannot see other clients in your portfolio or access internal-only modules such as billing, team management, or automation configuration.
Internal admins manage portal users from each client's detail page in the dashboard. Published reports, portal-visible incidents, and branding configured in Settings → Branding determine what contacts see after sign-in. The portal is read-focused: clients review reports, track incident summaries you expose, and view health and SLA context appropriate for external audiences.
Portal authentication is independent from internal team login. Portal sessions cannot access dashboard routes, and internal sessions cannot impersonate portal users without explicit admin action. This separation keeps external access narrowly scoped.
Agencies need a professional, controlled way to share deliverables and status without granting full platform access. The portal reduces email attachment churn, gives clients a single destination for QBR reports, and builds trust through transparent incident communication when you enable it.
White-label branding from Settings → Branding ensures the portal reflects your agency identity—or co-branding where configured—rather than generic platform chrome. Clients experience a polished, on-brand destination that matches proposals and SOW materials.
Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.
Internal vs. portal access
| Capability | Internal dashboard | Client portal |
|---|---|---|
| Login URL | Standard app login | /client-portal/login |
| Scope | Full organization (by role) | Single client only |
| Reports | Draft and published | Published only |
| Incidents | All incidents | Portal-visible incidents only |
| Branding | Dashboard theme | Settings → Branding white-label |
A portal user is an external contact with email, name, and password scoped to exactly one client. Multiple portal users can exist per client—each person should have their own account rather than shared credentials. Disable portal users promptly when contacts leave the client organization.
A marketing agency white-labels the portal in Settings → Branding with their agency logo. Each retainer client receives two portal users—the marketing director and a finance contact. Monthly performance reports publish after internal review; clients sign in at /client-portal/login to download PDF exports before QBR calls. Incidents are rarely portal-visible; transparency flows through reports instead.
An AI automation firm enables portal access for clients running production workflows. Portal users see published monthly operations reports and portal-visible incidents when automations affect client systems. The agency uses co-branded Settings → Branding for reseller clients. Portal users are provisioned during onboarding and disabled within 24 hours of contract end.
An MSP grants portal access to IT leads at each managed client. Published reports summarize uptime, incidents, and SLA compliance. High-severity incidents enable portal visibility with client summaries updated during bridge calls. Portal users cannot see internal technical notes or unrelated clients in the portfolio.
A strategy consultancy uses the portal primarily for report delivery. Partners publish engagement summaries and executive decks; portal visibility on incidents is rare. Branding matches proposal materials configured in Settings → Branding. One portal user per stakeholder keeps access auditable for regulated clients.
An enterprise agency deploys the portal across hundreds of clients with standardized branding and SSO considerations per contract. Portal user provisioning follows an ITIL-style access request process. Published reports require a two-person review before publish. Incident portal visibility follows a communications playbook with pre-approved summary templates.
Client portal troubleshooting
| Problem | Cause | Solution |
|---|---|---|
| Portal user cannot sign in | Wrong email, disabled account, or incorrect login URL. | Verify the email on the client detail page; confirm the user is enabled; share /client-portal/login; use password reset if needed. |
| Report not visible in portal | Report is Draft or belongs to a different client. | Publish the report from Reports; confirm the report client matches the portal user's client. |
| Incident missing from portal | Portal visibility is disabled by default. | Enable portal visibility on the incident record and add a client-facing summary. |
| Wrong logo or colors in portal | Branding not saved or browser cache serving old assets. | Review and save Settings → Branding; hard-refresh the portal or sign out and back in. |
Share your deployment URL with the /client-portal/login path—for example https://your-domain/client-portal/login. The login form accepts portal user email and password. Password reset flows are available from the login page when enabled for your deployment.
Reports must be published from the internal Reports module before they appear in the portal. Draft and generated reports are never visible externally. Publishing is the explicit gate between internal review and client delivery.
Incidents are internal by default. Enable portal visibility on individual incidents to share summary, status, and timeline appropriate for the client. Incidents without portal visibility do not appear in the portal. Internal description and resolution notes remain for your team only.
Organization branding—logo, colors, and display name—configured in Settings → Branding applies to the client portal shell, login page, and authenticated views. Clients see your agency identity, not generic marketing chrome.
| User sees unexpected client data |
| Portal user created on the wrong client record. |
| Verify the user was created on the correct client; disable and recreate if misassigned; contact support if cross-client data appears. |
| PDF export unavailable in portal | Export not enabled for the report or plan limitation. | Confirm export settings on the report; verify plan includes portal PDF export where applicable. |
| Branding not applied to login page | Branding changes not published or plan lacks white-label. | Save and publish branding in Settings → Branding; upgrade via Settings → Billing if white-label is plan-gated. |
