Data
Order number, statuses, dates, and the fields each client is allowed to see.
Client portal and partner portal
Give clients one clear path to statuses, documents, and requests
Create a portal for customers, dealers, or partners: people see only the data they are allowed to see, download a document, submit a request, and know what happens next.
- For whom
- Companies whose customers, dealers, or partners repeatedly ask for order statuses, documents, and terms.
- Business outcome
- Routine questions move into the portal, while managers receive requests with the relevant context attached.
Client journey demonstrationPortal and documents
TaskCheck an order status and get documents
- 01Check an order status
- 02Download a specification
- 03Reply to a request
ordersstatusesdocumentsrequests
Before building the portal
What should be clear before you launch a client portal
A portal is more than a gated page. Start by defining which actions customers should complete without emailing a manager and which data each role may see.
- What will a client see?
An order or request status, documents, activity history, and the next step.
- Who gets access?
Customers, dealers, partners, or employees — with different roles and data scopes.
- What happens after a request?
The form sends approved fields to the owner, while the status explains what to do next.
What to prepare
Start with one real order or client request
Use a journey that customers currently ask a manager to complete. This defines the portal by useful actions instead of an arbitrary screen list.
Documents
Invoices, agreements, specifications, and access rules for each file type.
Actions
A request, reply, document upload, or confirmation of the next step.
The client journey
From signing in to an answer without emailing a manager
Open every step in the browser and review it as a specific role before launch.
- 01
Sign in
The client gets access only to their data and documents.
- 02
Understand the status
The first page shows the order state and next action.
- 03
Get the document
The relevant file sits next to the order or request.
- 04
Send a request
The manager receives the subject, order, and completed fields.
What the result looks like
Review the complete portal journey, not isolated screens
One pass shows what customers see after sign-in, where they find a document, and what happens after a request. A CRM or accounting-system connection is confirmed separately.
Client portal screenstatus · documents · request
Clients know what is happening
The status and next action are visible without asking a manager.
Documents stay with the task
An invoice, agreement, or specification appears in the right context.
Managers receive a complete request
The message already includes the client, order, subject, and required fields.
Access and security
Access is scoped by role and approved data
Your team defines which statuses, documents, and actions each role can use. Before launch, access, the data source, and form behavior are checked so the portal does not expose more than a client needs.
Roles for customers, dealers, partners, and employees
Recorded in the project rules and checked before launch.
Only approved fields and documents
Recorded in the project rules and checked before launch.
Access and action checks before publishing
Recorded in the project rules and checked before launch.
Scope boundaries
What Fluw can assemble and what needs a separate review
In Fluw
Portal pages, statuses, documents, forms, and ordinary interface changes.
After setup
Data from a confirmed source and request routing through an agreed workflow.
Separate assessment
A new connector, complex permissions, payments, e-signatures, or critical business logic.
Before you start
Common questions about client and partner portals
Do we need a CRM or accounting system first?
No. You can start with files and a field description. If a system exchange is needed, we first check its API, permissions, and data scope.
Can documents and statuses be hidden from other clients?
Yes, that is part of role and access design. The exact rules depend on the data source and are confirmed before launch.
Does the portal send notifications automatically?
Only when that channel and route are configured separately. Notifications are not treated as ready without an integration check.
What if the source data changes?
The portal receives approved updates through a confirmed connection, or stays on a manual file update. That boundary is recorded in the project scope.
Start