Office365 ResourceWatch

The Office365 Resource Watch template collects an inventory of your Microsoft 365 tenant rather than a stream of events: users, groups, devices, registered applications, installed apps and conditional access policies, read periodically from Microsoft Graph and kept on SIEM → Resources.

That makes it the odd one out among the Microsoft integrations, and it is worth being clear about what it is for. An audit log tells you what happened; this tells you what exists. It is what lets a detection resolve an object GUID in an audit record to a person, decide whether the account that just signed in from a new country is enabled, or answer "which applications in this tenant hold that Graph permission" without anyone opening the portal.

Like Office 365 Activity API and Azure AD audit, it is authorised by administrator consent: you supply one administrator's email address and Microsoft asks that administrator to approve a Fluency application that already exists. You never open the Microsoft portal, and the person who finishes the setup may not be you.

The setup has two halves, in the opposite order to most guides:

1. In Fluency — install the Office365 Resource Watch template with an administrator's email address. This sends the approval request.
2. In Microsoft — that administrator reviews the permissions and accepts.

Which of the four Microsoft 365 pages you want

	Office365 Resource Watch (this page)	Office365	Azure Directory Audit	Office365-Audit
Guide	This page	Activity API	Azure AD audit	Office 365 Audit
Collects	Tenant resource inventory	The unified audit log	Entra directory audit	All three
Default authentication	Administrator consent	Administrator consent	Administrator consent	Client secret only
What you supply	An admin's email address	An admin's email address	An admin's email address	Tenant ID, client ID, client secret
Lands in	SIEM → Resources	Index Office365	Index AzureAudit	Both indexes and Resources
Entra application	FluencyOffice365ResourceWatch	Fluency Office365 Event Reader	FluencyAzureADAudit	One you register yourself

Each of the three consent templates is a separate application in Microsoft Entra ID with its own permission set, so consenting to one does not consent to the others. Installing all three means three requests and three approvals.

This is the one template you might not need separately

Office 365 Audit already reads the directory resources this template collects — its catalog description is "Office365 audit event, AzureAD audit and Azure Directory Resources". If you are running that, you are very likely getting this inventory already, and installing Resource Watch alongside it means two applications reading the same objects from Graph on their own schedules.

There is no index collision to warn about, because this template writes to the Resources store rather than to a data-lake index — so nothing will fail. It will just be duplicated work. Check SIEM → Resources before installing: if an Office 365 card is already there and populated, you do not need this.

What arrives

Nothing lands in a data-lake index. The output is a record set on SIEM → Resources, refreshed on a schedule rather than appended to.

Resource type	Contents	Backed by
Users	Display name, account enabled, MFA enabled, user type, created on, roles	Directory.Read.All, UserAuthenticationMethod.Read.All
Groups	Group membership and type	Directory.Read.All
Devices	Registered and joined devices	Directory.Read.All
Applications	Registered applications, with publisher domain, application ID and the permissions each holds	Directory.Read.All
Installed Apps	Applications installed in the tenant	Directory.Read.All
Cond. Access Policies	The tenant's conditional access policies	Policy.Read.All

Checking the refresh cadence on your own install

This template writes to the Resources store rather than to an index — its parameter schema has no datalake or datalake index name field at all. How often it refreshes, how a deleted object is aged out, and which Graph endpoints back each resource type are recorded on the install itself: open the application's details panel with the blue eye button and read its Actions list.

Unlike most templates, this one has no destination to choose

Office365 Resource Watch takes no datalake or datalake index name parameter — the destination is fixed by the template rather than chosen on the form, so there is nothing here to collide with another application. That absence is deliberate, not an omission in this guide.

Before you begin

A Global Administrator or Privileged Role Administrator. This is stricter than the other Microsoft integrations and it is the most common reason this install stalls. Microsoft's rule is:

Privileged Role Administrator, for granting consent for apps requesting any permission, for any API.

Cloud Application Administrator, AI Administrator, or Application Administrator, for granting consent for apps requesting any permission for any API, except Microsoft Graph app roles (application permissions).

