Power Automate’s Object-Centric Process Mining Is GA. Your Bottleneck Data Still Needs a Pipeline First.

A finance operations leader reviewing a process mining dashboard showing connected order, invoice, and payment flows

A finance operations director running Dynamics 365 Finance and Operations recently walked into a budget review with a straightforward automation pitch: build Power Automate flows to shorten the order-to-cash cycle. The CFO’s response was less straightforward. Before funding new flows, she wanted proof of where the cycle actually breaks down, not an assumption based on which team complains loudest. That question, where is the process actually stalling and why, is precisely what Microsoft’s object-centric process mining capability in Power Automate was built to answer. It reached general availability on June 5, 2026, and it changes what a process mining exercise can tell a finance or operations leader. It also comes with a data engineering requirement that most teams have not budgeted for yet.

A finance operations leader reviewing a process mining dashboard showing connected order, invoice, and payment flows

Why Case-Centric Process Mining Kept Missing the Real Bottleneck

Power Automate has offered process mining for several years, and Dynamics 365 Supply Chain Management customers on version 10.0.35 and later already have a purpose-built entry point: a warehouse material movement analysis template that reads closed warehouse work records straight out of Dataverse, no custom configuration required. That capability is genuinely useful, and it works because it treats a process as a single, well-defined case, such as one warehouse work order moving through a fixed sequence of steps.

The limitation shows up the moment a process stops being a clean sequence. An order-to-cash cycle is not one case moving through one lane. A single sales order can spawn multiple shipments, each shipment can be tied to more than one invoice, and a payment can settle across several invoices at once. Traditional case-centric mining forces all of that into one case identifier, which means analysts either duplicate events across cases to preserve accuracy, or they flatten the relationships and lose the very dependency that caused the delay. Microsoft’s own framing of the problem is direct: a shipment held up because an unrelated invoice on the same customer account went unpaid is exactly the kind of cross-object dependency that a single-case view cannot represent cleanly. Object-centric process mining, or OCPM, is built to keep orders, invoices, payments, and shipments as separate but linked object types within one process map, so an analyst can see where those flows intersect and where the actual delay originates.

What Object-Centric Process Mining Changes Once It’s Running

The practical difference for a finance or supply chain leader is that root cause analysis stops requiring a manual reconciliation project. Instead of pulling separate reports for orders, accounts receivable, and logistics and asking an analyst to manually trace where they intersect, OCPM keeps those relationships intact in the underlying data model from the start. Microsoft describes the intended outcome as compressing root cause investigations that used to take weeks down to hours, along with the more familiar benefits of shorter cycle times, lower operational cost, and better resource utilization once the actual constraint is identified rather than guessed at.

For a CFO evaluating where to spend the next automation budget, that matters more than it might first appear. A process improvement initiative built on a flattened, case-centric view risks automating the wrong step: speeding up invoice approval, for instance, when the true constraint is a shipment reconciliation process three steps downstream that only becomes visible once orders, invoices, and shipments are analyzed together. Object-centric process mining is designed to surface that kind of hidden dependency before a Power Automate build begins, which is a materially better position than discovering it after a flow has already been deployed and the expected cycle-time improvement doesn’t show up.

An abstract illustration of connected order, invoice, and payment objects intersecting in a process map

The Data Pipeline Nobody Is Budgeting For

Here is the part that tends to get skipped in the pitch. The Dataverse-native warehouse analysis template mentioned earlier works because case-centric process mining can read Dataverse tables directly. Object-centric process mining, as it stands today, does not offer that same direct connection to Dataverse or to Dynamics 365 tables. It ingests data as a CSV file structured according to Microsoft’s object-centric event log, or OCEL, format, stored in either Azure Data Lake Gen2 or OneLake. Fabric Lakehouses with schema support enabled are explicitly not yet supported as a source, which rules out one path some teams might assume would work.

Building that OCEL file is not a trivial export. The mapping step requires at least one activity attribute, at least one start event attribute, and at least two object type attributes, with optional end event, resource, and additional event or object-level attributes layered on for richer analysis. In practice, that means someone, whether an internal analytics team or an implementation partner, needs to design an extraction and transformation process that pulls order, invoice, payment, and shipment events out of Dynamics 365 and Dataverse, aligns them to a shared activity and object model, and lands the result as a correctly structured CSV before OCPM can analyze anything. That is a real data engineering task, and it is separate from, and in addition to, the Power Automate Premium licensing already required to use process mining at all.

What the Licensing Actually Covers

On the cost side, process and task mining are bundled into the Power Automate Premium per-user license, which includes both capabilities along with a starting capacity pool: each licensed user contributes 50 MB toward a shared tenant-wide limit that caps at 100 GB. Organizations that outgrow that pool can add the Power Automate Process Mining add-on, priced at the tenant level, which adds another 100 GB of process mining capacity along with additional Dataverse database and file storage. Customizing the reporting layer against your own Power BI workspace requires a separate Power BI Premium license. None of that licensing changes because a team chooses object-centric analysis over case-centric analysis, which means the incremental cost of adopting OCPM is almost entirely the data pipeline work, not the software itself.

What’s Coming That Should Factor Into Timing

Two features on Microsoft’s own roadmap are worth factoring into a rollout decision rather than treating OCPM as a finished, static capability. Support for exporting object-centric process mining data to a Microsoft Fabric semantic model is planned for August 2026, which would let this data flow into existing Power BI and Fabric reporting rather than staying siloed inside the process mining tool itself. Normalized schema import support for data ingestion, also targeted for August 2026, is intended to ease some of the current data preparation burden, though it has not been detailed in enough depth yet to know how much of the CSV construction work it actually removes. A broader Process Intelligence Studio experience is set to preview in September 2026 and reach general availability the following month, consolidating process mining, task mining, and related analysis into a single workspace. Teams weighing whether to invest in the manual OCEL pipeline now versus waiting a quarter for these dependencies to mature have a legitimate reason to ask that question before committing engineering time.

Where This Leaves a Decision-Maker Today

None of this argues against object-centric process mining. It argues for treating it as what it is: a genuinely more accurate way to see how a multi-object process like order-to-cash or procure-to-pay actually behaves, paired with a data preparation cost that is easy to underestimate when the feature is pitched as simply “available now.” Before funding an OCPM initiative, it is worth confirming which specific cross-object process is causing the most cost or delay, whether that process’s underlying data already exists in a form close to the OCEL structure or will require meaningful transformation work, and whether waiting for the Fabric export and normalized schema import features changes the math on doing this now versus later this year. Routeget Technologies has walked several Dynamics 365 clients through exactly this kind of data readiness assessment before committing to a process mining build, and the pattern holds consistently: the mining tool itself is rarely the bottleneck. The data getting to it is.

#PowerAutomate #ProcessMining #AutomationROI #OrderToCash #DataverseIntegration #PowerPlatform

Dataverse Capacity Got Bigger This Year. Your Storage Governance Still Needs to Catch Up

IT director reviewing a Dataverse storage capacity dashboard showing database, file, and log usage

An IT director we spoke with recently pulled up the Power Platform admin center in January expecting the same tired warning banner about Dataverse capacity that had been sitting there since October. It was gone. Database storage for their Dynamics 365 Finance and Supply Chain Management environment had jumped from 90 GB to 125 GB overnight, with no purchase order, no change request, and no email from their partner. The natural conclusion was that the capacity problem had quietly solved itself. Four months later, the same environment tripped a new kind of alert: a file storage overage notice, even though database usage looked flat. Nothing had been deleted or migrated. The ground underneath the numbers had simply moved.

