Catalogue › Platform Administration › monitoring

Monitoring

Department

Platform Administration

Stages

Prepare, Operate

Modules

All

Status

reviewed

Copilot Cowork

Platform Administration plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Claude Code

/plugin install platform-administration@d365forge

Licence

CC BY 4.0, by Simon Foote, Robert Peledie

After go-live, the system's reputation depends on the support team finding problems before users do. Dynamics 365 CE fails in quiet ways: a support mailbox stops creating cases, a flow's connection expires, an integration queue backs up, system jobs pile up or capacity creeps towards its limit. None of these puts an error on a user's screen until the damage is done.

Most projects either monitor too little, relying on users to report issues, or too much, sending every alert to a mailbox nobody reads. Good monitoring is a short list of signals, each with an owner and a runbook.

When to use

• Preparing operational readiness before go-live.
• Deciding which signals to alert on and where alerts go.
• Users are reporting failures that monitoring should have caught.
• Reviewing monitoring after a major change, a new integration or a new agent.

Not this skill: support-operations:incident-management for handling incidents once raised, support-operations:support-model for support tiers and hours, customer-service:service-analytics for business service reporting, and solution-architecture:performance-by-design for designing performance problems out.

Questions to ask first

1. Who receives alerts, and during which hours? An alert without a reachable owner is noise.
2. Which business processes are critical enough to need end-to-end checks? These get heartbeat monitoring, not just error logs.
3. Which monitoring tools does the organisation already run (Azure Monitor, a security information and event management tool, an IT service management tool)? Feed existing tools rather than adding another console.
4. Which integrations and automations run unattended? Each needs its own failure signal.
5. What are the log and telemetry retention requirements? These decide where data is kept and for how long; where personal data is involved, check with the organisation's DPO or legal adviser.

Approach

Monitor in layers, from Microsoft's service down to individual business processes, and route each signal to someone who can act on it.

1. Microsoft service. Subscribe the platform team to service health and Message center for the products in use. Message center posts often announce deprecations and behaviour changes well before they take effect.
2. Platform. Watch capacity, API request usage and throttling, environment operations and admin activity through the Power Platform admin center and its analytics, with capacity alerts set well short of limits.
3. Application. Send Dataverse, model-driven app and flow telemetry to Application Insights where supported, checking current Microsoft Learn documentation for what can be exported. Alert on plug-in exceptions, failed or stuck system jobs, flow failures and form performance regressions. Keep plug-in trace logging to exceptions in production.
4. Integration. Monitor dead-letter queues, failed messages and sync lag for each integration, at both the Dataverse end and the other system's end.
5. Business heartbeat. Define simple checks that prove critical processes still work: cases arriving from each support mailbox, server-side sync mailboxes healthy, work orders reaching technicians' devices, leads arriving from marketing forms. A missing heartbeat is often the first sign of a broken connection.
6. Security and audit. Feed audit and activity logs into the organisation's security monitoring, with the scope agreed with the security team.
7. Alert design. Every alert has a threshold, an owner, a severity and a runbook entry. Alerts go to monitored queues, shared channels or the service management tool, never to personal mailboxes. Review alert volumes monthly and retire alerts nobody acts on.

Outputs

• A monitoring catalogue listing signal, source, threshold, owner, severity and runbook link.
• Dashboards for platform health, integrations and business heartbeats.
• Runbook entries handed to support and referenced by the cutover-and-hypercare-checklist.
• Monthly monitoring review notes feeding continuous improvement.

Scale notes

SMB

Start with service health and Message center subscriptions, capacity alerts, flow failure notifications to a shared mailbox or Teams channel, and one heartbeat for each critical inbound channel. That small set catches most real problems. Do not skip naming an owner for each signal.

Enterprise

Integrate telemetry with the enterprise monitoring and service management tools, define severity levels aligned to the support model and run synthetic transactions for key journeys. A platform operations lead owns the catalogue, and hypercare uses the same signals with tighter thresholds.

Hand-offs

support-operations:incident-management handles raised alerts, support-operations:hypercare uses the catalogue during hypercare, and support-operations:continuous-improvement acts on trends. Reviewer sign-off: security-compliance:security-model-review for the scope of audit and security monitoring.

Sources

references/sources.md in this skill lists the outside authorities for the questions here, what each is authoritative for, and what you may do with it. Check the current Microsoft Learn documentation before stating how a feature behaves, because Dynamics 365 changes monthly, and cite what you used.

Never

• Send platform alerts to an individual's mailbox instead of a monitored queue.
• Create an alert with no owner or runbook entry.
• Leave full plug-in trace logging switched on in production.
• Rely on users reporting failures as the main means of detection.
• Ignore Message center notices about deprecations that affect the solution.