What a Microsoft 365 change receipt tells you

A change receipt is easy to misread. People see the word "applied" and assume the setting changed. Or they see "verified" and assume every later scan will stay green. Neither is what the receipt says.

This article separates the parts of a Microsoft 365 change: the plan, the approval, the Microsoft setup, the attempt and the response. It uses the states TenantVigil records, not invented ones.

Build the exact plan

Start with the exact operation and target. A plan names the customer, the action and the object it changes. "Add a group member" is a plan. "Fix group access" is not.

TenantVigil runs preflight safety checks against the plan. A change that is not in the supported list, or a body that does not match the allowed shape, is refused before it is sent.

The plan is the unit of approval. If the plan changes, the approval no longer covers it.

Get scoped approval

A supported change needs approval from an authorized customer decision maker. For many native changes, an independent partner admin also approves. Approval is for that exact plan, not for a general permission to change whatever comes up.

This is the part that keeps a technician's good idea inside a boundary. The technician prepares the change. The customer approves the exact fix. A second partner admin checks the work.

Finish Microsoft setup first

A native change needs its Microsoft permission granted and its callback URI registered before it can run. The customer may also need to re-consent when a permission is added. This setup is separate from the plan and the approval.

TenantVigil only reads your Microsoft 365 tenant. It never changes a setting: you apply each fix yourself.

The sentence matters because it separates reading a tenant from changing it. A scan can read settings without any change permission. A change cannot run until the plan, approval and Microsoft setup all line up.

See Plan a change and read its receipt for the setup steps.

Separate attempt from response

The receipt records two different facts: what TenantVigil attempted, and what Microsoft returned.

The attempt is the operation the plan described. The response is Microsoft's answer. A successful HTTP call is not the same as a verified change. A failed call is not the same as a change that did not happen; it means the attempt did not complete and must be read carefully.

Three common misreads

• "Applied means done." Applied means the attempt returned. Verified is the stronger state.
• "Outcome unknown means it failed." It means the response was unclear. Check before retrying.
• "One receipt covers the batch." Receipts are per operation. Read each one.

These misreads cause the wrong customer update. The fix is to read the state name, then read the timestamp, then say what the receipt says.

Read the receipt states

TenantVigil uses these common states:

• Ready, not sent means the plan exists but nothing has been sent to Microsoft.
• Applied; not verified means the attempt returned, but the result has not been confirmed in Microsoft.
• Verified in Microsoft means the result was confirmed.
• Outcome unknown; check before retrying means the response was unclear and the change is not resent automatically.

Not every path reaches verified. Some operations have no clean readback, so the receipt stays at Applied; not verified. An unclear outcome is checked before it is retried, never retried blindly.

The receipt is per operation. One change may be verified while another is not. Read the state on each receipt instead of assuming the whole batch behaved the same way.

Act on each state

Treat each state as an instruction:

• For Ready, not sent, finish the approval and Microsoft setup before you send anything.
• For Applied; not verified, open Microsoft and confirm the setting before you tell the customer it is done.
• For Verified in Microsoft, record that the check passed at that time. It is not a promise that the setting will never drift.
• For Outcome unknown; check before retrying, read the raw response and the compensation record. Do not resend the same change until you know why the result was unclear.

The receipt also shows when each part happened. That sequence helps you explain the change to a customer: planned, approved, sent, returned, verified.

Keep receipts with the customer record

Do not copy the receipt into a separate spreadsheet and call it the system of record. The receipt lives in the customer's history where the plan, approval and evidence already point.

That link is what makes an audit easier. The customer can see what you attempted. You can see what Microsoft returned. A reviewer can see that an unclear result was checked, not hidden.

What manual work still needs recording

Some Exchange changes have no supported Microsoft API. Mail forwarding, FullAccess, SendAs, distribution-list membership and an unsupported organisation setting stay manual.

A technician makes the change in Microsoft 365 or PowerShell, then reports back. The receipt for that work records the resolution, not a later verified scan. If a scan later shows the setting, that is a separate piece of evidence.

Some native changes have no clean undo. The receipt says so. Do not promise a rollback path the product does not record. Read the undo note before the change, not after.

See Supported changes and manual work for the full boundary.

What to do next

Pick one real request and read its receipt from top to bottom. Compare the plan, the approval record, the attempt and the response. When the four parts disagree, slow down before sending anything else.