That is roughly where most Dynamics 365 and Power Platform customers stand right now with Dataverse storage. Microsoft raised default capacity entitlements significantly in December 2025, restructured how that capacity is reported and managed, and then made a second, narrower adjustment in the spring that reclassifies certain metadata between storage types. Individually, each change is well documented. Together, they change what a capacity plan built a year ago actually means, and CIOs and IT directors who treat the December Dataverse capacity increase as a problem solved rather than a system redesigned are going to be surprised by their own admin center in a quarter or two.

What changed in Dataverse capacity this December

The default database capacity increase was substantial and varied by product. Copilot Studio, Power Apps per-app plans, and Power Automate process licenses moved from a 5 GB to a 15 GB baseline. Dynamics 365 CRM applications, including Sales, Customer Service, Field Service, and the Contact Center, moved from 10 GB to 30 GB. Dynamics 365 Customer Insights went from 25 GB to 45 GB. On the ERP side, Standard tier products including Finance, Supply Chain Management, Project Operations, Commerce, and Human Resources rose from 60 GB to 90 GB, while the Premium tier for Finance and Supply Chain Management increased from 90 GB to 125 GB. File storage roughly doubled across most of these same products, though Microsoft did not publish the same level of per-product detail it did for database capacity. Log storage was left untouched.

The more structurally important change sits underneath those numbers. Finance and Operations customers previously managed two separate storage pools: one for the Operations database and one for Dataverse. As of December, those pools merged into a single combined entitlement. For an organization that had been carefully tracking two distinct capacity ceilings, this is not a cosmetic simplification. It changes how consumption trends read, and it means a team that spent the last two years building spreadsheets or Power BI reports to track Operations and Dataverse separately needs to rebuild that tracking around a single number.

Three capacity types, not one

Alongside the entitlement increase, Microsoft has been rolling out a new capacity reporting model that separates Dataverse storage into three distinct types: database, file, and log. This is not universal yet. Organizations still on the legacy model see a single blended capacity figure, while those on the new model get per-type visibility along with a mechanism called cross-capacity-type borrowing. Under that mechanism, unused database capacity can offset a log or file overage, and unused log capacity can offset a file overage, but file capacity cannot offset shortfalls anywhere else. A tenant only registers as officially over capacity after all of that eligible borrowing has already been applied.

Abstract illustration of database, file, and log storage blocks connected by data flow lines representing Dataverse capacity

This matters for budget owners specifically because it changes what an overage notification actually tells you. A file storage warning on an environment that appears to have plenty of headroom in its combined number is not necessarily a sign that the tenant needs more storage overall. It may simply mean the tenant has database or log capacity sitting unused that isn’t automatically flowing to cover the file shortfall, either because the environment hasn’t moved to the new model yet or because the borrowing rules genuinely don’t apply in that direction. Before anyone approves a purchase of additional capacity, it is worth confirming which reporting model the tenant is actually on and whether the specific storage type in the alert is one that borrowing rules can even help with.

The April reclassification nobody budgeted for

In April 2026, Microsoft moved solution-aware tables and related metadata out of database storage and into file storage. Total consumption for an organization does not change as a result of this move, but the split between the two numbers does, and it does so without any corresponding change in what the organization is actually storing. A team that set a database utilization threshold as an internal early-warning trigger, say 70 percent of entitlement, may find that number drop for reasons that have nothing to do with actual data growth, while file utilization climbs for the same non-reason. Anyone reviewing a capacity trend line that spans this period without accounting for the reclassification is going to draw the wrong conclusion about whether their data growth rate is accelerating or slowing down.

Sales Premium customers got a further, separate adjustment in the same window: per-user file storage entitlement doubled from 250 MB to 500 MB, and the underlying tenant base storage figures for those environments moved as well. Microsoft’s own framing for these changes has been candid about the driver: AI-assisted features, Copilot experiences inside Dynamics 365 applications, and the broader push toward agentic workflows all generate metadata, context, and interaction history that traditional transactional storage planning never had to account for. Storage capacity planning built around transaction volume alone is now measuring the wrong thing.

What a capacity plan actually needs to do differently

None of this means the December increase was a bad deal for customers. Bigger entitlements at no additional cost are, on their own terms, a straightforward win, and organizations that were previously purchasing supplemental capacity to cover a gap that the new baseline now closes should go back and cancel or right-size that spending. The mistake is treating a larger number as the end of the exercise rather than the start of a different one.

The more durable response is to rebuild storage governance around the actual mechanics Microsoft has put in place rather than around the old assumption of one number that only ever goes up when you buy more. That starts with confirming, environment by environment, whether the tenant is on the legacy single-figure model or the new three-type model, since the two require genuinely different monitoring approaches. It continues with capturing a clean baseline now, broken out by database, file, and log where that visibility exists, so that the April reclassification and any future ones can be isolated from genuine consumption growth rather than blended into it. It also means understanding the capacity extension option Microsoft makes available once an environment crosses 80 percent utilization: a 45-day window to reduce usage or purchase additional capacity, capped at three extensions in a rolling 365-day period, which is a real safety valve but not one designed to be leaned on indefinitely. And it means deciding, deliberately and in advance rather than reactively during an incident, whether pay-as-you-go billing tied to an Azure subscription is the right overage mechanism for a given environment or whether reallocating from tenant pool capacity is preferable.

For finance and IT leaders who fund these environments, the practical takeaway is that Dataverse storage has moved from a mostly static line item to something closer to a cloud consumption model, with the reporting granularity and billing flexibility that implies, but also the volatility. That is a governance conversation as much as a technical one, and it is worth having before the next reclassification lands rather than after a budget line quietly moves for reasons nobody remembers agreeing to. At Routeget, the engagements that go smoothest are the ones where a client’s storage monitoring gets rebuilt around the new model proactively, rather than the ones where the first real conversation about it happens after an unexpected overage notice.

#Dataverse #DataverseStorage #PowerPlatformLicensing #ITGovernance #DynamicsFinanceOps #CloudCostManagement

Dynamics 365 Autonomous Email Resolution: What to Audit Before September 30

Customer service manager reviewing an automated email triage dashboard in a modern operations center

A support mailbox that receives a few thousand emails a month tends to look the same from the outside no matter what’s actually happening inside it: a queue, a set of SLAs, a team quietly triaging password resets, order-status questions, and return requests alongside the handful of cases that genuinely need a human’s judgment. Most customer service leaders already know which categories in that queue are repetitive enough that a well-trained system could handle them end to end. What changes on September 30, 2026, is that Dynamics 365 Customer Service ships autonomous email resolution, a first-party feature built to do exactly that, and the decision about whether to turn it on now belongs on a CIO’s or VP of customer operations’ desk rather than in a future roadmap conversation.

The feature is called autonomous email resolution, and it is delivered through the Case Management Agent that Microsoft has been building out across the last several release waves. Microsoft’s own message center announcement, MC1465523, confirms the general availability date and describes the capability plainly: it analyzes an incoming email, identifies the customer’s intent, checks whether the knowledge and actions needed to resolve it are actually available, and then either sends a resolution, asks a clarifying question, or hands the email off as a fully-contexted case for a person to finish. That last part matters as much as the automation itself. Nothing here is pitched as replacing a support team; it is pitched as removing the portion of the queue that never needed a person’s attention in the first place.

Abstract illustration of an AI agent autonomously processing and resolving an email through a neural network

What autonomous email resolution actually ships on September 30

Reading the feature closely is worth the ten minutes it takes, because the mechanics determine how much control an organization actually retains. Configuration happens in the Copilot Service admin center, under email settings, where an administrator turns on email resolution and then, critically, sets a deployment status separately for each line of business. That per-line-of-business control is the real governance lever here: a line handling password resets or shipping status can be configured for fully autonomous resolution on day one, while a line handling billing disputes or account cancellations can be left in a draft-only mode where the system prepares a response but a representative still reviews and sends it. Nothing forces an all-or-nothing rollout, and organizations that treat this as a binary on/off switch are already making the decision harder than it needs to be.