This application requests Microsoft Graph application permissions — Read all audit log data and Read all user mailbox settings are both unambiguously the app-only variants of their permissions, since the delegated ones are worded "Read audit log data" and "Read user mailbox settings". That puts it squarely in the exception, so Cloud Application Administrator and Application Administrator are not sufficient. Send the request to a Global Administrator or a Privileged Role Administrator.

No licence gate. Unlike the directory audit, reading directory objects does not need Microsoft Entra ID P1 or P2. Resource Watch works on a Free tenant.

No tenant switch to turn on. Unlike the unified audit log, there is nothing to enable first — the directory is always readable by an application that has been granted the permissions.

The address you supply has to be a working mailbox that the approver reads, because that is where the request lands.

Access to the Fluency portal with permission to install applications.

Part 1 — Fluency

Install the Application

Go to Platform → Applications → Install Application From Template and choose Office365 Resource Watch from the Office Software (SaaS) and IAM category.

Parameter	Notes
Enable Admin Consent Mode?	Checkbox, ticked by default. Leave it ticked for the route this page documents. Unticking it changes the form — see If your tenant will not allow the consent route.
admin email address	The administrator who will be asked to approve. Must be a mailbox they actually read, and must belong to someone who holds one of the roles above.

Those two fields are the whole form. There is no datalake and no datalake index name.

Press Install. The application then appears in the Installed Applications view, where its badge reads Running once the pipeline is up.

Running does not mean working — it means waiting

The badge reflects the pipeline, not the consent. Until the administrator approves in Microsoft, this application is a correctly-built pipeline with nothing to read, and it looks identical to one that is collecting normally. There is no "waiting for approval" state to watch for.

For this template the confirmation is unusually clean, though: a resource roster is never legitimately empty. See Confirm it is running.

If your tenant will not allow the consent route

If your organisation blocks consent to third-party applications, untick Enable Admin Consent Mode — the form replaces the email field with Azure Tenant ID, Azure ClientID and Azure ClientSecret, for an app registration you create and hold yourself.

Build the registration as described in Part 1 of the Office 365 Audit page, granting the Microsoft Graph application permissions listed in Review the request and accept below. Note that going this way means creating and rotating a client secret, and that Office 365 Audit collects these same resources plus two event streams from one registration — so if you are registering an application anyway, that is usually the better destination.

Part 2 — Microsoft

This half is performed by the administrator whose address you entered. Everything below is written for them.

What the administrator receives

Fluency sends a message to that address containing a link to Microsoft's admin consent page for the application. Opening it takes them to login.microsoftonline.com, where they sign in and are shown the permission request.

If the administrator reports nothing arriving

Check spam quarantine first. Reinstalling does not change how the request is delivered.

Review the request and accept

Seven permissions are requested — the widest set of the three consent templates:

Consent screen wording	Permission	What it buys
Read your organization's policies	Policy.Read.All	The Cond. Access Policies resource type.
Read all audit log data	AuditLog.Read.All	Directory audit and sign-in data. See the note below — this is broader than the inventory needs.
Read all usage reports	Reports.Read.All	Per-user and per-service usage counters.
Read all user mailbox settings	MailboxSettings.Read	Mailbox configuration — forwarding rules, delegates, automatic replies.
Read directory data	Directory.Read.All	Users, Groups, Devices, Applications, Installed Apps. The core of what this template produces.
Read all users' authentication methods	UserAuthenticationMethod.Read.All	The MFA Enabled column, and which methods each account has registered.
Sign in and read user profile	User.Read (delegated)	Identifies the signing-in administrator during the consent itself. Not used for collection.

Three checks before accepting:

1. The application is FluencyOffice365ResourceWatch and the publisher is Fluency Corp. If the name or publisher is anything else, stop.
2. The list matches the table above. A consent screen asking for more than this is not this integration.
3. The screen says Review for your organization — that is the tenant-wide grant.

Click Accept. If the administrator clicks Cancel, Microsoft returns AADSTS65004: The resource owner or authorization server denied the request., no grant is created, and nothing on the Fluency side reports it.

Three of these are worth a second thought, and the consent screen is all-or-nothing

Most of the list is inventory metadata. Three entries are not, and an administrator is entitled to weigh them:

