Every MSP wants technicians to have enough access to do the job and no more. The hard part is that "the job" changes with each customer and each technician.
TenantVigil splits the problem into two parts: partner roles and customer assignment. This article explains both, in the order an MSP should set them up.
Start with the two partner roles
TenantVigil has two partner roles that matter for customer visibility.
A partner admin sees every customer the MSP owns. A member sees only the customers assigned to them.
The roles are about console visibility, not Microsoft privileges. Inviting someone as a partner admin in TenantVigil does not make them a global administrator in any customer tenant.
Assign customers, then invite staff
Set up the roles first, then invite staff into bounded partner roles from the Team page. An invitation does not grant Microsoft administrator privileges in any customer tenant.
After the invitation, a partner admin assigns each member to the customers they support. The member can then move between those customer contexts from My customers.
This is the order that avoids the common mistake: invite ten people, give them all admin, and only later realise half of them can see customers they do not support.
See Assign staff to customers for the full steps.
Check what a member can actually see
Each person sees only the customer data their current grants allow. If a grant ends, a suspension lands or a customer moves to another MSP, the person's view of that customer ends.
Search and filters work inside that same boundary. A member can search and filter only the customers they are allowed to reach. The search box does not become a way around assignment.
Here is the difference at a glance:
| Role | Customer visibility | Typical use |
|---|---|---|
| Partner admin | Every customer the MSP owns | Owner or service manager |
| Member | Only assigned customers | Technician or specialist |
The table is about console visibility. It says nothing about Microsoft permissions in a customer tenant.
Review access when the team changes
Access reviews are part of the job, not a once-a-year exercise.
When a technician leaves, suspend their account. When a technician changes teams, change their customer assignments. When a customer moves to another MSP, the relationship change ends your team's access to that customer.
Keep the assignment list short enough to review. If every member sees every customer, the boundary is not doing its job.
Keep console access and Microsoft consent separate
A technician who can open a customer in TenantVigil still needs that customer's administrator consent before TenantVigil reads the tenant.
The customer's administrator completes consent once, and the tenant is linked only after the consent checks pass. A missing source permission does not fail the whole scan; the affected checks are left not read.
Native changes need another layer. Each sender needs its Microsoft permission granted and its callback URI registered before it works for a customer. See Microsoft permissions and customer access for the details.
Explain what the customer sees
Customers also get a plain-English view of access. A customer's owners and admins can see the MSP people who can open the organisation now, their role and grant date, and what the MSP did there in the last 90 days that TenantVigil records.
That view is a plain-English explanation of access. It is not a substitute for the customer's own Microsoft permission review.
When a customer leaves
When a customer leaves your MSP or moves to another provider, your team's access ends with the relationship. The customer owner disconnects or leaves from Settings. Native Microsoft grants may need separate removal in Microsoft Entra.
Do not rely on the console alone to remove every Microsoft permission. A local disconnect does not erase every grant outside TenantVigil.
Keep the customer view in your onboarding script
Add one step to every customer onboarding: have the customer open the access view and confirm who can see the tenant. That step catches assignment mistakes while the relationship is new.
Then repeat the check when staff change roles or leave. The view is most useful when it is read, not just available.
A review checklist for a growing team
Run this list whenever a technician joins, changes team or leaves:
- Set the person to admin or member on purpose.
- Assign members only to the customers they support.
- Check that a suspended or departed person no longer appears in a customer's access view.
- Confirm the customer's Microsoft consent is still current for the work the person will do.
Each step takes a few minutes. Together they keep the boundary in place without a heavyweight process.
What to avoid promising
Do not promise zero standing privilege or time-limited access unless you have built that outside the product. The console gives bounded roles and assigned customers, not a just-in-time approval workflow.
Do not promise that every action is audited. TenantVigil records what it records; a native action also depends on the plan, approval and receipt path.
What to do next
Review your current staff list. Make every person a member unless they need partner admin. Assign each member only to the customers they support. Then have one customer open the access view and confirm it matches what you expected.