The dependency chain behind the feature is longer than a single toggle suggests, and each link is worth confirming before a rollout date gets put on a calendar. Email resolution depends on the Customer Intent Agent being configured first, since that agent is what actually identifies what a customer is asking for. It depends on the Case Management Agent’s own guided setup being complete. For the fully autonomous path, where the system sends outbound email without a person in the loop, Microsoft requires a dedicated application user and a shared mailbox set up specifically for that flow, which is a reasonable security boundary but one that needs its own review: whoever owns identity and access management should know that a service account now has standing permission to send customer-facing email on the organization’s behalf.

One constraint is easy to miss and expensive to discover after the fact. Each email resolution configuration supports a single language. An organization running support across English, French, and Spanish mailboxes isn’t looking at one feature toggle; it’s looking at three separate configurations, each requiring its own line-of-business mapping and its own review cycle. That’s not a reason to avoid the feature, but it is a reason to scope the rollout by language and region from the start rather than discovering the limitation mid-deployment.

The billing question worth asking before the license conversation

Here is where the fine print earns its place in this article. Microsoft’s broader Dynamics 365 Customer Service pricing already establishes how most AI agent capabilities get paid for: Professional and Enterprise tier customers consume Copilot Credits, purchased separately from the base per-user license, while the Premium tier bundles in a base allocation of included capacity. That’s the billing model most IT and finance leaders have already built into their Copilot budgeting conversations over the past year.

Autonomous email resolution’s own documentation adds a second billing surface to that picture rather than simply drawing down the same Copilot Credit pool. Microsoft’s configuration guidance lists, as an explicit prerequisite, the Power Platform pay-as-you-go plan, which requires an Azure subscription attached to the environment specifically so the system can charge for agent runs on a consumption basis. In practice, that means a team that has already provisioned Copilot Credits for Case Management Agent’s classification and quality-evaluation capabilities can still be blocked from turning on autonomous email resolution until someone also attaches a billable Azure subscription to the Power Platform environment and enables the pay-as-you-go plan there. Those are two different procurement conversations, often owned by two different teams: one usually sits with the Dynamics 365 or Copilot licensing owner, and the other sits with whoever manages the organization’s Azure subscriptions and cost centers.

This is not a reason for alarm, and it is worth saying plainly that consumption-based billing tied to actual agent runs can be the more sensible model for a capability like this one, since cost then tracks usage rather than seat count. But it is exactly the kind of dependency that gets missed when a rollout gets planned purely as a licensing tier upgrade. The practical fix is straightforward: before scheduling a pilot, confirm that data movement for Copilot and generative AI features is enabled in the Power Platform admin center for the target environment, and confirm separately that an Azure subscription is attached and the pay-as-you-go plan is active, rather than assuming an existing Enterprise or Premium Customer Service license already covers it.

Governance gaps worth planning around, not waiting on

Microsoft’s own documentation, as of this writing, does not publish a specific confidence threshold or scoring mechanism that determines when the system resolves an email autonomously versus escalating it. That is a legitimate gap for governance teams to plan around rather than a reason to delay indefinitely. The practical response is the same one that has worked for every other agentic capability Microsoft has shipped into this product line over the past year: run the feature in its production-ready preview mode against a narrow, well-understood line of business first, watch what it actually resolves versus escalates over a few weeks of real volume, and only then widen the automation level or add a second line of business. Treat the per-line-of-business deployment status setting as the real control surface, since Microsoft has not given administrators a separate dial to tune model confidence directly.

It’s also worth having someone on the compliance or risk side confirm that autonomously sent customer emails, generated from enterprise knowledge and business instructions rather than drafted by a person, fit within existing customer communication policies and any regulatory obligations specific to the industry. A financial services or healthcare organization will likely want a longer review cycle here than a retailer fielding order-status questions, and that difference should shape the rollout timeline more than the September 30 GA date does.

What decision-makers should do this month

The practical sequence for a customer service or IT leader evaluating this feature ahead of GA looks like this: identify one or two lines of business with high email volume and genuinely repetitive, low-risk request types, since these are the best pilot candidates regardless of how quickly the organization intends to expand the feature afterward. Confirm the billing prerequisites on both sides, Copilot Credits and the Power Platform pay-as-you-go plan with an attached Azure subscription, well before the pilot’s target start date, since provisioning an Azure subscription and getting it approved through procurement can take longer than the feature configuration itself. Assign clear ownership of the application user and shared mailbox that the autonomous flow depends on, treating that account with the same access review rigor as any other service identity with outbound communication permissions. And build in a deliberate review checkpoint, perhaps two to four weeks into the pilot, before extending the automation level beyond draft-only for any additional line of business.

Routeget Technologies has walked several clients through exactly this kind of staged agentic rollout across the Dynamics 365 Customer Service and Field Service product lines over the past year, and the pattern holds consistently: the technology tends to work about as well as Microsoft describes it, and the actual project risk sits almost entirely in governance sequencing and billing setup rather than in the AI itself. Getting those two things right before September 30 is a smaller lift than it looks, and it is considerably smaller than untangling them after a line of business has already gone live on autopilot.

#AutonomousEmailResolution #CaseManagementAgent #DynamicsCustomerService #CopilotCredits #CustomerServiceAI #AIGovernance

Power Apps Component Libraries vs. Code Components: Choosing a Reuse Strategy That Holds Up

Solution architect reviewing multiple Power Apps interface mockups on a monitor, representing component reuse across canvas apps

A Power Apps center of excellence at a mid-size manufacturer recently discovered that its “shared” approval banner control existed in eleven slightly different versions across eleven canvas apps. Every app maker had pulled the component in at some point, tweaked a color or a label to fit their screen, and moved on. When a compliance requirement forced a wording change across all of them, nobody could say with confidence which apps were actually running the current version without opening each one and checking manually. The team had built a Power Apps component library specifically to prevent this. It didn’t, because nobody on the team understood how a component library actually propagates changes.

That gap between what makers assume Power Apps component libraries do and what they actually do is one of the more expensive misunderstandings in a growing Power Apps estate, and it only gets worse as the number of apps and makers increases. Solution architects planning a reuse strategy have two real options inside the platform: canvas component libraries, the no-code mechanism most makers reach for first, and code components built on the Power Apps component framework (PCF), which have been usable inside canvas apps since general availability in June 2021 but remain underused outside professional development teams. Picking between them, or more realistically deciding where each one belongs, requires understanding a few mechanics that the tooling doesn’t make obvious at first glance.

Power Apps component libraries copy, they don’t link

The detail that trips up most teams is this: when a canvas app imports a component from a library, Power Apps copies that component’s full definition into the app itself. The app becomes, in Microsoft’s own terminology, self-contained with respect to that component. There is no live reference back to the library sitting in Dataverse. This is a deliberate design choice that lets an app keep functioning even if it’s exported to an environment where the source library doesn’t exist, but it means updates are never automatic.

When a library owner publishes a change, consuming apps get a notification the next time a maker opens that app for editing, or a maker can proactively check for updates from the Insert pane. Either way, someone has to look at the diff, decide to accept it, and republish the app. Skip that step across even a handful of apps and you end up exactly where the manufacturer above did: a library that is current, and a fleet of apps that quietly are not.

Abstract illustration of glowing modular panel blocks assembling together, representing reusable Power Apps components

A few structural details make this worse if they’re not planned for early. Microsoft’s own guidance caps component libraries at roughly twenty components for performance reasons, which means a library that grows organically without a naming or grouping convention eventually has to be split, and that split itself becomes a migration project. If a maker edits a library-sourced component directly inside an app instead of going back to the library, that action silently breaks the link and creates a local, permanently divergent copy, though the dependency reference stays visible in the Insert pane, which makes it look connected when it isn’t. And library components carry a managed property called “Allow customizations.” When it’s turned off in a target environment, nobody downstream can adjust the component locally at all, which is often the right call for a governed control but needs to be a conscious decision, not a default nobody reviewed.

