Audit and Activity

Two items in the sidebar cover who changed what:

Audit: every change in Intune and Entra, who made it, and the way back. Its tabs are Changes, Restore, Admins, Device actions, Autopilot, Approvals, Alerts and Reports.
Activity: what people did in MDO for the tenant.

Audit and Activity link to each other.

Changes

Audit › Changes lists each change as one sentence, grouped by day: the object, who made it, how (in the Intune portal, by an app, or by MDO) and when. Click a row to open the change sheet with each setting before and after, the review, other changes to the same object, and its History.

Who made it comes from Intune’s and Entra’s audit logs, which MDO reads every 15 minutes. When Intune doesn’t report the person, the row says “actor not reported by Intune”. When several people’s events match, it says “Several people”.
Before and after come from MDO’s copy of the object, taken at the nightly collection (04:00 UTC) and whenever someone clicks Sync with Intune. A change that is in the audit log but not yet in a copy is listed at the top until the next collection. Kinds MDO doesn’t copy (apps, filters, scripts) show as event-only rows, marked “Before and after not tracked for this kind”.
MDO copies policies, assignments with their group names, Intune roles and scope tags (with DeviceManagementRBAC.Read.All), the enrollment status page, enrollment restrictions, device limits, Windows Hello, Autopilot profiles, and Endpoint security setting by setting.

Filter by search, source, who, kind of change, severity, platform, review state and acknowledged state. Needs review shows the changes no one has decided on yet.

Entra changes

Rows labelled Entra come from Entra’s audit log: Conditional Access policies and named locations, changes to groups that an Intune assignment uses, directory role assignments including PIM, app consents, permission grants and app credentials, and device deletes. Conditional Access rows show the before and after when MDO has Policy.Read.All; without it they show who and what, and say how to grant the permission in Settings › Connection. Windows LAPS password views appear under Device actions.

Approve, dismiss, acknowledge, revert

Approve marks the change as reviewed and acknowledges it. Dismiss marks it as reviewed and changes nothing in Intune.
Acknowledge takes an expected change off the open list for 30, 60 or 90 days or indefinitely. Several rows can be approved, dismissed or acknowledged at once.
Revert undoes the change. It first shows exactly what MDO will write (the value now and after the revert, the assignment lists, or the backup it will restore from). It covers:
- device configuration and compliance settings: only the settings the change touched are written back;
- assignments;
- deleted policies, recreated from the newest backup that has them, with a new ID.
MDO refuses with a reason for settings the change added, secret or write-only values, Wi-Fi, VPN, email and certificate profiles, custom profiles with encrypted settings, and changes to noncompliance actions. If the object changed again since, nothing is written unless you confirm. Reverting Settings Catalog settings is switched off for now; assignment reverts and restoring a deleted Settings Catalog policy still work. Each change can be reverted once. Revert needs a role that can restore policies (Owner or Admin).

Protected objects

From its sheet or the change sheet, an Owner or Admin can mark a policy, an app or a Conditional Access policy as protected, with a reason. Protected objects carry a badge on Changes, the policy list and the Apps list. Any change to one raises the built-in high-severity alert “A protected policy or app is changed”.

For a policy, automatic revert can be turned on (off by default). MDO then reverts a change to it after the next copy, only where Revert can do it without asking, never for a change with no reported person, at most three times per policy per day, and sends a follow-up alert with the outcome.

Alerts

Rules live in Settings › Alerts, fired alerts in Audit › Alerts and the Inbox. Built-in rules:

Alert me when	On by default
A protected policy or app is changed	Yes, immediately
A policy, app or Conditional Access policy is deleted	Yes, immediately
An assignment is removed or widened to All users or All devices	Yes, immediately
A compliance or Endpoint security policy is weakened	Yes, immediately
A directory role is granted (including PIM eligible)	Yes, immediately
A device is wiped, retired or reset	Yes, daily digest
A high-severity anomaly	Yes, immediately
Any other change	No

Each rule goes by email, by webhook (a Teams incoming webhook, a Workflows URL or any URL that takes JSON), or both, immediately or as an hourly or daily digest (daily at 07:00 UTC). An MSP can set defaults for every client tenant; a tenant’s own rule wins. MDO’s own actions don’t raise alerts unless a rule includes them. Send test checks each channel. Rules and channels need the Owner or Admin role.

Admins, Device actions, Autopilot, Approvals

Admins (“People and apps”): each person and app that made changes, with counts of events, changes, deletes and failures, and the Anomalies card.
Device actions: wipe, retire, Fresh start, Autopilot reset, lock, passcode reset, restart, sync, delete and LAPS, with who asked (from the audit log) and the device’s own result.
Autopilot: Autopilot events and duplicate serial numbers.
Approvals: Multi Admin Approval requests with requestor, approver and status.

Anomalies

Each anomaly has a severity and a one-sentence reason:

Pattern	What MDO flags
Volume spike	A day with at least 10 changes and 3 times the daily average of the 60 days before (High at 6 times and 25 changes)
Failure rate	A day with at least 5 changes of which 20% failed (High at 50%)
Off-hours	At least 3 changes in hours a person doesn’t usually work, measured against their own last 60 days (needs 20 changes on 5 days of history)
Rare operation	An operation not seen in the 60 days before (High for a delete, wipe or retire)
New actor	A person or app with changes and none in the 60 days before (High with deletes or wipes)

With less than 14 days of history in MDO, the comparisons with the past are skipped and the card says “Not enough history yet”. MDO’s own actions are scored separately and never count toward the tenant’s anomalies.

Reports

Audit › Reports builds a change report for a period (last 30 days, last quarter or your own dates), areas, people and apps, and sources (Intune, Entra), with MDO’s own actions in or out. The scope line is shown before you generate it and printed at the top. Download as CSV or PDF. Generating and downloading it needs the Owner or Admin role, as does every export of audit history.

Activity

Activity is a record of what people did in MDO for the selected tenant, newest first and grouped by day. Each row says:

when it happened (your local time; UTC on hover);
what happened, as a sentence, for example “Deployed 7-Zip 26.02” or “Invited [email protected] as Viewer”;
who did it;
the object it touched, as a link (an app, policy, user or setting).

A source label shows where the change came from: MDO, or MDO scheduled for a change MDO made on its own. Every sign-in to MDO is recorded too. Changes made in the Intune portal are no longer listed here; they are in Audit › Changes, with who made them.

When VirtualCaffeine staff open your tenant in a support session, they must give a reason, the session expires, and Activity shows a row when it starts, one per area they view (“Dana Reyes, VirtualCaffeine support, viewed Compliance, reason: …”) and one when it ends. You see their name, never their email.

Filter by date range (last 7, 30 or 90 days, 13 months, or your own dates), person, area, object name and source. The filters are part of the page address, so you can share a filtered view.

Click a row to see the before and after values, the job it started, and the request details.

Who can see it: customer admins and technicians can see Activity. Owners and Admins can also Export CSV of the filtered rows.

Audit history and Activity are kept for 13 months. App changes also appear in each app’s History tab (see Editing an app).