Your operations team detects an 18% budget deviation in manufacturing. Not today, but three weeks after it occurred. By then, the damage is already done. This scenario repeats itself in dozens of mid-sized and large companies across LATAM that have Dynamics 365 implemented but have not configured an operational alert system that works in real time. The problem is not the platform: it is that nobody configured the right alerts with the right thresholds.
This article explains, step by step and without filler theory, how to configure Dynamics 365 alerts so that your organization detects operational anomalies before they become crises. From the native Finance & Operations rules to advanced flows with Power Automate, we cover what really works in production.
Why real-time operational monitoring is critical in ERP
An ERP centralizes data from finance, operations, purchasing and logistics. That is exactly its value. But that same volume of data creates a visibility problem: without well-configured alerts, nobody knows when something deviates from the plan until the monthly report confirms it.
In implementation projects we have accompanied at KCP Dynamics, the pattern is consistent: organizations configure the ERP, put it into production and assume the system will “warn” if something goes wrong. It does not do so by default. Automatic alerts in Dynamics 365 are a capability that exists, but one that requires deliberate configuration to be useful. Without that configuration, Dynamics 365 alerts simply do not fire.
The three most frequent anomaly scenarios we see in manufacturing, retail and financial services companies in LATAM are: budget deviations not detected in time, delays in purchase or sales orders that affect customer service, and unauthorized changes to master data such as prices, credit limits or payment terms. Correctly configured Dynamics 365 alerts cover all three scenarios.
To put the problem in perspective: according to Gartner data on operational risk management in ERP, the average detection time for financial anomalies without configured alerts exceeds 18 days in mid-sized organizations. In that interval, an undetected budget deviation can accumulate an impact of between 3% and 8% of the period’s budget, depending on the sector. In manufacturing, where material and labor costs move fast, that margin can represent hundreds of thousands of dollars. Configuring the right Dynamics 365 alerts is not a technical exercise: it is a financial decision. Well-calibrated Dynamics 365 automatic notifications are, in practice, a risk control tool.
The two layers of alerts in Dynamics 365 Finance & Operations
Before configuring any alert, you need to understand the architecture. Dynamics 365 Finance & Operations alerts are articulated in two distinct mechanisms that complement each other.
Native alert rules
Native alert rules are the fastest entry point for operational monitoring. Any user with the appropriate role can create Dynamics 365 alerts directly from the interface, without any development. The system allows monitoring changes in specific fields, creation or deletion of records, and expiration of key dates.
Technically, these Dynamics 365 alerts are processed by two batch jobs that must be active: the one for change-based alerts and the one for due date alerts. The first fires notifications when a field or record changes according to the defined conditions; the second, when a configured deadline is approaching or has passed. If these batch jobs are not scheduled with the correct frequency, alerts will arrive late or not at all. It is the most common configuration error we find in implementation audits.
There is also a little-documented behavior worth knowing: if a field changes twice before the batch job runs, only the final state is processed. According to the official Microsoft documentation on batch processing of alerts, if the field value meets the original condition again before processing, the system may not generate any notification. This has direct implications in high-transaction-frequency environments: the batch job frequency must be aligned with the rate of change of the data you monitor with your Dynamics 365 alerts.
It is also worth knowing the practical limits of native rules: not all F&O entities support alert rules — some system tables or virtual entities are not available as alert sources. Additionally, in sandbox environments the behavior of batch jobs may differ from production in terms of execution frequency and priority, so sandbox tests do not always faithfully reproduce the actual firing times of Dynamics 365 alerts. Finally, although Microsoft does not publish an officially documented limit of rules per user, in implementations with more than 200 simultaneously active rules we have observed degradation in batch job processing times.
Power Automate for advanced logic
Native rules cover simple events. For anomalies that require conditional logic — for example, alerting only if the deviation exceeds 10% AND the absolute amount is greater than 50,000 USD — you need Power Automate. The integration between Dynamics 365 alerts and Power Automate allows building flows that combine multiple conditions, query data from other sources, and send notifications to Teams, email or even external systems.
The practical difference is clear: native Dynamics 365 alert rules are user configuration; Power Automate is process configuration. Both have their place in a well-designed operational monitoring strategy. Combining both layers is the most effective way to leverage Dynamics 365 alerts in complex environments.
Decision tree: native alerts, Power Automate or Azure Monitor
The article describes three notification mechanisms, but the practical question is: which one to use in each situation? The following table summarizes the most relevant decision criteria so you can choose without having to read all of Microsoft’s documentation first.
| Criterion | Native F&O Rules | Power Automate | Azure Monitor |
|---|---|---|---|
| Logic complexity | Low (field changes, date expires) | Medium-high (multiple conditions, cross-data) | Infrastructure (batch job failures, system errors) |
| Who configures it | Business user with appropriate role | Power user or functional consultant | Azure / DevOps administrator |
| License required | Included in D365 F&O | Premium if using D365 F&O connector | Azure subscription (pay-per-use) |
| Response speed | Depends on batch job (minutes) | Near real time (seconds-minutes) | Near real time for platform metrics |
| Typical use case | Master data change, order expiration | Budget deviation with composite threshold, enriched Teams notification | Batch job failure, integration error, performance degradation |
| When NOT to use it? | When logic requires cross conditions or external data | For infrastructure monitoring or system errors | For business logic; has no access to F&O functional entities |
The practical rule we apply in projects: always start with native rules for the simplest and highest-impact events. Add Power Automate when native logic is not sufficient. Incorporate Azure Monitor only if you have a technical team that actively manages the infrastructure. Mixing all three without a clear criterion creates overlaps and blind spots in your Dynamics 365 alert system.
Roles and permissions: what you need before you start
This is the first practical blocker a technical reader encounters and that most guides ignore. If the user does not have the correct privileges in F&O, the “Create custom alert rule” option simply does not appear in the menu, and the diagnosis can consume unnecessary hours.
In Dynamics 365 Finance & Operations, the ability to create alert rules is controlled by the privilege EventCreateAlertRule (or its equivalent depending on the environment version). This privilege is included by default in the duty Maintain alert rules (EventMaintainAlertRules), which in turn is part of standard roles such as System user and functional module roles like Accounts payable manager or Accounts receivable manager. However, in implementations with custom roles — the norm in medium and large projects — this duty may not be assigned, which prevents the user from configuring any type of Dynamics 365 alerts.
The steps to verify and assign access are as follows. First, navigate to System administration → Security → Security roles and locate the affected user’s role. Second, check whether the duty EventMaintainAlertRules is included in the role hierarchy. If it is not, you have two options: add the duty to the existing role (if the scope of that role allows it) or create a complementary role specific to alerts and assign it to the user. The second option is cleaner from an audit perspective, because it allows revoking access to alerts without touching the user’s main functional role.
For the Power Automate context, access to the Dynamics 365 Finance & Operations connector requires the user to have read permissions on the entities the flow queries, in addition to the corresponding Premium license. A flow that fails silently due to missing permissions on the source entity is just as problematic as one that is not configured: the Dynamics 365 alert appears active but does not fire.
Critical prerequisite: verifying the email channel
Before creating your first alert rule, there is a technical prerequisite that the F&O configuration wizard does not mention and that is the second most frequent cause of alerts not arriving: the environment’s email server must be enabled and correctly configured.
In Dynamics 365 Finance & Operations, email notification sending is managed through the System administration → Setup → Email → Email parameters module. There you must verify that the mail provider is configured (SMTP or Exchange Online), that the credentials are valid, and that the server can send test messages correctly. If the send test fails, no alert will arrive by email even if the batch job works perfectly.
The most common problems at this point are three. The first is that the production environment uses Exchange Online but the sandbox environment points to an old or non-existent SMTP server: sandbox tests pass, but in production Dynamics 365 alerts do not arrive. The second is that the credentials of the service account used for sending have expired or been rotated without updating the configuration in F&O. The third is that the D365FO environment domain is not authorized in the organization’s SPF/DKIM policies, causing emails to land in the spam folder or be rejected outright. Before signing off on any Dynamics 365 alert configuration that includes email notification, send a test email from Email parameters and confirm it in the recipient’s mailbox.
How to configure Dynamics 365 alerts: step by step
Here is the concrete process for creating a native alert rule in Dynamics 365 Finance & Operations. We illustrate it with the most requested case: alert for a change in a customer’s credit limit.
- Navigate to the relevant form. In this case, Accounts receivable → Customers → All customers. Select the record you want to monitor.
- Access Options in the action pane and select “Create custom alert rule” within the Share group.
- Define the trigger event. You can choose between value change, record creation, deletion, or date expiration. For the credit limit, select “field value changes”.
- Configure the conditions. Specify the exact field (credit limit) and the threshold: for example, “when the value exceeds 10,000 USD” or simply “when it changes”. Dynamics 365 alerts allow granularity at the individual field level.
- Set the scope. Decide whether the alert applies only to the selected record or to all records of the entity (all customers). For unauthorized change control, the broad scope is more useful in Dynamics 365 alerts.
- Define the notification channel. You can receive the alert within the application (message center) and/or by email. Activate both for critical anomalies.
- Save and verify that the batch jobs are active. Without this, the Dynamics 365 alert rule exists but does not fire.
Batch job troubleshooting: step-by-step diagnosis
The most frequent complaint in Dynamics 365 alert implementations is: “I configured the rule but I am not receiving notifications”. In 80% of cases, the root cause lies in the batch jobs, not in the rule itself. This section gives you the exact diagnostic protocol to resolve that problem in production.
Verifying the status of alert batch jobs
The first step is to confirm that the two alert jobs are active and running. The path is: System administration → Periodic tasks → Alerts. There you will find two entries: “Change-based alerts” and “Due date alerts”. Each must show status Waiting or Executing, never Error or Held.
If you want a consolidated view of all batch jobs in the environment, navigate to System administration → Inquiries → Batch jobs. From there you can filter by name, status or last execution date. A job in “Error” status is not automatically rescheduled: you must review the log, correct the cause and reactivate it manually for Dynamics 365 alerts to work again.
Reading error logs
When a batch job fails, the system records the detail in the history. To access it: select the job in the Batch jobs form → Batch job history button → select the failed execution → Log button. The log shows the error message, the exact time and, in many cases, the stack trace if the failure was code-related.
The most common errors in Dynamics 365 alert batch jobs are three. The first is database timeout: occurs when the volume of records to evaluate is very high and the query exceeds the time limit; the solution is to reduce the scope of the alert rules or increase the execution interval. The second is lock conflict: the job tries to read tables that another process has locked; it is resolved by scheduling the job during lower transactional load periods. The third is transient cloud infrastructure failure: in cloud D365FO environments, the batch server can migrate between SQL pools and the execution fails with a system error; for these cases, Microsoft introduced the BatchRetryable functionality, which allows jobs to automatically retry on transient failures without manual intervention, ensuring the continuity of Dynamics 365 alerts.
Configuring automatic retries and alerts on the batch jobs themselves
There is a governance pattern that few teams implement but that makes a real difference: configuring Dynamics 365 alerts on the alert batch jobs themselves. That is, creating a rule that notifies the system administrator when the alert job ends in error or is cancelled. This closes the loop: if the notification mechanism fails, someone knows immediately.
To do this, go to System administration → Inquiries → Batch jobs, select the alert job, and use the Alerts button to configure a notification when the status changes to “Error” or “Cancelled”. The recipient must be the technical administrator of the environment, not the business user. With this configuration, the system monitors itself and eliminates the most common blind spot in Dynamics 365 alert implementations.
For continuous production manufacturing environments, the batch job frequency benchmark we have validated in LATAM projects is as follows: every 15 minutes for Dynamics 365 alerts on financial master data and credit limits, every 30 minutes for budget deviations, and every hour for inventory monitoring and long-cycle purchase orders. Frequencies below 10 minutes in environments with more than 500 transactions per hour generate database contention without appreciable operational benefit.
Real use cases: which alerts to configure first
Not every anomaly deserves an alert. The most frequent error we see in implementations is not the lack of Dynamics 365 alerts: it is the excess. Teams that receive 40 daily notifications end up ignoring all of them. The discipline of alert design starts by prioritizing the events that truly require immediate action.
Budget deviations
For budget control, the most valuable alert is not “spending changed”, but “spending exceeded the approved threshold”. In Dynamics 365 Finance, budget deviation alerts are configured by combining native budget control rules with event alerts in the General ledger module. The typical flow: when a transaction takes budget consumption above 85% of the approved limit, a notification is triggered to the cost center manager and the CFO. Dynamics 365 budget control alerts are, in many cases, the first ones the finance team needs to activate.
With Power Automate you can go further: compare the accumulated spending of the current month against the same period of the previous year and alert only if the deviation exceeds a configurable percentage. This eliminates Dynamics 365 alerts for “normal spending in peak season” and focuses attention on real deviations.
Purchase and sales order delays
Dynamics 365 due date alerts are perfect for this scenario. Configure a rule that fires a notification 48 hours before the confirmed delivery date if the order status has not advanced to the next milestone. For example: if a purchase order is still in “Confirmed” status when it should be in “Partially received” two days before expiration, the system alerts the buyer and the operations manager.
We applied this pattern with clients in the LATAM retail sector to reduce the impact of stock-outs. The early alert allows managing with the supplier before the problem reaches the point of sale. Dynamics 365 due date alerts on orders are one of the configurations with the highest immediate return in purchasing operations.
Changes to sales prices, payment terms or supplier bank details are vectors of fraud and operational error. Configuring automatic Dynamics 365 alerts on any modification to these fields is a basic internal control measure, not optional. A “field value changes” type alert rule on the price catalog or supplier record, with notification to the compliance officer and the controller, covers this risk with less than 10 minutes of configuration.
Designing an alert strategy without generating noise
The greatest risk of a poorly designed alert system is notification fatigue. When everything is urgent, nothing is. In operational monitoring projects with Dynamics 365 alerts, we apply a three-level framework that has proven to work in production.
| Level | Type of anomaly | Recommended channel | Recipient |
|---|---|---|---|
| Critical | Unauthorized change in financial master data, credit limit exceeded | Email + immediate Teams | CFO, Controller, CTO |
| Operational | Order delay, budget deviation >10% | Email + in-app notification | Operations manager, area manager |
| Informational | New supplier creation, project status change | Daily email digest | Purchasing team, project manager |
The daily digest is the most underestimated tool in managing Dynamics 365 alert notifications. Instead of sending each informational alert in real time, group low-urgency events into a summary that the team reviews once a day. This reduces the perceived volume of notifications without losing visibility. Applying this classification from the start is what differentiates a Dynamics 365 alert system that works from one that the team ends up ignoring.
Integration with Power Automate and Microsoft Teams
Native Dynamics 365 alerts cover basic monitoring. But when you need contextual notifications that include additional data, direct links to the record and action options from within the message itself, integration with Power Automate and Microsoft Teams takes Dynamics 365 alerts to the next level.
A typical production flow works like this: Power Automate listens for changes in a Dynamics 365 entity (for example, the status of a sales order), evaluates configurable conditions (has it gone more than 48 hours without an update?), and sends a message to a Teams channel with the order detail, the affected customer, and two action buttons: “Escalate” and “Mark as handled”. The responsible person acts without leaving Teams. Dynamics 365 alerts integrated with Teams eliminate the need to switch applications to respond.
This pattern reduces response time to anomalies because it eliminates the step of searching for the record in the ERP. The alert brings the context to the user, not the other way around. In manufacturing projects in Mexico and Colombia, we have seen reductions of up to 60% in the resolution time of operational incidents with this approach.
Power Automate licensing: what you need to know before committing
Before designing advanced flows for your Dynamics 365 alerts, it is worth understanding the licensing implications. Not all Power Automate flows have the same cost, and the difference can be relevant to the budget of an operational monitoring project.
The starting point: if your flow only uses standard connectors (Teams, Outlook, SharePoint), it can run under the Microsoft 365 license you already have. The problem appears when you need premium connectors. The Dynamics 365 Finance & Operations connector is a premium connector, which means flows that use it require an additional license. According to official Microsoft documentation, there are two main modalities: the Premium per-user license (each person who creates or runs the flow needs their own license) and the per-flow or per-process license (the flow has its own license independent of the number of users who run it, more suitable for back-end automations).
For automated flows in the Dynamics 365 context — that is, flows that run as part of the application and are associated with it —, the Dynamics 365 license of the flow owner may cover automated execution. But if the flow is independent or run by users without a D365 license, a separate Premium license is required. Always verify with your partner or Microsoft channel the model that applies to your specific architecture before scaling the number of flows in production. This point is especially relevant when the volume of automated Dynamics 365 alerts grows and multiple departments start creating their own flows.
Integration with Power BI: from point event to monitoring dashboard
Configuring individual alerts is the starting point. Operational maturity arrives when those Dynamics 365 alerts form part of a continuous monitoring system that connects point events with trends and patterns. Dynamics 365, combined with Power BI, allows moving from reactive alerts to predictive dashboards.
The maturity flow we apply with our clients has three phases. First, basic native Dynamics 365 alerts for the most critical events: master data changes, key date expirations. Second, Power Automate flows for anomalies with conditional logic and enriched notifications in Teams. Third, Power BI dashboards that consolidate the history of fired Dynamics 365 alerts, their resolution and recurring anomaly patterns.
To connect Power BI with F&O data, the most recommended route is through the Entity Store — the analytical data warehouse integrated in Dynamics 365 — which exposes data in a format optimized for Power BI queries via DirectQuery. For alert monitoring dashboards, the most useful entities are those of General ledger (GeneralLedgerActivities) and Budget (BudgetActivities), which allow building metrics such as accumulated budget consumption, variation versus the previous period and spending velocity by cost center. For high volumes or more complex architectures, Microsoft documents the data entities available for financial performance content in Power BI.
The alert monitoring dashboard we recommend building includes four key metrics: number of alerts fired per week (to detect trends of operational degradation), average time between firing and resolution (to measure team effectiveness), distribution of alerts by module (finance, purchasing, logistics) and recurring alerts without resolution (signal of structural, not point-in-time, problems). This fourth indicator is the most valuable: if the same Dynamics 365 alert fires week after week, the problem is not the alert, it is the underlying process.
This third level is where operational monitoring generates real strategic value. You not only know when something fails: you start to see why it fails regularly and can act on the root cause, not just the symptom. In manufacturing, this can mean identifying that a specific supplier concentrates 70% of order delays. In retail, that budget deviations are concentrated in a specific cost center during the last quarter of the year. Pattern analysis on the history of Dynamics 365 alerts is what converts reactive monitoring into operational intelligence.
Alert governance: who configures what and how it is maintained
A Dynamics 365 alert system without governance degrades quickly. In six months, you will have duplicate rules, recipients who no longer work at the company, and thresholds that nobody remembers why they were set that way. Dynamics 365 alert governance is not a technical issue: it is an organizational responsibility issue.
What works in practice is assigning an “alert owner” per critical process: a person responsible for reviewing quarterly that the thresholds are still relevant, that the recipients are correct, and that the alert is still generating real actions. If a Dynamics 365 alert has been firing for three months without anyone acting, there are two options: adjust the threshold or delete it.
From KCP Dynamics we recommend documenting each Dynamics 365 alert rule in a centralized register that includes: rule name, process it covers, configured threshold, recipients, notification channel, date of last review and owner. This register can live in a SharePoint list or in a Dataverse table integrated with the Dynamics 365 environment itself.
The other critical governance element is access control. Not all users should be able to create Dynamics 365 alerts on any entity. In environments with sensitive financial data, rules on General ledger, Treasury or Payroll modules must be restricted to specific roles and audited periodically. Limiting who can create and modify Dynamics 365 alerts in sensitive modules is just as important as the configuration of the thresholds themselves.
How to export and audit the inventory of existing rules
To do real governance, you first need to know what Dynamics 365 alerts exist in the environment. The native form to consult them is at Options → Alert rules from any form, but it only shows the rules of the user in session. For a consolidated view of all rules in the environment, the path is System administration → Inquiries → Alert rules, where you can filter by user, entity or status and export the result to Excel with the standard F&O export button.
This export is the starting point of the governance exercise: a complete list of active rules, with their owner and their last firing date, allows quickly identifying orphaned rules (whose owner is no longer in the organization), duplicate rules (same event, same recipient, configured by different users) and rules that have never fired (possible configuration error or overly restrictive threshold). Performing this Dynamics 365 alert audit once a quarter, together with the threshold review, is the most profitable governance habit you can install in your team.
Centralized alert register template
For the centralized register to be useful from day one, it needs a minimum structure that any alert owner can fill in and maintain. Below is an example of the recommended columns and a sample row that illustrates how to document a real alert:
| Field | Description | Example |
|---|---|---|
| Rule name | Unique descriptive identifier | ALERT-FIN-001 Customer credit limit change |
| Process covered | Module and business process | Accounts receivable — Credit control |
| Configured threshold | Exact condition that triggers the alert | Field “Credit limit” changes on any customer |
| Recipients | People or roles who receive the notification | Financial controller, Head of credit and collections |
| Notification channel | Email, Teams, in-app message center | Email + immediate Teams |
| Owner | Person responsible for maintaining and reviewing the rule | Ana García — Controller |
| Date of last review | When it was verified that the threshold is still valid | 2024-10-15 |
| Status | Active / Under review / Deactivated | Active |
| Notes | Context, known exceptions or change history | Excludes customers with “Internal” category — reviewed in Q3 2024 |
This register can be maintained in a SharePoint list with metadata columns, which allows filtering by module, owner or pending review date. The key is not the tool where the register lives, but the habit of updating it every time a Dynamics 365 alert is created, modified or deactivated. An outdated register is worse than having no register: it generates false confidence about the actual state of your active Dynamics 365 alerts.
A note on alerts in Dynamics 365 Sales and Customer Service
Everything described so far applies to Dynamics 365 Finance & Operations. If your organization works with Customer Engagement applications — D365 Sales, Customer Service, Field Service or Marketing — the mechanism is different: these apps do not use F&O batch jobs. In that ecosystem, notifications are built primarily with native Power Automate flows, business process flow rules and, in some cases, the third-party Alerts4Dynamics tool for more specific CRM use cases.
If your project combines both worlds — F&O for finance and operations, and D365 Sales for the commercial cycle — the alert strategy must be designed separately for each layer and then integrated into a unified Power BI dashboard. Mixing the alert mechanisms of both platforms without a clear architecture is one of the most frequent sources of inconsistencies in broad-scope Dynamics 365 projects. In these hybrid scenarios, Dynamics 365 alerts from each layer must have clearly differentiated owners and notification channels.
Continuous monitoring: from point alert to sustained operational visibility
Dynamics 365 alerts are the detection layer. Pattern analysis is the intelligence layer. Together, they form an operational monitoring system that turns the ERP into a proactive management tool, not just a historical record. The ultimate goal is not to have more alerts: it is to need fewer, because processes are so well controlled that anomalies are the exception, not the norm.
To get there, the path is what we have described: start with native alerts for the three or four most critical events, ensure that batch jobs work and are monitored, add Power Automate where the logic requires it, build the Power BI dashboard to see patterns, and establish the governance that keeps the system alive over time. Each layer reinforces the next. Well-designed Dynamics 365 alerts are not a one-time project: they are an operational capability that matures over time.
At KCP Dynamics we accompany this process from design to continuous operation. If your organization has Dynamics 365 implemented but alerts are not working as they should, the problem almost always has a concrete technical solution — and it is usually in the batch jobs, permissions or email server configuration, not in the platform.
Frequently asked questions
What is the difference between a native Dynamics 365 alert and a Power Automate flow?
Native Dynamics 365 Finance & Operations alerts allow monitoring field changes, record creation or deletion, and date expirations, directly from the interface without development. They are quick to configure but limited in conditional logic. Power Automate flows allow multiple conditions, queries to other data sources, and enriched notifications in Teams or email with action options. For simple anomalies, native Dynamics 365 alerts are sufficient; for complex logic or contextual notifications, Power Automate is the right tool.
Why are my Dynamics 365 alerts not firing?
The most frequent reason is that the Dynamics 365 alert batch jobs are not active or are not scheduled with the correct frequency. Dynamics 365 Finance & Operations processes alerts through two batch jobs: one for field changes and one for due dates. If these jobs are not running, the alert rules exist in the system but do not generate notifications. Check in System administration → Batch jobs that both are scheduled and active.
How do I avoid notification fatigue in my team?
The key is to design Dynamics 365 alerts with precise thresholds and classify them by urgency level. Critical anomalies (unauthorized changes, financial limit breaches) should be notified in real time by email and Teams. Operational ones (delays, moderate deviations) can go via in-app notification and email. Informational ones should be consolidated into a daily digest, not sent individually. A team that receives 5 actionable Dynamics 365 alerts per day responds better than one that receives 40 mixed notifications.
Can automatic alerts be configured for budget deviations in Dynamics 365?
Yes. Dynamics 365 Finance alerts include native budget controls that can be combined with alert rules to notify when consumption exceeds a defined threshold, for example 85% of the approved budget. For more sophisticated logic, such as comparing current spending against the historical figure for the same period, Power Automate connected to General ledger data is used. The result is a Dynamics 365 alert that distinguishes between normal seasonal spending and a real deviation that requires attention.
Who should manage alert rules in a mid-sized organization?
The most effective approach is to assign an owner per critical process, not centralize everything in IT. The finance manager handles Dynamics 365 alerts for budget and financial master data; the operations manager, those for orders and logistics; the purchasing team, those for suppliers. IT or the Dynamics 365 team sets configuration standards, controls access and performs periodic audits. This distributed model ensures that thresholds are relevant to the business and that someone acts when the Dynamics 365 alert fires.
Sources
- How to Set Up Azure Monitor Alerts for D365 Batch Failures
- Connect Power BI to Dynamics 365 Finance and Operations for advanced ERP analytics | Rand Group
- Financial performance PowerBI.com solution – Finance & Operations | Dynamics 365 | Microsoft Learn
- Dynamics 365 for Operations | Power BI Company Entity Data
- Preguntas frecuentes sobre licencias de Power Platform – Power Platform | Microsoft Learn