Stakeholders

Track client contacts, decision makers, reviewers, approvers, and communication owners.

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

Store stakeholder names, emails, roles, departments, and relationship notes.
Assign stakeholders to companies, projects, approvals, reports, and client requests.
Use stakeholder records to route review requests and avoid sending approvals to the wrong contact.

When to Use This Feature

Use it when a client has separate contacts for approval, billing, project feedback, and executive signoff.
Use it when review requests must go to a specific person instead of a generic company email.
Use it when client portal access should be limited to named people with known responsibilities.

Practical Examples

The marketing manager receives review queue items, the COO receives final approval requests, and the accountant receives billing-related notifications.
A stakeholder can be allowed to review deliverables without seeing internal tasks, team notes, or unrelated projects.
When a contact changes roles, the admin can update stakeholder responsibility without rewriting project history.

Recommended Workflow

Open the related company or client record before creating the stakeholder.
Add the stakeholder name, email, role, department, phone, and responsibility in the client relationship.
Mark whether the stakeholder is a decision maker, reviewer, approver, billing contact, or portal user.
Attach the stakeholder to projects, approvals, reports, deliverables, and requests where their action is required.
Review access and notification settings before sending portal invitations or approval requests.

Important Fields and Records

Stakeholder name, email, phone, job title, department, role, and company relationship.
Reviewer, approver, billing contact, executive sponsor, project owner, or portal user flags.
Assigned projects, approval requests, review items, reports, communication notes, and activity history.

Best Practices

Record the stakeholder role clearly so team members know who approves, who pays, and who gives feedback.
Use named stakeholder accounts instead of shared inboxes for approvals and audit history.
Remove or disable portal access when a stakeholder leaves the client organization.
Keep communication notes professional because they may be used during account handoff or dispute review.
Review stakeholder access before sharing sensitive files, invoices, reports, or executive summaries.

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.