Docs / FlowCRM AI

Client Portal

Understand the client-facing portal used by customers to review projects, deliverables, approvals, files, reports, exports, and requests.

Estimated reading: 4 minutes

Client Portal

Understand the client-facing portal used by customers to review projects, deliverables, approvals, files, reports, exports, and requests.

This page explains how Client Portal works inside FlowCRM AI, when to use it, how teams should operate it, and what administrators should check before enabling it for real workspaces or paid plans.

Main Capabilities

  • Client users get a simplified workspace focused on review, delivery, files, reports, and requests.
  • The portal hides internal operations while keeping client-facing work easy to access.
  • Access is controlled by portal permissions, workspace scope, client relationship, and plan settings.

When to Use This Feature

  • Use it when onboarding a new client or organization.
  • Use it when multiple projects, stakeholders, reports, or files belong to the same customer.
  • Use it when account managers need one place to review client activity and portal status.

Practical Examples

  • Use this page while setting up a demo workspace so buyers understand the feature with real client data.
  • Create one sample record, connect it to a client and project, then test what internal users and client portal users can see.
  • Review the related report, activity, permission, and export behavior before presenting the feature to customers.

Recommended Workflow

  1. Enable portal access for the correct company, stakeholder, or client user.
  2. Choose which projects, deliverables, approvals, reports, exports, and shared files are visible.
  3. Test the portal with a client-level account before inviting real clients.
  4. Use the portal for review, approvals, downloads, reports, and new requests instead of scattered email threads.
  5. Audit portal activity regularly to confirm clients are viewing and responding to shared work.

Important Fields and Records

  • Client name, organization, owner, contact details, portal status, and workspace relationship.
  • Related projects, reports, approvals, files, notes, and activity timeline.
  • Access settings that control what the client can view or manage.

Section Guide

This section contains the related pages below. New buyers should read them in order first, then return to the specific page that matches the task they are setting up.

  • Overview: Explain the client portal home page and what clients can see after logging in.
  • Delivery Timeline: Let clients follow project milestones, delivery events, due dates, and handoff progress.
  • Deliverables: Show client-ready deliverables with status, files, versions, notes, and review actions.
  • Approvals: Give clients a focused list of items that require formal approval or rejection.
  • Review Queue: Show all client review items that need feedback, comments, approval, or follow-up.
  • Shared Files: Provide clients with access to shared files, documents, assets, reports, and delivery attachments.
  • Reports: Let clients view delivered reports, performance summaries, AI reports, and project updates.
  • Exports: Allow clients to access exported reports, files, summaries, and delivery packages.
  • New Request: Let clients submit new requests, changes, questions, files, or follow-up items from the portal.

Best Practices

  • Keep names and descriptions clear enough for another team member to understand without extra context.
  • Attach records to the correct workspace, client, and project so reports and permissions stay accurate.
  • Use statuses consistently; avoid using notes or comments as a replacement for workflow status.
  • Review client-facing content before sharing it through a portal, report, approval, or delivery flow.
  • Clear application cache after module, permission, route, or pricing changes.

Plan Access and Permissions

Use this feature with the correct workspace, role permissions, plan limits, and installed modules. Some functionality can be enabled by plan, sold as an addon, or hidden when the related module is not installed. Administrators should review plan permissions before making the feature visible to customers.

  • Confirm the current user role can view, create, update, and delete related records.
  • Confirm the workspace plan includes the required feature key or addon permission.
  • Confirm related buttons, menus, and pricing rows are hidden when the module is not installed.
  • Confirm customer-facing records only expose the intended workspace, client, or project data.

Troubleshooting

The page or button does not appear
Confirm the related module is installed, routes are loaded, and the current plan includes the required permission. Also clear route, config, and view cache after module changes.

The record saves but does not show in reports
Confirm it is attached to the correct workspace, client, project, status, and date range used by the report.

A client or team member cannot access the item
Review role permissions, workspace membership, portal settings, and plan limits. Access is usually blocked by scope, role, or missing addon permission.

Old information is still visible
Clear application cache and refresh the browser. If the page is public-facing, confirm the public documentation or portal cache has been refreshed.

FAQ

Can this feature be sold as part of a paid plan?
Yes, if the related permission or addon key is connected to plans. Review your license type before selling customer access.

Can customers see this data?
Only when portal routes, workspace permissions, and visibility settings allow it. Internal records should remain hidden from client users.

What happens if the related addon is removed?
Menus, buttons, pricing fields, and routes should be hidden when the module is not installed. Keep a database backup before removing addon tables.