Client Requests

Collect, triage, assign, and resolve client requests from one structured workflow.

This page explains how Client Requests 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

Capture client requests with type, priority, status, project, owner, and due date.
Convert requests into tasks, approvals, deliverables, or follow-up actions.
Keep request history attached to the correct client and workspace.

When to Use This Feature

Use it when clients need a structured way to ask for changes, new work, questions, or file updates.
Use it when your team wants to convert client asks into tasks, deliverables, approvals, or follow-ups.
Use it to avoid losing client requests inside email threads, chat messages, or meeting notes.

Practical Examples

A client submits "Update homepage banner copy" from the portal; the agency converts it into a task under the active website project.
A client uploads new brand files through a request; the team attaches them to the asset library and marks the request resolved.
A client asks for a new monthly report; the account manager turns the request into a client report workflow.

Recommended Workflow

Collect the request from the client portal or create it manually from the workspace.
Classify the request by client, company, project, priority, type, owner, due date, and status.
Review attachments and clarify missing information before assigning work.
Convert the request into a task, approval, deliverable update, report follow-up, or support item.
Close the request only after the client receives a response and the related work is updated.

Important Fields and Records

Request title, type, priority, description, client, company, project, owner, status, and due date.
Attachments, screenshots, requested changes, internal notes, client comments, and resolution notes.
Connected task, approval, deliverable, report, support ticket, or communication follow-up.

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.