Client Portal Administration

Setting Up Client Logins

The Client Portal uses a separate authentication system from your internal staff login. Clients authenticate via cookie-based sessions rather than JWT tokens, and their access is automatically scoped to their own client record -- they can never see another client's data.

To create a client login, navigate to the client's record in XeroFlow and open the Portal Access section. Enter the client contact's email address and send an invitation. The recipient receives an email with a secure link to set their password and access the portal. You can invite multiple contacts per client, each with their own login credentials and individual permission sets.

Configuring Permissions

Each client portal user has a set of granular permissions that control exactly what they can see and do. The three primary permissions are:

• canViewInvoices

  Allows the client user to view their invoices and billing history in the portal. When disabled, the Invoices section is hidden entirely from their navigation.

• canApproveWork

  Grants the ability to approve or request revisions on deliverables submitted for review. Without this permission, the user can view approval items but cannot take action on them.

• canAddComments

  Enables the user to leave comments on projects, approvals, and deliverables. This is useful for client contacts who need to provide feedback but should not have approval authority.

Permissions are set per user, not per client, so you can give a marketing director full access while limiting a junior contact to view-only. Changes take effect immediately -- no logout required.

Managing Approval Workflows

The approval system lets you submit deliverables -- design mockups, ad creatives, copy documents, or any file -- to a client for review. When you create an approval request, you select the client, attach the deliverable files, and add a description of what needs to be reviewed.

The client sees the approval in their portal with a clear status: Pending, Approved, or Revision Requested. When a client requests revisions, they can add comments explaining what needs to change. Your team receives a notification, makes the updates, and resubmits. The full history of submissions, comments, and status changes is tracked, creating an auditable record of the approval process.

Customising the Portal Experience

The portal layout adapts based on permissions. If a client user does not have invoice access, the Invoices tab disappears from their sidebar entirely -- they never see it. The same applies to approvals and other permission-gated sections. This means each client contact sees a clean, relevant interface tailored to their role.

The portal includes a dashboard with an overview of active projects, pending approvals, and recent notifications. A creative gallery page shows all delivered assets in a visual grid with download and preview capabilities. The notifications system alerts clients when new deliverables are ready, invoices are issued, or project updates occur.

Inviting Clients

The invitation flow is designed to be frictionless. When you send an invite, the client receives a branded email from your agency with a link to accept the invitation, set a password, and access their portal. Invitations expire after 7 days but can be resent at any time.

You can track invitation status from the client record -- see whether an invite was sent, accepted, or is still pending. If a client user forgets their password, they can reset it through the portal login page without needing to contact your team. Session management uses secure httpOnly cookies, and sessions are scoped to the portal domain to prevent any overlap with staff authentication.

Security and Data Isolation

Every portal API endpoint enforces data isolation at the query level. When a client user makes a request, the server automatically scopes all database queries to their clientId. There is no parameter the client can manipulate to access another organisation's data -- the scoping happens server-side based on the authenticated session.

Staff and client authentication systems are entirely separate. The global auth middleware skips all /portal routes, and portal middleware only applies to portal pages. This dual-auth architecture ensures that a compromised client session cannot escalate to staff-level access.