Where solution export makes this a governance problem, not just a hygiene one

Application lifecycle management adds another layer that’s easy to miss if a team is exporting solutions on a schedule rather than reviewing them individually. Solution export always packages the latest published version of the component library, regardless of which version any given consuming app has actually accepted. That means the correct sequence is to update every dependent app to the current component version first, then export. Do it backward, and you can ship a solution where the library and the apps inside it are on different versions of the same control, which typically surfaces as a subtle visual or behavioral inconsistency rather than an outright error.

There’s also a one-time synchronization quirk worth knowing before a first deployment: when an app and its library move to a target environment together, Power Apps treats them as synchronized at that moment and won’t prompt for updates again until the library is reimported with a newer version. Teams that assume update notifications will keep working the same way in production as they did in the maker’s development environment are often surprised when that stops happening. And because Dataverse tracks the dependency relationship, a library can’t be deleted while any app still references it, and a missing library in a solution import produces a hard failure rather than a warning, which is a reasonable safety net but one that catches teams off guard when they’ve assumed a component library is just another kind of shared file.

What code components are actually for

Power Apps component framework code components sit at a different point on the build-versus-govern spectrum. A system administrator has to explicitly enable the Power Apps component framework for canvas apps at the environment level before any maker can use one, which is itself a useful governance checkpoint that a canvas component library doesn’t have. Building one requires the Power Platform CLI and TypeScript rather than the canvas designer, and the finished component gets packaged into a Dataverse solution and imported like any other managed asset, which puts it squarely inside standard ALM pipelines instead of the copy-and-notify model described above.

The tradeoff is real, not cosmetic. Code components running inside canvas apps can’t call the Dataverse Web API directly, and they can’t implement custom authentication; both of those have to be handled through connectors instead, which rules out certain integration patterns that would be straightforward in a model-driven app. Microsoft’s documentation is also direct about the security posture: because a code component is executable code with access to the same context and tokens as the app around it, the platform surfaces an explicit warning when someone imports one, and the stated guidance is to treat unfamiliar components the way you’d treat any third-party dependency, which is to say, review it before it goes anywhere near a production environment.

A workable split, not a single winner

None of this argues for abandoning component libraries in favor of code components, or the reverse. The two mechanisms are suited to different kinds of reuse, and the architects who get the most value out of Power Apps treat the choice as a deliberate design decision rather than whichever option the maker who built the first version happened to know.

Component libraries are the right tool for UI patterns that app teams themselves need to iterate on: a standard header, a status badge, a form validation pattern that will keep evolving as business rules change. The update-and-review workflow is a feature here, not a bug, because it gives each app team a checkpoint before absorbing a change, provided someone actually owns checking for updates on a schedule rather than leaving it to chance. Code components are the better fit for controls that need to be built once, security-reviewed once, and then distributed as a locked, vetted building block: a specialized data visualization, a control that needs rendering performance a canvas formula can’t deliver, or anything a center of excellence wants to hand out without giving every consuming team edit access to the internals.

The practical starting point for a team building either strategy is small: split libraries along functional lines before they approach the twenty-component ceiling, require a version note on every publish so consumers can judge a change before accepting it, and add a step to the solution export checklist that confirms every dependent app has actually synced to the latest component version. For code components, route imports through whatever center of excellence review process already governs custom connectors, since the risk profile is similar. None of this is complicated once it’s written down, which is precisely why it’s worth writing down before the first inconsistent approval banner shows up in an audit, rather than after. Routeget Technologies has helped several clients untangle exactly this kind of fragmented reuse setup during broader Power Platform governance engagements, and the fix is almost always process, not a missing feature.

#PowerApps #ComponentLibraries #PowerAppsComponentFramework #ALMGovernance #LowCodeGovernance #CanvasAppArchitecture

Direct Lake Semantic Models for Dynamics 365 F&O Data

BI developer reviewing a Direct Lake semantic model diagram for Dynamics 365 F&O data on a widescreen monitor

A BI developer at a manufacturing client rebuilt their Dynamics 365 Finance and Operations reporting as a Direct Lake semantic model the week Fast Fabric rolled out, expecting the same near-instant refresh everyone had been promised in the release notes. For the first ten days it worked exactly that way: framing updates that used to take an overnight BYOD job finished in seconds, and finance users watched inventory valuation numbers move in something close to real time. Then a month-end load pushed one fact table past a few hundred million rows, a refresh failed outright with no warning beyond a guardrail error code, and the model sat unqueryable until someone tracked down which table had tripped which limit. Nothing about Direct Lake had changed. What changed was that nobody had modeled for its ceilings before the data volume found them.

That gap between “Direct Lake is fast” and “Direct Lake behaves differently enough from Import mode that it needs its own design discipline” is where most F&O teams get tripped up right now. Fast Fabric has genuinely solved the latency problem that made near-real-time F&O reporting impractical for years, cutting sync times that used to run one to two hours down to under fifteen minutes in most observed cases, according to Microsoft’s own Dataverse and Fabric integration update. But building a semantic model on top of that faster pipe is a different exercise than plugging Power BI into a data warehouse, and the differences matter most exactly when a model is otherwise working well enough that nobody is looking closely at it.

BI developer reviewing a Direct Lake semantic model diagram for Dynamics 365 F&O data on a widescreen monitor

What actually lands in OneLake now

F&O data doesn’t write to OneLake directly. It flows through Dataverse, which is the layer that transforms F&O table data into Delta Parquet and exposes it to Fabric through shortcuts and mirroring, without the customer managing any Spark compute or Azure infrastructure themselves. That’s the architectural distinction from the older Synapse Link pattern, where a customer’s own Spark jobs did the transformation. Fast Fabric, now in public preview with global rollout completed and an automatic upgrade for existing customers planned for the first quarter of 2026, is what tightened the sync cadence on that same Dataverse-to-OneLake pipeline. Anyone still comparing today’s F&O-to-Fabric numbers against the old BYOD or Data Export Service benchmarks is working from a stale mental model of what the pipeline can do.

The practical consequence for a solution architect is that F&O tables show up in a Fabric lakehouse as Delta tables with a Dataverse-flavored schema underneath them: GUID-based keys, some binary columns, and complex types that don’t map cleanly onto every Direct Lake data type. That schema inheritance is the first thing worth checking before any modeling work starts, not after a refresh fails.

Choosing a Direct Lake semantic model: OneLake or the SQL analytics endpoint

Fabric currently gives two ways to put a semantic model directly on top of those Delta tables, and the choice isn’t cosmetic. Direct Lake on the SQL analytics endpoint reads through the lakehouse or warehouse’s SQL layer, supports non-materialized views, and, critically, falls back to DirectQuery automatically when a table can’t load in Direct Lake mode, for example when SQL-based row-level security is enforced. Direct Lake on OneLake skips that SQL layer and reads Delta tables directly from any Fabric source, which unlocks composite models that mix Direct Lake with Import or DirectQuery tables, calculated tables, and calculated columns (both still in preview and, for calculated columns, limited to user-context evaluation). The tradeoff is that Direct Lake on OneLake has no fallback path at all. If a query exceeds a guardrail, it fails. There is no quietly-slower DirectQuery safety net to catch it.

For most F&O reporting models, that argues for a specific default: use Direct Lake on OneLake when the model genuinely needs composite modeling or calculated tables over F&O data, and reach for Direct Lake on the SQL analytics endpoint when the model is closer to a straightforward reporting layer where a DirectQuery fallback is worth more than the extra flexibility. Architects who pick OneLake mode by default because it’s the newer, more capable option often find out about the missing fallback during a production incident rather than during design review.

