Group access

A role decides what someone can do. Group access decides which customers they can do it to. A Helpdesk role says someone can work tickets through AI Chat. Their group membership says whose tickets.

When you need it

Every non-admin team member needs to be in at least one group, so this is part of onboarding day one, not an advanced feature you grow into. If a technician should see every customer, add them to the built-in All Companies group and you're done. Create your own groups when someone should only see some customers:

• VIPs: some customers, or some people at a customer, should only be handled by technicians you've picked. Michael Scott wants the same two techs every time, and you don't want just anyone on the helpdesk in his mailbox. Create a VIPs group, add the technicians who look after him, and restrict his end-user account to that group. Everyone else who works Dunder Mifflin still sees the rest of the company, but not Michael.
• Pods: if your team works in pods, each pod owning a set of accounts, create a group per pod with its customers and techs. A tech in Pod A works Pod A's tickets, and the AI working on their behalf stays inside Pod A's customers too.
• Break-glass accounts: emergency admin accounts are the keys to a customer's tenant, and they shouldn't be in front of every technician. Restrict them to a break-glass group with only the senior techs who'd ever need them, so they stay hidden from everyone else working that customer.

How it applies

A group is a set of team members, plus what they can access. Access works at two levels.

Companies. A group gives its members access to the companies in it. Team members can belong to more than one group, and their company access is the combination of every group they're in.

End-users and devices. By default, anyone with access to a company can see every end-user and device in it. You don't have to set anything per user, which is right for most of a customer's staff. When an end-user or device needs tighter control, restrict it to a specific group. From then on, only members of that group can access it, even technicians who have access to the rest of the company, including through All Companies.

That override is what makes the VIP and break-glass examples work. Company access is the broad grant, and an end-user or device restriction carves out the exceptions inside it. If restrictions only added access, a VIP would still be visible to every tech who works their company, which is exactly what you were trying to prevent.

Owners and Admins see every customer regardless of group membership. Groups are what give a Manager, Engineer, Helpdesk, or custom-role user any customer access at all, not a restriction layered on top of access they'd otherwise have.

The All Companies group

Every Uniportal tenant has a system group called All Companies. It contains every company in Uniportal, and Uniportal keeps it that way: when a new company is created, from Microsoft 365 or Google Workspace, it's added to All Companies automatically.

That's the difference from a group you build yourself. Add Darryl to a custom group with all forty of your customers today, and when customer forty-one is onboarded next month, he can't see it until someone remembers to update the group. Add him to All Companies and he can, without anyone touching anything.

Use All Companies for the technicians who should work any customer, which at most MSPs is most of the team. Create custom groups only for the people who need a narrower view, like a Tier 1 queue or a branch.

All Companies can't be deleted. You manage its members, not its companies. It's also unnecessary for Owners and Admins, who already see every company regardless of group.

Group access can only be assigned once someone has accepted their invite. See Invite a team member for that limitation.

Creating a custom group

If everyone who'll be in the group should see every customer, use All Companies instead. A custom group is for picking specific customers.

Keeping groups accurate

A group only protects access as long as it reflects reality. When you take on a new customer, retire one, or move a technician between branches, update group membership too. An out-of-date group either blocks someone from a customer they now own, or leaves access open to one they no longer should see, and neither failure mode announces itself. You find out when someone complains they can't see a ticket, or when you notice someone could see one they shouldn't have.