• Read all user mailbox settings exposes forwarding rules, delegate access and automatic replies for every mailbox. That is a genuine detection asset — attacker-created forwarding rules are a classic persistence technique, and this is how you inventory them — but it is mailbox configuration for the whole organisation.
• Read all users' authentication methods covers registered phone numbers and Authenticator settings. Microsoft is explicit about the limit: it "does not allow the app to see secret information like passwords, or to sign-in or otherwise use the authentication methods."
• Read all audit log data is the widest permission on the list and it is not obviously needed by a resource inventory. Microsoft does pair the two routinely — "the Directory.Read.All permission is required to retrieve tenant licensing information if it isn't already cached" — but that explains why an audit integration needs Directory.Read.All, not why an inventory needs AuditLog.Read.All. Which part of the roster it backs could not be confirmed against a running installation, so treat it as an unexplained part of the ask rather than a justified one.

You cannot accept six of seven — the consent screen grants all or nothing. If a subset is what your organisation will allow, use the client-secret route, where you choose the permissions yourself and can leave the ones you object to unticked. Expect the resource types they back to be empty or absent in that case.

What the grant is, and what it is not

Once accepted, the grant lives on the tenant rather than on the administrator who approved it:

• It does not expire, and there is no secret to rotate.
• It survives the approver leaving — deactivating the administrator who clicked Accept does not affect collection.
• It is revocable by anyone with the role, from Enterprise applications, without telling Fluency.
• It does not grant a person anything. No Fluency user gains access to your tenant.

Confirm it is running

A resource roster is the strictest health check any integration in this manual offers, because it is never legitimately empty. An event feed on a quiet tenant may have nothing to show; a directory that contains no users does not exist. If the roster is empty, something is wrong.

Open SIEM → Resources (URL path /SIEM/resources). Once the application has run, an Office 365 card appears with one button per resource type it collects:

Click a resource type to open its list at /SIEM/resources/O365/<type>. The list replaces the cards with a record browser: a red Back to Resources button, a Download Resource export, a drop-down for switching resource type within the integration, a Search bar, a faceted filter panel reporting Total Records, and one card per record.

Users is the list worth checking first. It carries Display Name, Account Enabled, MFA Enabled, User Type, Created On, and Roles, with AccountEnabled, Group, and Role facets — an inventory of who is in the tenant, which accounts are enabled, and which lack MFA.

Compare Total Records against the number of accounts you expect. A count that is plausible means consent was granted and collection is working. Applications is the other one to look at on first run — its Permission facet is the fastest way to find every application in the tenant holding a given Graph permission, which is the inventory most tenants have never actually taken.

If a resource type button returns a Resource Load Failed message naming that type, the application has not collected it yet — give the first poll time to complete before treating it as a failure. If every type fails and the card never populates, check the Microsoft side: in the Microsoft Entra admin center, go to Entra ID → Enterprise apps → All applications and search for FluencyOffice365ResourceWatch. If it is not there, consent was never granted.

For the full page reference, see SIEM → Resources.

Maintenance

There is no credential to rotate

No secret expires, so nothing here needs a calendar entry. What can break the integration is someone revoking the consent, so the maintenance task is review rather than rotation.

Reviewing and revoking the grant

From Entra ID → Enterprise apps → All applications → FluencyOffice365ResourceWatch → Permissions → Admin consent, use the ... control on a permission row and select Revoke permission.

The Type column on that tab separates Delegated from Application, which matters here because several of the seven permissions display identical wording for both — Read directory data, Read your organization's policies, Read all usage reports and Read all users' authentication methods are worded the same either way. The consent screen cannot tell you which was granted; this tab can.

Nothing tells Fluency when a grant is revoked. Collection stops and the application keeps reporting Running. Because the roster is refreshed rather than appended to, a revoked grant shows up as an inventory that quietly stops ageing rather than as an empty one — which is harder to notice. If the Created On column has no recent accounts in it, check the grant.

Removing the integration

Uninstall the application in Fluency first, with the red Uninstall button at the foot of its details panel. Then, in Microsoft, delete the enterprise application (Properties → Delete) or revoke its permissions as above.

Troubleshooting