Framing, transcoding, and what a guardrail failure actually costs

Direct Lake’s refresh model is fundamentally different from Import, and it’s worth explaining precisely because the difference is what makes the failure mode above so disruptive. A traditional refresh in Import mode copies the underlying data. Direct Lake framing copies only metadata: it analyzes the latest Delta table version, points the model’s references at the current files in OneLake, and finishes in seconds rather than minutes or hours. Data itself loads column by column, and only the columns a given query actually touches, through a process Microsoft calls transcoding. That’s what lets a Direct Lake model handle data volumes larger than a capacity’s memory ceiling; it never has to hold all of it at once.

Abstract visualization of real-time data synchronization from Dynamics 365 F&O into Microsoft Fabric OneLake

Capacity guardrails are what set the boundaries on this, and they scale meaningfully by Fabric SKU. An F2 through F8 capacity caps out at 1,000 Parquet files and 1,000 row groups per table, 300 million rows, and a 10 GB model size limit. Step up to F64 or above and those ceilings jump to 5,000 files, 5,000 row groups, and 1.5 billion rows, with model size effectively unlimited. A large F&O fact table, general ledger transactions or inventory movements on an enterprise instance, can realistically approach those lower-tier limits, which means the F-SKU a Fabric workspace runs on isn’t just a cost decision anymore. It’s a modeling constraint that should be checked against actual F&O table row counts before a Direct Lake model design gets finalized, not discovered when a guardrail breach takes the model offline.

The newer Manage Tables capability, now in public preview for existing Fabric links, gives architects a lever here that didn’t exist a year ago: selecting which F&O-sourced tables actually sync to Fabric, rather than replicating an entire dataset and hoping guardrails hold. Narrowing the synced table set to what a given semantic model actually needs is one of the more direct ways to keep a Direct Lake model inside its capacity’s guardrails without upgrading the SKU.

Data type conversions worth doing before, not after, deployment

Direct Lake doesn’t support every Delta data type. Complex Delta types, binary fields, and GUID columns need to be converted, typically to strings, before a Direct Lake model can use them cleanly. Because F&O data reaches OneLake through Dataverse’s schema, GUID-based surrogate keys and occasional binary fields show up more often than they would in a purpose-built warehouse schema, so this conversion step tends to hit F&O-sourced models harder than it hits models built from cleaner, purpose-designed lakehouse tables. Handling these conversions in a lakehouse notebook or a Fabric pipeline before the semantic model is built, rather than discovering the unsupported type at model creation time, avoids a rebuild cycle that’s easy to skip when a project is already behind schedule.

A few other constraints round out the pre-deployment checklist: Direct Lake has no gateway support, so on-premises data can’t participate directly; the semantic model’s workspace has to sit in the same region as the data source workspace; and Direct Lake isn’t available in personal workspaces at all. None of these are exotic edge cases for an enterprise F&O deployment, but each is the kind of thing that’s far cheaper to confirm during architecture review than to discover during a go-live weekend.

Building for the ceiling, not just the average day

Fast Fabric removed the latency excuse that used to justify slower, batch-oriented F&O reporting architectures, and that’s a real and welcome change. But a semantic model designed only against yesterday’s data volumes, without a look at capacity guardrails, fallback behavior, and the schema quirks Dataverse introduces, is a model that works fine until the month it doesn’t. Routeget Technologies has walked several clients through exactly this kind of pre-deployment guardrail check on F&O Direct Lake models, and the pattern holds: the projects that skip it don’t usually fail on day one. They fail on the first month-end close that actually stresses the numbers the design assumed would stay small.

#DirectLake #MicrosoftFabric #DynamicsFinanceOps #PowerBI #DataModeling #FabricGuardrails

Sales Opportunity Agent Risk Criteria: A Configuration Guide

Sales professional reviewing a CRM opportunity pipeline dashboard with risk indicators on a widescreen monitor

A sales operations director at a mid-size distributor recently asked a reasonable question during a forecast review: why had the Sales Opportunity Agent flagged a deal with a signed letter of intent and an engaged economic buyer as high risk, while waving through a deal where the primary contact had gone silent for three weeks? The answer, once the architect behind the deployment dug into it, was that the agent’s risk model was still running on Microsoft’s default predictive scoring fields: stage velocity, close date slippage, historical win rate by deal size. None of those fields knew that this particular buyer’s procurement team always goes quiet right before signature, or that a champion’s sudden silence after a reorg announcement is the real warning sign in this account base. That gap between what a generic model measures and what an experienced seller actually watches for is precisely what Microsoft’s August 30, 2026 update to Sales Opportunity Agent risk criteria was built to close, and it changes what a technical rollout of this agent actually involves.

Until that update, configuring risk assessment in the agent meant choosing which existing Dynamics 365 fields fed the predictive opportunity scoring model and adjusting a handful of thresholds. Useful, but rigid. Now admins can add a custom risk criterion by describing it in plain language, and the agent layers that instruction on top of its default scoring rather than replacing it. For a solution architect or D365 CE technical consultant planning a rollout, that single change reshapes several downstream decisions: how selection criteria should be scoped, how many agent instances to run, and how much validation work happens before anyone trusts the output.

Sales professional reviewing a CRM opportunity pipeline dashboard with risk indicators on a widescreen monitor

What the Sales Opportunity Agent Risk Criteria Actually Do

The agent’s baseline risk assessment draws on the predictive opportunity scoring machine learning model already present in Dynamics 365 Sales. If that model isn’t configured in your environment, the agent triggers its setup automatically the first time it runs, which is worth knowing up front since it introduces a delay that has nothing to do with your own configuration work. On top of that baseline, the risk configuration section (found under Guidance in the agent’s settings page) now exposes an “Add a custom risk” option. Rather than mapping a field to a threshold, you write a description of the business condition you want flagged, and the agent interprets it against the data it has access to.

This is a meaningful departure from how most Dynamics 365 configuration has historically worked, where a business rule or classic workflow condition had to be expressed as an explicit field comparison. A natural-language risk criterion is closer to writing a prompt than writing a rule, which means two architects describing the same business concern could produce criteria that behave slightly differently depending on wording. That is not a flaw so much as a tradeoff: you gain the ability to capture tacit sales knowledge that was never going to get modeled as a formal Dataverse field, at the cost of the deterministic testability you’d expect from a traditional business rule.

Selection Criteria Come First, and They Are Easy to Get Wrong

Before any risk criterion runs, selection criteria decide which opportunities the agent even looks at. This is configured as a named segment (for example, “Enterprise renewals”) with filter conditions such as rating, estimated revenue, and status, plus an optional look-back period for including opportunities created before the agent was activated. Skip the look-back setting and the agent only considers opportunities created after activation, which catches teams off guard when historical pipeline doesn’t show up in the first few days.

The common mistake here is scoping selection criteria too broadly, on the theory that wider coverage means more value. In practice, loose criteria just mean the agent spends its processing cycles researching deals that were never going to close, competing for the same shared capacity pool as the opportunities you actually care about. A tighter starting point, something like status equals open, status reason equals in progress, and a revenue floor that reflects what “worth researching” means for your sales org, produces better signal and leaves headroom if you later add more segments.

It also helps to understand how the agent prioritizes work once multiple opportunities qualify, since this determines what gets attention first when capacity is constrained. The agent scores queued opportunities using several factors in order: estimated revenue, estimated close date, how recently the opportunity was researched, recent email activity, predictive win-rate score (lower scores get prioritized, since they need more attention), and whether a seller manually requested a refresh. That ordering matters operationally. A high-value deal with a distant close date will generally get processed before a smaller deal closing sooner, so if your sales leadership expects near-term renewals to surface first, you may need a separate agent instance scoped specifically to that segment rather than relying on the shared queue to sort it out.

