For an MSP, "run customer work" often means a pile of logins. One customer uses a shared global admin account. Another has three technicians who each know part of the setup. A third has no record of who changed what.
TenantVigil takes a different route: start from the customer, then move through the work the same way every time. This article walks through that route in order. The example customer is Contoso Dental. It is example data, not a real customer.
Choose a reachable customer
Sign in to the partner console and open the customer list. You see only the customers your current grants allow. A partner admin sees every customer the MSP owns. A member sees the customers assigned to them.
Search and filter from that same list. If you cannot open a customer, check your assignment before looking for a workaround. Access that is missing on purpose is a boundary, not a bug.
A customer appears in the console only after a real administrator consents. The consent flow checks that the signed-in directory matches the invited tenant and that the invitation issuer is still an approved MSP. See Connect a customer tenant for the consent steps and the disconnect rules.
Work from one customer context at a time. The context keeps the customer in view while you move between queues, findings, plans, receipts and reports. This is the habit that removes the "which tenant am I in now?" question.
Keep the customer thread visible
Each customer's work stays connected to that customer. A finding links to its evidence. A plan links to the exact target. A receipt links back to the plan. A report is built from stored scan results for that customer.
This means you can answer the questions that recur: what did we find, what did we plan, what did Microsoft return, and what did the customer see? You do not rebuild that story from a ticket note and a sign-in log.
The same thread helps when work changes hands. Another technician opens the customer, reads the request and the receipt, and continues from the same record instead of starting over.
Review assigned work
Open a customer context. The work queue shows owned requests, cases and the receipts attached to them. Choose one item and read it before you act.
Example data: a group-membership request for Contoso Dental is assigned to one technician. The request names the group and the member. It is not a vague ticket that says "fix permissions".
If no work item exists, open one from a finding. A finding has a stable identity, so the next scan can show whether anything changed. Own the work in your queue; do not leave it in a shared inbox where nobody knows who is acting.
Check current access before a change
Before you plan a change, confirm two things: you are in the right customer context, and your role lets you work on that customer.
Console access and Microsoft consent are separate. You can see a customer in TenantVigil only after the customer consents. A native change in Microsoft 365 also needs its own permission grant and callback registration. See Microsoft permissions and customer access for the boundary.
This check matters because a technician can often see a setting while the customer has not granted the permission that would let a change run. The console does not pretend the missing permission is a failed change. It keeps the two facts separate.
Plan the change, then approve it
Stage the exact operation and target before asking for approval. A plan names the customer, the action and the object it changes. TenantVigil runs preflight safety checks against the plan and refuses a body that does not match the allowed shape.
Approval is scoped to that exact plan. If you edit the plan, the approval no longer applies. For many native changes, an independent partner admin also approves.
Not every change has a sender. Exchange forwarding, FullAccess, SendAs, distribution-list membership and an unsupported organisation setting stay manual because no supported Microsoft API exists for them. A technician makes those changes in Microsoft 365 or PowerShell, then reports back. The receipt for manual work records that a technician resolved the request, not that a scan later verified the setting.
Read the receipt
After a change runs, read the receipt. It records what was attempted and what Microsoft returned. The state is per operation. It is not a blanket promise that every change was verified.
The common states are:
Ready, not sentApplied; not verifiedVerified in MicrosoftOutcome unknown; check before retrying
An unclear result is not resent automatically. If the receipt says the outcome is unknown, check before retrying. A receipt with no clean undo says so.
Close the loop with the customer
After the receipt, tell the customer what happened in one short note. Use the receipt, not a summary from memory. If the receipt says Applied; not verified, say that. If it says Verified in Microsoft, say that and the time.
The report later gives the longer view. The note gives the immediate answer. Both should agree with the receipt.
Prepare the customer report
Reports and evidence packs are built from stored scan results, so the data-as-of time is visible. Produce a branded recurring service report, and keep the evidence pack for the customer.
A branded report is not a fully rebranded portal. The report is yours; the product is still recognisable. See Prepare a customer service report.
What to do next
Start with your own account. Read Start your MSP account, connect a test customer, and work one request through to its receipt. That one pass builds the habit the rest of the console follows.