5 min lesson
Setting up user groups
User groups in Frontline let you permission objects, activity timeline visibility, and Max runtime. Use groups like Management and Sales, not one group per person.
A user group is a named set of people in the workspace. Management. Sales. Support. You put users in a group once, then you grant access to the group instead of clicking through every seat when something changes.
Roles still matter. Owners and admins decide who is in which group. Users do not build the groups. The group is not a second role. It is the list you use when you permission the work.
Why groups exist
A firm does not give every seat the same picture. Sales needs people, companies, the pipeline, and Max. Support needs tickets and the fields that close a request. Management might need the full picture, plus the ability to see activity across books. If you grant that person by person, the next hire repeats the same clicks, and someone is always missed.
Groups fix the repeat. Create Sales, add the people who carry a book, and attach permissions to Sales. When a new hire is invited as a user, you add them to Sales and they inherit the same access. When someone moves into Management, you change the group, not a dozen checkboxes.
Only admins and owners can create, rename, and delete groups, and they can only add people who already belong to the account. Invite first, then group.
What you permission with a group
Groups show up wherever Frontline asks who is allowed to do something. Three places matter most in this course.
Objects. This is access to the CRM itself: which objects and record types a group can see, create, update, or delete. Sales might get full working access to People, Companies, and Deals, and lighter access on Tickets. Support might get Tickets and Contact fields that Sales should not edit. Management might see every object. If a group cannot see Leads, those users will not find James Harrington until he is a Contact. Be explicit. Object permissions are how you keep a clean model from becoming a free-for-all after you invite the firm.
Activity timeline. This is who can see the history on a record, including synced email and WhatsApp, not only the notes the team typed. The timeline still redacts what a person is not allowed to see, in the app, through Max, and through the CLI. Groups let you say “Sales can see shared activity on People” without opening every mailbox to the whole company. Someone in Support and someone in Management can both open James and still see different depth, if that is how you set sharing.
Max runtime. This is who can run Max, and how far Max can go for that group. Max reads the same objects and the same timeline the user is allowed to see. If Sales has runtime and a contractor group does not, only Sales can ask Max to find a household, log a call, or update a field. If a group can run Max but cannot update Deals, Max will not move the mandate for them. Runtime is not a bypass. It is permission to use the assistant inside the access you already granted.
You will also see groups on tables, workflows, and agents when you share those resources. The pattern is the same. Prefer a group over a long list of names. People change. The job does not.
A simple group map
Start smaller than the org chart. A few groups named for the job, not the person, cover most teams.
Sales gets People, Companies, and Deals, timeline visibility for the records they work, and Max runtime so they can log a call from a voice note. In a wealth firm, that is the advisors who own the relationship with James and Harrington Family Office.
Support gets Tickets, the Contact fields that finish paperwork, and enough timeline access to complete a beneficiary change without seeing every private WhatsApp thread. If you do not have a support seat yet, skip the group until you do.
Management gets the wider picture: objects across the workspace, broader timeline visibility, and Max runtime. Partners and team leads usually sit here, often on top of an Owner or Admin role, which still overrides group limits when they need to fix the workspace.
Do not create a group per person. “James’s team” is an assignment problem, not a group problem. Put the salesperson on the record. Put that salesperson in Sales.
Name groups the way the company already talks. Management, Sales, Support, Marketing, Operations. Avoid names that go stale, like a quarter or a project. Review groups when you invite a class of hires, not every Monday. If a permission question keeps coming back as “can this person see the email on James,” it is a timeline grant on the group, not a new object.
What good looks like
A healthy workspace has few roles and few groups. Owners and admins are rare. Users are the default seat. Groups match jobs, Management and Sales first, then only what you need. Object access, timeline visibility, and Max runtime are set on those groups so a new salesperson inherits a working day instead of a scavenger hunt.
Next, the last lesson in this section: to-dos, notes, and files, the work that sits on the record after the people are in.