Writing a Risk Criterion That Actually Earns Its Place

The temptation with natural-language configuration is to restate what the default model already covers, just in different words. That adds noise without adding insight. A custom risk criterion is worth configuring when it encodes something a seller already watches for informally but that no existing field captures well. A few examples that hold up in practice: flagging an opportunity when the primary contact’s job title has changed within the last 30 days, since a champion move is a known risk signal that stage and close-date fields won’t surface; flagging deals in a late stage with no email activity logged in the past two weeks, which tends to catch stalled deals before they slip a quarter; or flagging opportunities where a competitor’s name appears in recent email or meeting notes captured by the agent’s research, which surfaces competitive displacement risk earlier than a rep might think to log it manually.

Close-up of a laptop screen showing an abstract sales pipeline funnel visualization with risk-flag markers on deal nodes

Because these criteria are interpreted rather than evaluated against a strict rule, validate them the same way you’d validate any new logic before trusting it at scale. Use the Preview option in the selection criteria screen to check a representative sample, but treat that preview as directional rather than exhaustive, and cross-check with Advanced Find or a saved view before assuming the criterion behaves the way you intended. Configuration changes also don’t take effect until you explicitly apply them, and the agent only reprocesses on its configured refresh cadence of three, seven, or fourteen days, so budget a full cycle before concluding a criterion isn’t working.

Multiple Instances, One Shared Capacity Pool

Organizations can run up to ten active agent instances at once, each with its own profile, selection criteria, and knowledge sources, which is the mechanism for applying different risk logic to different parts of the business, say, enterprise deals versus transactional ones, without cramming every condition into a single configuration. The catch is that all instances draw from one shared Copilot Studio knowledge base and one shared capacity pool, so heavier use by one instance can slow research for another. If two instances’ selection criteria overlap, the instance with the earlier start time claims the opportunity, and that ownership sticks for the opportunity’s lifecycle. There’s no warning when criteria overlap, which means the discipline has to come from how you design segments up front rather than from anything the platform will catch for you.

The simplified admin configuration that reached general availability on June 30, 2026 helps here by offering guided setup with sensible defaults and a basic-versus-advanced configuration split, so a first instance can go live quickly and pick up custom risk criteria and finer-grained settings later. That’s a genuine improvement for getting started, but it doesn’t remove the need to plan selection criteria deliberately before adding a second or third instance, since the underlying shared-capacity constraints don’t change.

Getting Useful Signal Out of the Rollout

The August GA of custom risk criteria removes a real excuse that architects have had for a while: that the agent’s risk model didn’t understand the specific patterns of a given sales motion. It now can, provided someone takes the time to write criteria that reflect what sales leadership actually raises in forecast calls rather than restating stage and close date in prose. The work that remains is the same discipline any configuration project needs: scope selection criteria narrowly, verify with independent tools rather than trusting the preview alone, and treat a natural-language rule with the same scrutiny you’d give a workflow condition, because it is making decisions about what gets a seller’s attention.

Routeget Technologies has walked a handful of clients through standing up their first Sales Opportunity Agent instances this year, and the pattern that works best is starting with one tightly scoped segment, letting it run a few refresh cycles, and only then drafting custom risk criteria based on what actually surprised the sales team about the default output. That sequencing avoids the common failure mode of over-engineering risk logic before anyone has seen how the baseline model behaves against real pipeline.

#SalesOpportunityAgent #Dynamics365Sales #CRMConfiguration #OpportunityManagement #SalesAIAgents #CustomerEngagement

Power Automate’s Self-Healing Desktop Flows: What Gets Fixed, and What Still Breaks

IT operations engineer monitoring automated workflow dashboards on multiple monitors

A desktop flow that has run clean for eight months can start failing on a Tuesday morning for reasons that have nothing to do with the flow itself. A vendor portal repaints its login page during a routine update, a button that used to sit at a fixed set of pixel coordinates shifts three rows down, and the automation that finance has relied on for month-end reconciliation throws “Element not found” at 6 a.m. with nobody watching. This is the specific kind of fragility that Power Automate’s newly introduced self-healing desktop flows capability is built to reduce, and it is worth understanding precisely what the feature does before assuming it solves a problem it was never designed to solve.

IT operations engineer monitoring automated workflow dashboards on multiple monitors

Why UI Automation Breaks in the First Place

Desktop flows built around UI and browser automation actions work by capturing a selector, essentially a description of where an element lives inside an application’s structure, and replaying that description at runtime to find the same button, field, or menu again. That approach has always been reliable right up until the moment it isn’t. A web app ships a design refresh. A desktop application renames a control during a patch. A browser update changes how a page renders just enough that the original selector no longer resolves to anything. None of these changes touch the business logic of the flow at all, yet they are historically among the most common reasons a production RPA process stops overnight. They are also the reason RPA teams spend a disproportionate share of their maintenance time on selector repair rather than on building anything new.

What Self-Healing Desktop Flows Actually Do

Self-healing entered public preview on March 31, 2026, as an agentic capability scoped specifically to UI and web automation actions inside Power Automate for desktop, version 2.66 and later. It is not a general reliability feature, and it does not run continuously in the background. It activates only at the moment a specific action throws an Element not found error on the primary or secondary screen, or a Window not found error on the main screen, and only for actions involving a single UI element interaction such as a click or a checkbox selection.

When that failure occurs, the flow’s existing retry policy still runs first. Self-healing sits as a fallback step after retries are exhausted and before whatever error handling rules a maker has configured downstream, things like setting a variable or running a subflow. At that point, the desktop flow captures a screenshot of the missing element’s expected location, the parent window’s title, and a full image of the desktop, then passes that context to two large language models working in combination: GPT-4.1 mini and Claude Sonnet 4.5. The models attempt to identify a UI element that plausibly matches what the original selector was looking for, propose it as a substitute, and let the flow continue. If neither model can produce a confident match, the flow falls through to normal error handling exactly as if self-healing were not enabled at all.

That single design choice, using self-healing purely as a recovery mechanism rather than a permanent correction, matters more than it might first appear. The feature does not rewrite the flow’s stored selector once it recovers. Every future run of that same action will hit the same missing-element error and go through the same self-healing detour again, which means self-healing reduces the visible symptom of a broken selector without eliminating the underlying maintenance debt sitting behind it.

Where the Coverage Actually Stops

Teams evaluating this feature tend to assume it covers more ground than it does, and the gaps are specific enough to matter for planning. Self-healing does not apply to window or screen handling actions, so a flow that fails because an entire application window can’t be located, rather than a single control inside it, gets no help here. It does not extend to multi-element interactions like drag-and-drop, which remain exactly as brittle as before. It has no effect during designer test runs, applying only to console and cloud runs in attended or unattended mode, so a maker debugging inside the desktop flow designer won’t see it engage at all. And because the underlying models work from a screenshot and a window title rather than the application’s actual DOM or object model, self-healing is inherently probabilistic. Microsoft’s own documentation is direct about this: the models can occasionally identify the wrong element, which for a click action on a financial approval screen is not a theoretical risk worth shrugging off.

Close-up of a laptop screen showing a workflow diagram with one error node highlighted

There is also a visibility gap worth planning around before rollout rather than discovering during an incident. The Power Automate portal does not currently surface self-healing activity inside standard action-level run logs. The desktop flow run page shows a rollup of up to three successful self-healing attempts, but anyone who wants a full audit trail has to fall back to a registry setting that writes a repairWithAIInfo property into local log files on the machine running the flow. That is a meaningfully more manual process than most teams are used to for production RPA monitoring, and it is worth building into a rollout checklist rather than assuming the standard portal view will show everything.

