For customers, dealers, and partners

A portal for your clients

Order status, the right document, and answers — in one place. Create a portal in Fluw that your customers can use themselves.

Describe your portal How it works

My ordersPortal example · demonstration data

Order #1042

Office equipment

Preparing for dispatch

Order progress

Order receivedItems confirmed
Payment receivedDocuments available alongside
Preparing for dispatchNext step: arrange delivery

Order documents

Invoice #1042PDF · 124 KB

SpecificationPDF · 280 KB

Files belong to this order and are available to its owner.

A delivery question

Can I change the delivery address?

The request already includes the order and customer. The manager has the context.

Less back-and-forth. More clarity.

Companies whose customers, dealers, or partners repeatedly ask for order statuses, documents, and terms.

Routine questions move into the portal, while managers receive requests with the relevant context attached.

1
Sign in
The client gets access only to their data and documents.
2
Understand the status
The first page shows the order state and next action.
3
Get the document
The relevant file sits next to the order or request.
4
Send a request
The manager receives the subject, order, and completed fields.

Access and security

Their portal. Their 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.

Review the security approach

Example access rules

Customer: Their own orders, documents, and requests
Partner: Information and terms available to their organization
Manager: Requests from customers they are responsible for

Roles and restrictions are defined for your project. Access is checked for every role before launch.

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.

Start your brief with these answers:

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.

Add a sample order, approved fields, documents, and customer actions. A CRM or accounting-system connection is reviewed separately.

Guide to preparing a client portal

Define the first version together

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.

Available integrations

About your portal

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.

Describe the portal your clients or partners need

Tell us who will use the portal and what they need to accomplish.