Foundational Task: Alerting - Email and Webhooks

You can't secure what you can't see.

This is the single most important principle in managed services — and the one most often overlooked. The Microsoft 365 ecosystem is vast, constantly evolving, and operated by multiple parties. Changes happen every day, and most of them happen silently.

Microsoft 365 does not provide an easy, configurable, unified, real-time change notification system across its services. The native tooling — audit logs, admin center notifications, Message Center posts — is fragmented, delayed, and requires active effort to monitor. Most organisations discover a critical change only when something breaks. By then, the damage is done.

Inforcer closes this gap. The platform's core purpose is to provide context to changes happening across the entire Microsoft 365 platform — not just that something changed, but what changed, when, who made the change, and what the previous value was. That context is surfaced across four core surfaces:

The Automation & Alerting engine is the real-time layer on top of this visibility. It pushes notifications the moment a change is detected — directly to email, Teams channels, or PSA systems — so you don't have to go looking for problems. Problems come to you.

The assumption that only authorized administrators make changes is dangerous. In reality:

I still remember the feeling after setting Inforcer up across a part of our managed portfolio for the first time. I came in the next morning and saw 50+ tenants — every single one — showing a single change that had occurred overnight. After digging in, I discovered that Microsoft had modified the default behaviour in Teams Meeting Policies across the entire M365 platform. No prior warning. No opt-in. Every tenant affected simultaneously.

That was the moment it clicked: it isn't just about accountability within your own organization. It's visibility into defaults being modified by Microsoft themselves.

The Alerting engine is a foundational task — meaning you configure it once, before onboarding your first client, and every tenant you add automatically benefits. This is true economies of scale:

The time invested in setting up alerting pays dividends across every tenant, every day, for as long as you manage them.

Inforcer supports three alert delivery channels, each serving a different operational need:

Each alert can be configured to deliver to one, two, or all three channels simultaneously.

Inforcer provides a library of pre-built alert types that monitor specific aspects of the M365 ecosystem:

📚 Full alert values reference: docs.inforcer.com — Alert Values — list of available template variables, dynamic values, and placeholders for each alert type.

💡 Tip: Start with Policy Change Monitoring and Administrators without MFA — these two alerts alone provide more visibility than most native M365 tooling combined.

Navigate to: Inforcer → Automate (left sidebar) → Alerting

From this page you can:

Each alert shows three delivery configuration icons:

Email is the simplest starting point. Every alert should have at least one email recipient as a baseline.

Enter one or more recipient email addresses. You can add multiple addresses — each will receive a copy of the alert.

The subject line supports template variables that dynamically populate with tenant-specific data. This is critical when managing multiple tenants — without dynamic subjects, every alert email looks the same in your inbox.

Recommended subject format:

Available template variables for subjects:

💡 Tip: Using {{tenant.name}} in the subject means you can create email rules in Outlook to auto-sort alerts by customer — invaluable when managing 20+ tenants.

Inforcer includes a built-in Advanced HTML Editor that provides professionally formatted email templates out of the box. You don't need to write any HTML — just load a template.

Steps:

The template uses Liquid-style template variables (e.g. {{ alert.message }}, {{ tenant.name }}, {% for policy in tracked_changes.policies %}) to dynamically render the alert content. You don't need to edit these — they populate automatically when the alert fires.

Webhooks deliver real-time, richly formatted alert cards directly into Microsoft Teams channels. This is the most operationally impactful delivery method — your team sees changes the moment they happen, in the channels they're already working in.

Inforcer webhook alerts render as structured Adaptive Cards in Teams, showing:

Inforcer provides a curated library of pre-built webhook templates optimised for Microsoft Teams Adaptive Cards. These templates are ready to use and cover common alert scenarios with rich formatting.

📚 Full template library: docs.inforcer.com — Teams Webhook Library

PSA integration automatically creates tickets in your professional services automation platform when alerts fire. This ensures changes don't just get seen — they get tracked, assigned, and resolved.

Inforcer integrates with major MSP PSA platforms including:

Configuration steps vary by PSA platform. Refer to the Inforcer documentation for platform-specific setup guides.

The table below is a suggested starting point — not a rigid requirement. Every environment is different. Use this as a guide to build your initial alerting configuration and expand from there as your operational maturity grows.

💡 Start small, expand later. If you're just getting started, enable Policy Change Monitoring and Administrators without MFA first. These two alone will transform your visibility. Add the rest as you build confidence in the workflow.

When a policy change is detected, the alert includes a detailed change report:

The email alert contains:

The Teams card provides the same information in a compact, scannable format:

Visibility is security. The Alerting engine is not a nice-to-have — it is the foundation that every other security control depends on. A perfectly configured baseline means nothing if someone quietly changes it and nobody notices.