Turning It On

Enabling self-healing is not a single toggle, and the chain of prerequisites is easy to get partway through and assume is finished. It starts in the Microsoft 365 admin center, under Copilot settings, where Anthropic has to be enabled as an approved AI subprocessor. This is already the default for most commercial cloud tenants, but it is worth confirming rather than assuming, especially in regulated environments where subprocessor lists get reviewed on a fixed schedule. From there, the same approval has to be granted a second time inside the Power Platform admin center, under Copilot settings, where external models are configured at either the environment or environment group level. A tenant using non-US regions also needs to explicitly allow data to move across regions under that environment’s generative AI features, since the underlying model calls are not necessarily processed in-region otherwise. Only after those three settings are in place does a fourth toggle, Copilot in Power Automate under the same admin settings, need to be switched on before the capability becomes available to makers at all.

At the flow level, the configuration is much simpler by comparison. Inside the desktop flow designer, a maker opens the error handling settings on a supported UI or web automation action and switches on self-healing for that specific action, one action at a time rather than as a flow-wide setting. This granularity is a genuine advantage for a phased rollout. A team can enable self-healing selectively on the handful of actions in a flow that interact with the least stable third-party interfaces, such as a vendor portal outside the organization’s control, while leaving internal, well-governed applications on standard error handling until there is a clearer track record to point to.

Fitting This Into an Error-Handling Strategy, Not Replacing One

The practical risk with a feature like this is not that it fails to work as documented. It is that a maker treats a preview capability with known gaps as a substitute for the selector discipline, monitoring, and testing that RPA has always required, and quietly stops doing that harder work because the flow appears to keep running. The teams getting real value from self-healing so far are treating it as one layer in a broader error-handling stack, sitting below a solid retry policy and above a documented escalation path, rather than as the whole strategy. That means still designing selectors deliberately instead of accepting whatever the recorder captures by default, still monitoring flow run history instead of assuming silence means success, and still budgeting time for the registry-level log review needed to catch a self-healing attempt that quietly picked the wrong element on a screen nobody double-checked afterward.

Used that way, self-healing does what its name suggests for a specific and fairly narrow category of failure: it buys time and reduces the volume of after-hours pages caused by a button that moved six pixels to the left. It does not, and by Microsoft’s own account is not meant to, remove the need for an RPA program that treats maintenance as part of the design rather than an afterthought to it. Routeget Technologies has been walking clients through exactly this kind of phased rollout, piloting self-healing on the least stable external-facing actions in a flow before deciding how far to extend it. That sequencing, more than the feature itself, is usually what determines whether a preview capability like this earns a permanent place in production.

#PowerAutomate #SelfHealingFlows #DesktopFlows #RPAGovernance #PowerPlatform #AutomationReliability

Configuring Financial Report Packages for Month-End Distribution in Business Central

Finance controller reviewing a bundled financial report dashboard during month-end close

A controller at a mid-market manufacturer spends the first three days of every close cycle doing something that has nothing to do with accounting: assembling a stack of PDFs. The profit and loss statement goes to the executive team. The balance sheet and a G/L detail extract go to the audit committee. A budget variance report goes to department heads, each filtered to their own cost center. In Business Central, every one of those documents has lived as its own Financial Report, generated and distributed on its own schedule, which means close week turns into a sequence of separate print jobs, separate emails, and separate chances to send the wrong version to the wrong list.

That specific problem, bundling several financial statements into one coherent, schedulable output, is what Financial Report Packages address in Business Central 2026 release wave 2. The feature landed in the update 29.0 public preview in September 2026, and it is worth understanding now, while it is still confined to sandbox environments, so that the rollout plan for general availability in October is already written by the time the feature reaches production.

Finance controller reviewing a bundled financial report dashboard during month-end close

What changed, and what didn’t, in wave 1

It helps to be precise about what already existed before this. Business Central 2026 release wave 1 (BC28) gave Financial Reports scheduling for the first time. Before BC28, a Financial Report could only be printed on demand; there was no way to have it generate and land in an inbox automatically. Wave 1 fixed that at the level of a single report: from the Financial Reports page or the Financial Report Card, the Schedules action let you configure a code, a description, an “Export to PDF” or “Send Email” option, a list of recipients pulled from User Setup email addresses, a Next Run Date/Time, and a Recurrence Run Date Formula. Each scheduled run created a Financial Report Export Job entry in Job Queue Entries, and you could stack multiple schedules against the same report if different audiences needed it at different cadences.

That was genuine progress, but it left the packaging problem untouched. A controller with five statements to distribute still needed five schedules, five separate emails landing in five separate messages, and no guarantee they arrived in a sequence or format anyone downstream found usable. Wave 1 solved recurrence. It didn’t solve composition.

How Financial Report Packages work

Financial Report Packages, new in the 29.0 preview, introduce a container object that sits above individual Financial Reports rather than replacing them. You reach it either through Tell Me by searching “Financial Report Packages” or via a Packages action on the Financial Reports page itself. Creating a package starts with a header record (the Financial Report Package table, internally table ID 8371) where you set a name and description, the same way you would name any reusable configuration object in Business Central.

The substance of the package lives in its lines, stored in the Fin. Report Package Report table (ID 8372). Each line points to an existing Financial Report, and this is where the design gets genuinely useful for anyone who has fought with one-size-fits-all reporting: every line can carry its own custom filters and its own date formula, independent of the other reports in the same package. A P&L line might use a “-CM” to “CM” formula to lock onto the current month, while a companion cash flow line in the same package uses a trailing twelve-month range. You’re not forcing every statement in the bundle onto identical dimensions or identical periods just because they’re shipping together.

Once the lines are configured, two actions do the actual work. Print generates the combined output immediately, useful for testing a package before you trust it to run unattended, or for the occasional ad hoc request from a board member who wants “everything” right now. Schedules is where the recurring value shows up: you can set multiple schedules per package, each with its own Next Run Date/Time and Recurrence Run Date Formula, and each capable of emailing multiple recipients whose addresses come from their User Setup records. Every run is tracked in a log, so when someone asks whether the March package actually went out, there’s a record rather than a guess.

The output itself still surfaces through the Report Inbox, the existing Business Central page that lists reports generated by scheduling rather than by the Print action, and that also supports pushing files to OneDrive or sharing them with a link. Packages don’t bypass that infrastructure; they feed it a combined file instead of a single-report one.

Close-up of a laptop showing a bundled financial report configuration next to printed statements during month-end close

Setting this up without recreating the wave 1 mess

The mistake to avoid is treating a package as a folder you drop existing schedules into. It isn’t. If you already built individual report schedules under the wave 1 model, plan to retire the redundant ones once a package covers the same distribution, or you’ll end up with both the old single-report emails and the new bundled PDF landing in the same inboxes, which is a worse experience than the one you started with.

Design packages around who receives them, not around how the reports happen to be organized in the Financial Reports list. An executive package might combine the P&L and a cash position summary. An audit-committee package might combine the balance sheet with a G/L detail extract and nothing else, since that audience doesn’t want departmental variance noise mixed in. A department-head package might need per-line filters set to each recipient’s cost center dimension, which is exactly what the line-level custom filters are built to handle. Because each line’s filter and date formula are independent, you can serve genuinely different audiences from the same underlying report definitions without maintaining duplicate report objects just to vary the scope.

One prerequisite is easy to miss until it breaks a scheduled run: every recipient needs a valid email address on their User Setup record. If it’s missing, the system doesn’t fail silently; it throws an explicit error stating the User Setup does not exist, which is at least diagnosable, but it’s worth confirming recipient setup as a checklist item before you go live with any package schedule rather than discovering the gap on the first missed delivery.

Why this matters more than it looks like it should

