Users
Invite teammates, review workspace roles, filter members, and manage row-level user actions.
Check which workspace behavior, access rule, credential, usage signal, or data-model surface the control changes.
What Users is for
Users is the workspace member control surface. The screen shows Search, a role filter, Invite user, a table with Full Name, Email, Role, and Actions.
This is where admins confirm who can operate in Frontline and which role each teammate has.
What each control changes
Search finds a teammate. The role filter narrows the table. Invite user adds a new workspace member. The Role column shows access level. Row Actions open member-specific controls.
Review this page before launching workflows that assign owners, route conversations, or expose CRM context to specific teammates.
Operational outcome
Correct user access keeps ownership clear. The right people can review Activity, receive handoffs, manage settings, and operate customer workflows.
Operational playbook
Use this page to identify what the control changes, which source context it uses, who owns the result, and where to verify it.
Use the page to identify the trigger, source data, owner, visible result, and review point before changing production behavior.
Best practices
Start with the operational job before changing configuration. Name the owner, define the trigger or source context, and decide how the result should be reviewed.
Start with one workflow, message, record update, or Max task before expanding. The team should know what changed, who owns it, and how to pause or adjust it.
Troubleshooting
If the result is wrong, debug in this order: source data, permissions, connected tools, required fields, workflow logs, then any generated output used later.
When debugging, open the related CRM record, Max activity, workflow run, or integration log first. Fix the source data or rule before adding more automation.
FAQs
What does Users control?
Invite teammates, review workspace roles, filter members, and manage row-level user actions.
Who should use this page?
Workspace admins, implementation owners, and operators responsible for configuring access, account behavior, developer integrations, or the data model.
How should this page fit into onboarding?
Use it to understand the product surface, inspect real UI states, and connect the concept to daily operating workflows before configuring production behavior.
What should I verify before using this in production?
Verify ownership, permissions, source context, failure behavior, and the handoff path so teammates can trust what the system does next.