Symptom	Likely cause	Fix
No Office 365 card on SIEM → Resources at all	Consent was never granted, or the first collection has not finished	Search Enterprise applications for FluencyOffice365ResourceWatch. If it is absent, the request was not accepted — resend it.
The administrator sees Need admin approval rather than a consent screen	AADSTS90094 — the account cannot consent to Microsoft Graph application permissions	Cloud Application Administrator is not enough for this template. Have a Global Administrator or Privileged Role Administrator open the same link.
Consent fails with AADSTS65004	The administrator selected Cancel	Send the request again. No grant was created.
The administrator never received anything	Wrong address, or the message was quarantined	Check the address on the install form, then spam quarantine.
One resource type returns Resource Load Failed, the rest are fine	That type has not been collected yet, or its backing permission was not granted	Wait out the first poll. If it persists, check the Admin consent tab for the permission in the What arrives table.
Cond. Access Policies is empty but everything else works	Policy.Read.All was not granted, or the tenant has no policies	Check the Admin consent tab. An empty list is correct for a tenant with no conditional access configured.
MFA Enabled is blank across all users	UserAuthenticationMethod.Read.All was not granted	Consent again with the full set, or grant that permission on your own registration if you are on the client-secret route.
The inventory is populated but stale — recent joiners are missing	The grant was revoked, or the application was deleted	Check Enterprise applications → Permissions → Admin consent. Re-consent if it is gone.
Two Office 365 resource cards, or records that look duplicated	Office365-Audit is also installed and reads the same objects	Expected. Uninstall whichever you do not want; there is no collision, only duplicated work.

Under the hood

Engineering reference — the consent flow and what is read from Graph

How the consent route authenticates

The application Fluency operates is registered as multi-tenant in Fluency's own directory. When the administrator approves, they are sent to Microsoft's admin consent endpoint:

https://login.microsoftonline.com/{tenant}/v2.0/adminconsent
        ?client_id={fluency-client-id}
        &scope=https://graph.microsoft.com/.default
        &redirect_uri={fluency-callback}
        &state={opaque}

Approval produces a redirect carrying admin_consent=True and the tenant GUID, which is why the form never asks for a tenant ID. Collection then uses the client credentials grant against https://graph.microsoft.com/.default.

Two artefacts result and they behave differently: application permissions produce an appRoleAssignment on the service principal, and delegated permissions consented tenant-wide produce an oauth2PermissionGrant with consentType: AllPrincipals. Neither references the approving user's account, which is why the grant outlives them.

What is read

Directory objects come from ordinary Microsoft Graph collections, paginated through @odata.nextLink:

GET https://graph.microsoft.com/v1.0/users
GET https://graph.microsoft.com/v1.0/groups
GET https://graph.microsoft.com/v1.0/devices
GET https://graph.microsoft.com/v1.0/applications
GET https://graph.microsoft.com/v1.0/servicePrincipals
GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
GET https://graph.microsoft.com/v1.0/users/{id}/authentication/methods

The list above is what the granted permissions and the resource types on the card account for. The endpoints and cadence your own install uses are recorded in its Actions list, reached with the blue eye button on the application's details panel.

Catalog observations

Two things distinguish this template from its three siblings in the connector catalog, both visible in its schema:

• It declares no datalake or index parameter, which is why the destination is the Resources store rather than a lake index.
• It declares no resource groups, where Office365 declares Office365, Azure Directory Audit declares AzureAD and Office365-Audit declares Office365. What a template's resource groups drive is outside the scope of this page; the difference is recorded here because it is real and unexplained, not because its consequence is known.

References

Microsoft

• Grant tenant-wide admin consent — which roles can approve, and the Microsoft Graph app-role exception
• Review permissions granted to enterprise applications — reviewing and revoking
• Overview of permissions and consent — delegated versus application permissions
• Admin consent on the Microsoft identity platform — the endpoint and its error responses
• Microsoft Graph permissions reference — the display strings in the table above
• List users and List conditionalAccessPolicies — the directory endpoints

Fluency

• Office 365 Audit — collects these same resources plus two event streams, on a client secret
• Office 365 Activity API and Azure AD audit — the other two consent templates
• SIEM → Resources — the page this integration populates
• Install Application From Template — every template and its parameters
• Microsoft integrations — the rest of this category