The same 29.0 preview also introduced G/L account usage tracing for financial report authors, letting you identify uncategorized accounts and preview a report’s calculations before publishing changes to its definition. That capability matters more once packages exist than it did when every report shipped alone. A calculation error or an uncategorized account sitting quietly in one standalone report is a problem for one audience. The same error sitting inside a package that bundles three statements into a single PDF for the executive team turns one mistake into a credibility problem across every report in the bundle, delivered in one shot. If you’re adopting packages, adopt the account tracing discipline alongside them, particularly for any report line feeding a package that goes to leadership.

It’s also worth being honest about timing. Everything described here is currently a preview feature, available only in Business Central online sandbox environments as of the September 2026 update, with Microsoft’s own documentation cautioning that preview features aren’t intended for production use and may carry restricted functionality until general availability, expected in October 2026. That’s a reasonable amount of time to build and test packages against a real close cycle in a sandbox before betting a live month-end on them. Treat October as the date you flip the switch in production, not the date you start figuring out how packages should be structured.

For an organization that has been assembling a five-document close package by hand every month, that lead time is the useful part. There’s no reason to wait for general availability to define which reports belong in which package, which filters each line needs, and which schedules match your actual close calendar. Doing that groundwork in the sandbox now means the October rollout is a configuration change, not a redesign, and Routeget Technologies typically structures exactly this kind of preview-to-production pilot as a parallel run: the new package alongside the existing manual process for one full close cycle, so any gap surfaces before it reaches an executive inbox.

#BusinessCentral #FinancialReportPackages #MonthEndClose #ERPReporting #FinanceAutomation

Power Apps Offline Profiles Just Got Easier to Build, Not Easier to Govern

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

A regional field service operation gave its dispatch team the green light to build a canvas app for technicians working in cellular dead zones: rural service calls, basement mechanical rooms, warehouses with concrete walls that killed every signal. The maker who built it, an operations analyst with no formal development background, had the app running offline in an afternoon. No ticket to IT, no admin center request, no waiting on a platform team’s sprint capacity. Three weeks later, a technician’s equipment inspection notes from a Friday afternoon call never made it into Dataverse. The app had been minimized on his phone all weekend while he checked email and texted his dispatcher, and Power Apps only syncs when it is actually running in the foreground. The data was not corrupted or lost outright, but it sat unsynced long enough that a compliance audit flagged a two-day gap in a safety inspection record that mattered.

That scenario is becoming more common, and it traces directly back to a change in how Power Apps offline profiles get created in the first place, a shift most IT organizations have not caught up to yet.

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

Power Apps Offline Profiles Move to Maker Studio

Until December 2025, configuring an offline profile for a Dataverse-backed canvas app meant a trip to the Power Platform admin center. A system administrator or system customizer had to define which tables synced, set filters to control data volume, and manage relationships, all through an admin-only surface that kept offline configuration inside IT’s field of view almost by accident. That friction was never framed as a governance control, but it functioned like one: nothing went offline without someone with elevated permissions touching it first.

Microsoft’s 2025 release wave 1 changes removed that checkpoint. Offline profile creation moved directly into Power Apps Studio, reaching general availability on December 12, 2025. A maker building a canvas app can now toggle “Can be used offline” in the app’s settings, generate a new profile from the app’s existing data sources, and publish, without ever leaving the maker experience or requesting elevated access. Microsoft’s stated rationale is reasonable on its face: reduce dependency on admin resources, shorten the path from idea to working field app, and let the people closest to the operational problem build the solution. For a citizen developer with a genuine business need and no admin relationship to lean on, that is a meaningful unblock.

The Governance Question Nobody Configured

The trade being made here is not really about ease of use. It is about who decides that a given business process is allowed to run detached from the server for hours or days at a time, and who is accountable when that detachment causes a problem. Under the old model, an admin reviewing an offline profile request had at least the opportunity to ask whether a given table should sync offline at all, whether the data involved needed tighter access controls, or whether the use case justified the storage and sync overhead. Under the new model, that opportunity does not exist unless an organization builds a replacement for it.

This is not a hypothetical concern specific to one industry. Any Dynamics 365 or Power Platform environment with field technicians, warehouse staff, inspectors, or delivery personnel is a candidate for exactly the pattern described above: a well-intentioned maker solves a real connectivity problem, and the governance layer that used to exist by default is simply gone unless someone rebuilds it deliberately. Organizations that have invested in a Center of Excellence practice are better positioned here, but a CoE toolkit built around monitoring app creation and DLP policy does not automatically extend visibility into offline profile configuration specifically, since that setting lives inside the app rather than as a separate governed artifact.

IT director reviewing a data synchronization and governance dashboard, representing oversight of Power Apps offline profile configuration

Where the Ceiling Actually Sits

Setting governance aside, the built-in offline engine that now powers this has real technical boundaries that a maker moving quickly can hit without realizing it. Dataverse enforces a hard cap of three million total records synced per offline profile, counting hidden system tables the platform uses internally to support offline mode, and a profile that exceeds it fails to sync rather than degrading gracefully. Each table in a profile is limited to fifteen relationships, only one of which can be a many-to-many or one-to-many type, and an offline profile can include at most fourteen image columns across every table involved. Several capabilities common in online apps simply are not supported offline at all: non-Dataverse connectors such as SharePoint or Excel, virtual and elastic tables, calculated and rollup fields (since there is no client-side engine to reevaluate them), the Relate and Unrelate functions, and self-referential or multi-level relationship lookups.

The foreground-sync behavior that caused the technician’s missing notes in the opening scenario is arguably the most consequential limitation for business planning, because it is invisible until it causes a problem. Power Apps only synchronizes offline data while the app is actively running and the device screen is unlocked. There is no background sync service quietly reconciling data the way a native mobile app with push-based sync might. A field worker who closes the app, locks their phone, or switches to another task mid-shift has effectively paused synchronization, and nothing in the default experience tells them that has happened. For a use case involving safety documentation, chain-of-custody records, or time-sensitive service confirmations, that gap deserves explicit attention before the app reaches production, not after an audit finds it.

A Practical Path Forward

None of this argues for reversing the democratization Microsoft has enabled here; the administrative bottleneck it removed was real; a field team should not wait weeks for a platform team to configure something a maker can now do safely in an afternoon. The more useful response is to treat offline-enabled canvas apps as a specific category worth a lightweight review step, separate from the general app governance an organization already applies. That review does not need to be heavy. It can be as simple as requiring any app with offline mode enabled to pass through a short checklist before it reaches production users: confirming the data involved does not exceed reasonable volume for the sync limits described above, confirming the business process can tolerate the foreground-only sync behavior or has been explicitly designed around it (a startup screen reminder, a manual sync button, a status indicator showing pending changes), and confirming someone owns monitoring the Sync Error table for that app rather than assuming silence means success.

It also means updating whatever Center of Excellence monitoring already exists to specifically flag apps where offline mode has been enabled, since that is now a maker-level decision rather than an admin-level one, and the two are not tracked through the same audit trail by default. An organization that already has DLP policies and environment strategy in place is not starting from zero here, but it should not assume that existing governance automatically covers a setting that used to require an admin’s hands and no longer does.

The underlying capability is genuinely useful, and for the right use case, three weeks of unblocked development against three months of waiting for a platform team is not a close call. The organizations that get real value out of this change will be the ones that pair the speed with a deliberate answer to the question the admin center used to answer by accident: who checks this before it goes to the field. Routeget Technologies has walked several clients through exactly this kind of governance retrofit, and the pattern that works best treats offline enablement as a specific, named checkpoint rather than folding it into a general app review that was never built to catch it.

#PowerAppsOffline #CanvasApps #FieldMobility #CitizenDeveloperGovernance #DataverseSync #PowerPlatformGovernance