Configuring Time Entry Duration Controls in Dynamics 365 Project Operations

Project manager reviewing a timesheet approval dashboard showing a calendar grid of time entries

A project accounting lead doing month-end billing reconciliation pulls up a consultant’s timesheet and finds a single day logged at 26 hours. It is almost certainly a typo, someone meant to type 2.6 or fat-fingered an extra digit, but it has already been submitted, approved by a project manager who didn’t look closely, and is sitting in the queue for client invoicing. A few rows down, another resource has logged entries in odd fragments: 7 minutes here, 23 minutes there, none of which line up with the 15-minute billing increments the engagement’s rate card assumes. Neither error is malicious. Both are expensive to catch after the fact, and until this summer, Dynamics 365 Project Operations gave administrators no native way to stop either one at the point of entry.

That gap has started to close. Project Operations now ships two native time entry duration controls that reached general availability within about five weeks of each other in 2026: the ability to configure a maximum daily time entry duration (GA July 24, 2026, tracked in Microsoft 365 message center as MC1425968) and the ability to configure a minimum interval for time entry duration (GA August 31, 2026, MC1443022). Together they give Project Operations something it had previously left entirely to custom validation, whether that meant a Power Automate flow triggered on time entry creation, a plugin registered against the create and update messages, or, more commonly, nothing at all beyond a project manager’s attention during approval.

What the two controls actually do

The maximum daily duration setting lets an administrator define the ceiling on how many minutes a single resource can log across time entries for one calendar day. Per Microsoft’s own release messaging, the configuration is applied from the Parameters page, and it is evaluated every time a time entry is created or modified, not just at submission or approval. That timing detail matters more than it might first appear. It means a resource typing an obviously wrong duration gets an error immediately, in the same session, rather than discovering it later when a project manager rejects the entry or, worse, when it has already cleared approval and shown up on an invoice.

The minimum interval control addresses a different failure mode: durations that are technically valid but operationally useless. Once configured, Project Operations only allows time entries whose duration is a multiple of the value an administrator sets, for example 15 minutes or a full hour. A resource cannot log 22 minutes against a task if the organization has standardized on quarter-hour billing increments; the entry is rejected until it rounds to 15, 30, 45, or 60. Microsoft’s own framing for this feature is squarely about time-tracking policy compliance rather than data hygiene for its own sake, and the distinction is worth sitting with: this is not a cosmetic rounding feature, it is a control meant to make sure recorded time actually maps to how the organization bills or costs labor.

Abstract illustration of a clock face overlaid with a grid representing time entry duration increments

Neither setting appears to expose a granular default in Microsoft’s public documentation beyond the mechanism itself, but field configuration guidance published around the July rollout describes the daily maximum defaulting to a full 24-hour day, meaning 1,440 minutes, until an administrator tightens it. If that reporting holds in your tenant, the practical implication is that this feature does nothing on its own. It has to be explicitly configured to be useful, which is a detail worth confirming in a sandbox before assuming it is protecting anyone.

Rolling out the time entry duration controls without a mess

The temptation with either control is to set the value you actually want on day one: an 8 or 9-hour daily cap matching a standard workday, and a 15-minute increment matching your billing rate card. Resist that instinct for the first rollout cycle. Because validation runs on every create and modify, and because Project Operations time entry has several paths into the system beyond the standard weekly grid, including the Copy Week function, bulk import, and any canvas or model-driven app built against the time entry entity, a tight setting configured without a testing pass tends to surface every non-standard workflow your organization has quietly built up around timesheets.

A safer sequence starts with a maximum daily duration set deliberately loose, something like 16 or 18 hours, purely to catch the genuinely broken entries (the accidental 26-hour day, the decimal-point typo that becomes 240 hours) without touching resources who occasionally work a long day and log it honestly. Watch validation errors for a full billing cycle before tightening toward the actual policy limit. The minimum interval control deserves the same caution, but for a different reason: it will interact directly with any existing Power Automate flows, integrations, or import templates that write time entries with durations your organization never audited closely. An integration pulling hours from a separate scheduling or field service system, for instance, might write entries in whatever granularity that source system uses, and a newly enforced 15-minute increment will start rejecting them the moment it goes live. Map every system of record that writes into project time entries before you set this value, not after.

It is also worth coordinating both settings with how your organization has configured time zone behavior for the time entry grid. Project Operations lets teams choose between time zone aware date handling, where the same entry can display on different calendar dates depending on the viewer’s time zone, and time zone independent handling, which pins the date regardless of viewer location using a dedicated time zone independent date field. For a distributed delivery team spanning multiple time zones, a daily maximum duration check that is evaluated against a date that shifts depending on who is looking at it can produce validation behavior that looks inconsistent to end users, even though the underlying rule hasn’t changed. Confirm which time zone mode is active before assuming daily duration validation will behave the same way for every resource.

What these controls do not solve

Both features validate entries going forward. Neither one appears to retroactively flag or correct time entries that already exist in the system, so a backlog of historical bad data, the kind most organizations discover they have the first time they actually go looking, will not be swept up by turning either setting on. If a data cleanup is part of the motivation for adopting these controls, that remains a separate exercise, likely a Power Platform dataflow or a one-time script against existing records, not something the new parameters retroactively apply.

Equally, neither control replaces approval-stage review. A time entry that respects both the daily maximum and the minimum increment can still be entirely wrong: charged to the wrong project task, misclassified by type, or simply inaccurate about what work actually happened. Duration validation catches a narrow, specific class of error, the kind that shows up as an obviously implausible number or a fractional oddity, and it catches it earlier and more reliably than a human reviewer scanning a timesheet approval queue ever will. It is not a substitute for that review; it removes one category of noise so the review that remains can focus on judgment calls rather than arithmetic.

For organizations running Project Operations at scale, particularly those billing time-and-materials engagements where a single mis-keyed entry can mean a client invoice dispute, these two settings are a genuinely useful, low-effort addition to a governance model that most teams have historically had to build themselves. Getting the rollout sequencing right, testing against every system that writes time entries, and being honest about what the controls do not cover matters more than getting the exact numbers right on day one. Routeget Technologies has walked several Project Operations customers through exactly this kind of parameter rollout, and the pattern holds: the configuration itself takes minutes, and the discovery of what has been quietly writing non-compliant time entries into the system for years takes considerably longer.

#ProjectOperations #TimeEntryValidation #DynamicsFinanceOps #TimesheetGovernance #ERPDataQuality #PSAConfiguration

Power Platform License Enforcement Has a Deadline: February 2027

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

A Power Platform administrator at a mid-size manufacturer got an odd notice in her Microsoft 365 message center in March. It referenced managed environments, a governance feature she associated with premium licensing decisions her CIO had deliberately deferred two budget cycles in a row. She assumed it was routine noise and archived it. Six months later, the same governance feature had been switched on for a dozen production environments without a single approval meeting, because those environments happened to be deployment targets in the organization’s new Power Platform pipelines setup. Nobody had connected the dots between an ALM modernization project and a licensing enforcement clock that started ticking the moment it went live.

That disconnect is becoming common, and it points to a real Power Platform license enforcement deadline that CIOs and IT directors should be treating as a budget line item rather than a footnote in an admin center notification. Microsoft has been quietly retiring the ALM Accelerator for Power Platform, the free, GitHub-based reference implementation many organizations used to bolt source control and deployment automation onto Azure DevOps. In its place, Microsoft is steering everyone toward Pipelines, the native, in-product ALM experience built directly into the Power Platform admin center. The pipelines feature itself is a genuine improvement for most organizations. The licensing mechanics it triggers are the part that deserves scrutiny before anyone signs off on the migration.

Why the ALM Accelerator Is Going Away

The ALM Accelerator was never meant to be permanent. Microsoft built it as a canvas app and Azure DevOps extension pairing, a reference pattern for makers who wanted Git-backed source control and staged deployments without hiring a professional DevOps team. Microsoft’s own documentation now marks it deprecated: no new features, and issues raised against it are no longer reviewed or fixed. The stated successor is Pipelines, described in Microsoft’s guidance as the strategic, in-product experience for maker-initiated application lifecycle management, extensible into Azure DevOps or GitHub when a team needs deeper customization.

For a lot of teams, that is a reasonable trade. Pipelines can be configured in minutes rather than the days or weeks a hand-built Azure DevOps release pipeline typically takes, and it comes with pre-validation, staged approvals, and automatic solution backups out of the box. The tradeoff is that Pipelines requires its non-host target environments, meaning the QA and production environments a solution deploys into, to be managed environments. Development environments are exempt, and the pipeline host itself does not have to be managed, but everything downstream of it does.

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

The Auto-Enablement Nobody Voted On

Here is where the administrator’s ignored notice becomes relevant. Microsoft’s documentation states plainly that starting in February 2026, it began enabling managed environments automatically for any pipeline target environment that was not already configured that way. Tenant admins can opt into a setting under Deployments, Settings in the Power Platform admin center that converts pipeline targets to managed environments proactively, and Microsoft recommends doing so. But the underlying enforcement is not contingent on that opt-in. If a solution is deployed through a pipeline into an unmanaged production environment, Microsoft’s rollout will convert that environment regardless of whether an admin ever flipped the setting.

That matters because managed environments are not a purely technical governance toggle. They carry a licensing dimension that most conversations about ALM modernization skip entirely.

The Licensing Dimension Most ALM Conversations Skip

Managed environments themselves do not cost extra on top of the right license. They come bundled as an entitlement with standalone Power Apps Premium, Power Automate Premium, Copilot Studio, Power Pages, and most Dynamics 365 licenses, along with pay-as-you-go meters for per-app and Copilot Studio consumption. That sounds harmless until you account for how many production apps in a typical enterprise are actually running on seeded or included rights rather than a standalone license: a Power Apps use right bundled into an Office 365 plan, or Power Automate capability included with a Dynamics 365 Pro license and scoped only to that application’s context. Those included rights were never built to satisfy managed environment licensing requirements on their own, and Microsoft’s own FAQ language on the topic notes that Power Apps or Power Automate capability tied to a Dynamics 365 Pro license is meant to be used only within that licensed application, not as a general-purpose citizen development platform.

Managed environments carry an autoclaim policy that automatically assigns the correct license to a user who accesses an app there, provided the tenant has license capacity to draw from. Autoclaim solves the paperwork problem of manually assigning licenses one user at a time. It does not solve the budget problem of simply not owning enough qualifying licenses to autoclaim against, and it does nothing for a user whose only access to Power Apps or Power Automate comes through a seeded right that was never designed to extend into a managed, governed production environment.

Abstract illustration of a countdown clock merging with a network of cloud environment nodes, some locked and some unlocked

The Power Platform License Enforcement Timeline You Are Already Inside

This is not a distant, hypothetical deadline. Microsoft’s published timeline shows administrative notifications through the Microsoft 365 message center and Power Platform admin center beginning in March 2026. In-app notifications aimed directly at end users without an appropriate license started in June 2026, following a staged escalation: an informational message on day one, a warning after seven days, and an error state after fifteen, each urging the user to request a license from an admin. The hard stop lands in February 2027: users who still lack an appropriate license at that point are blocked from opening the app entirely, shown a standard message telling them they need a Power Apps license to use it. Apps are not deleted and access resumes automatically once a qualifying license is detected, but for that window, whatever workflow depended on that app simply stops working for that user.

Given today’s date, that means the notification phase is already well underway inside most tenants that run pipelines against production environments, and the enforcement date is now closer than most annual license renewal cycles.

What This Means for the Business Case

None of this is a reason to avoid Pipelines or to keep patching together an already-deprecated ALM Accelerator deployment. The practical response is to treat the license audit as part of the ALM modernization project plan rather than as an afterthought that surfaces after go-live. That means pulling a current list of every user who accesses production apps sitting in, or scheduled to sit in, a pipeline-managed environment, and checking each one against a standalone qualifying license rather than assuming a Microsoft 365 or Dynamics 365 seat covers it. It means asking whether apps currently running on included, scoped rights actually need to move to standalone Premium licensing, get rearchitected to stay within their original licensed application’s context, or get retired if nobody can justify the cost. And it means giving finance and procurement enough lead time to true up license counts well before February 2027, rather than discovering the gap when a plant floor supervisor gets locked out of a production app and escalates it as an outage.

Organizations that have gone through this kind of ALM transition tend to find the technical migration to Pipelines is the easy part. The harder, more valuable work is the license and governance audit that should have accompanied it from the start, which is usually where firms like Routeget Technologies get pulled into these engagements: less to configure a pipeline, more to make sure the environments behind it do not quietly turn into a compliance problem eleven months later.

#PowerPlatformPipelines #ManagedEnvironments #ALMGovernance #PowerPlatformLicensing #LicenseComplianceAudit #EnterpriseGovernance

The AI Builder Credits Transition Has a Deadline: November 1, 2026

Finance and IT leaders reviewing Power Platform licensing budget charts on a laptop in an office setting

A Power Platform administrator at a mid-market distributor recently walked into her CFO’s office with a number nobody had budgeted for. Her company’s invoice-processing flow, built on AI Builder’s document processing models three years ago, had been running on credits bundled quietly into a Power Automate Premium renewal. That renewal comes up again in October. She had just learned that whatever gets signed this fall will be the last one to include those free credits at all, and that the resulting seeded credits and add-on option would disappear entirely for anyone who renews after November 1, 2026. Nobody in finance had flagged it as a line item, because for three years it had never been one.

That scenario is becoming common across organizations that adopted AI Builder early, when its credits shipped as a quiet inclusion in Power Apps, Power Automate, and Dynamics 365 licenses rather than a metered, purchased capacity. The AI Builder credits transition Microsoft is now enforcing retires that model outright, and the cutoff sits close enough on the calendar that IT Directors and finance leaders currently mid-negotiation on a Power Platform renewal need to understand it before they sign, not after.

What the AI Builder credits transition actually changes

Abstract illustration of digital credit tokens flowing between two separate licensing systems

AI Builder, the low-code AI layer inside Power Apps and Power Automate that handles document processing, form extraction, sentiment analysis, and prediction models, has historically been funded two ways: seeded credits bundled into premium licenses at no extra cost, and AI Builder capacity add-ons purchased separately when an organization’s usage outgrew the bundled amount. Microsoft’s documentation lists specific seeded allotments: Power Apps Premium includes 500 AI Builder credits, Power Apps per-app licenses include 250, Power Automate Premium and its RPA add-ons include 5,000 each, and Dynamics 365 Finance and Operations includes 20,000. A standalone AI Builder capacity add-on carries 1,000,000 credits.

Starting November 1, 2025, Microsoft closed new-customer sales of AI Builder capacity add-ons and shifted AI Builder features onto a dual-currency consumption model: an environment draws down its AI Builder credits first, and if those run out, the system automatically falls back to Copilot Credits before blocking the operation. Existing add-on customers could still renew and purchase through that window. November 1, 2026 is the harder cutoff. On that date, existing AI Builder capacity add-ons reach end of life: customers with an active add-on keep using the credits tied to it, but can no longer renew it or buy a new one. Separately, any Power Platform or Dynamics 365 license purchased or renewed on or after that date stops receiving seeded AI Builder credits altogether. If your renewal lands in September or October, you’re likely getting the last cycle that includes them at no incremental cost. If it lands in November or later, that inclusion is gone for the new term.

Microsoft has been explicit that it will honor entitlements already under contract. Licenses and add-ons purchased before the cutoff keep their credits for the remainder of that specific contract term, whatever length that is. What changes is the next renewal, not the current one already in force. That distinction matters enormously for budget planning, because it means the financial exposure isn’t immediate for most organizations. It arrives at whatever renewal date happens to fall after November 1, and for some finance teams that’s uncomfortably close.

Why this is a budgeting problem, not a technical one

The mechanically important detail, and the one most likely to catch a finance team off guard, is that there is no automatic conversion between the two credit systems. Microsoft’s own documentation states plainly that AI Builder credits and Copilot Credits are separate currencies with separate consumption rates per action, and unused AI Builder credits don’t roll over or translate into an equivalent number of Copilot Credits when the seeded allotment disappears. An organization that has been running document processing workloads for years on a bundled 20,000-credit Dynamics 365 F&O allotment, or a 5,000-credit Power Automate Premium allotment, needs to separately estimate what the equivalent workload costs once it draws exclusively on purchased Copilot Credits, because the published rate cards for the two currencies aren’t set up to produce the same effective cost per document or per prediction. Assuming last year’s consumption simply carries forward at the same dollar cost is the exact assumption this transition breaks.

This is where the business risk actually lives. AI Builder adoption inside Dynamics 365 F&O and Business Central environments tends to concentrate in exactly the processes finance departments care most about protecting: accounts payable invoice capture, receipt and expense processing, contract data extraction, vendor document classification. These are high-volume, repetitive workloads that were attractive to automate specifically because the seeded credits made the marginal cost of processing another document effectively zero. Once that seeded allotment is gone, the marginal cost stops being zero, and depending on volume, it can become a meaningful new operating expense that nobody modeled into the automation’s original ROI case.

What CIOs, CFOs, and Power Platform administrators should do before their next renewal

The first step is straightforward but frequently skipped: pull actual AI Builder consumption data from the Power Platform Admin Center, under Licensing and Capacity add-ons, before the renewal conversation starts rather than during it. Monthly consumption resets and doesn’t accumulate, so a single month’s snapshot understates volume during seasonal peaks like month-end close or year-end 1099 processing. Look at a full quarter, not a spot check.

The second step is checking renewal timing against the cutoff with more precision than “sometime this year.” A Power Automate Premium license renewing October 15 keeps its seeded credits for that full new term even though the term extends past November 1, since Microsoft’s honoring rule is tied to the contract’s start date, not to a mid-term calendar boundary. A license renewing November 15 does not get that benefit. For organizations with renewal dates close to the line, it’s worth confirming the exact contractual start date with a Microsoft partner or account team rather than assuming based on the calendar month alone.

Third, for teams that expect to keep growing AI Builder-dependent automation rather than shrinking it, purchasing or renewing an AI Builder capacity add-on before November 1, 2026 locks in access to that add-on’s credit pool and its associated rate for as long as the add-on contract runs, even though new add-on purchases stop being available afterward. That’s a genuine one-time window, not a recurring option, and it’s worth evaluating now rather than assuming it will still be available closer to the deadline.

Finally, this is a reasonable moment to model Copilot Credit costs for AI Builder workloads specifically, rather than treating Copilot Credits as an abstract budget line shared across every AI feature in the tenant. Document processing, form extraction, and prediction actions each draw against Copilot Credits at their own published rate once AI Builder credits are exhausted, and an organization running several automated document workflows across F&O, Business Central, and Power Automate should size that consumption separately from whatever Copilot Studio agent or Copilot chat usage is already drawing from the same pool. Treating them as one undifferentiated bucket is how a finance team ends up with a Copilot Credit shortfall it didn’t see coming from an entirely different application.

None of this requires panic, and it doesn’t require ripping out working automation. It requires treating a licensing calendar date the way a solution architect would treat any other deprecation notice: as a planning input with a hard date attached, not a vague future concern. At Routeget Technologies, the licensing transitions we’ve helped clients navigate tend to follow the same pattern: the technical migration is manageable, but the budget surprise is what actually causes friction with finance. Getting ahead of the renewal date, and getting real consumption numbers in front of the people who sign the contract, is what turns this from a surprise into a line item.

#DynamicsAIBuilder #CopilotCredits #PowerPlatformLicensing #ERPBudgetPlanning #EnterpriseAI #FinanceAutomation

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

Dynamics 365 Sales Home Lead Research Reaches GA. Read the License Fine Print First.

Sales operations manager reviewing an AI-prioritized lead list on a dashboard screen in a modern office

A sales operations director at a mid-market manufacturer spent part of August walking her CRO through the 2026 release wave 1 notes for Dynamics 365 Sales, and one line stood out: Sales Home lead research and next best actions were shipping this wave, landing directly on the screen every rep already opens first thing in the morning. It read like a free upgrade, the kind of quiet interface improvement Microsoft ships every wave without anyone needing to ask for it. Then she checked the prerequisites. The feature does not turn on by itself. It requires the Sales Qualification Agent, or its lead research capability, to be provisioned first, and that agent draws from the same Copilot Credit pool her finance team had already earmarked for a completely different AI rollout in customer service. What looked like a UI refresh was actually a new consumption-based line item, and nobody in the budget conversation had accounted for it.

That gap between how a feature reads in the release notes and how it actually gets paid for is becoming a recurring theme in the Dynamics 365 Sales roadmap, and it is worth understanding in detail before your own team flips the switch.

Sales operations manager reviewing an AI-prioritized lead list on a dashboard screen in a modern office

What Sales Home Lead Research Actually Does

The feature itself, officially titled “Get lead research and next best actions in Sales Home,” reached general availability this month after entering public preview in June. It puts a prioritized, AI-scored list of leads directly on the home screen sellers already use, ranked by urgency, fit, and engagement signals rather than by creation date or a manually assigned score. For each lead, the panel surfaces a short research summary, the reasoning behind why the system considers it worth pursuing now, and a recommended next action, whether that is a follow-up call, a qualification step, or simply unblocking an agent that is waiting on a decision. Sellers can act on the recommendation without leaving Sales Home, and the system tracks whether the action was taken so high-value leads stop quietly stalling in someone’s queue.

On paper, this solves a real and common problem. Most sales teams do not lack leads; they lack a reliable way to decide which ten of the two hundred leads sitting in a queue actually deserve a call this morning. Manual lead scoring models built on static rules tend to go stale within a quarter, and reps develop their own private heuristics that rarely match what marketing or revenue operations intended. A model that explains its reasoning, rather than just spitting out a number, addresses the trust problem that has quietly limited adoption of every previous generation of predictive lead scoring in this platform.

The Licensing Mechanic Buried in the Prerequisites

Here is where the release notes get less generous with detail than a budget owner would like. The Sales Home panel is not a standalone capability; it is a surface built on top of the Sales Qualification Agent, which does the actual research and reasoning work in the background. That agent is available with Dynamics 365 Sales Professional, Enterprise, or Premium licensing, but it consumes Copilot Credits with every research pass, every drafted outreach email, and every autonomous follow-up it sends. Premium licensing includes an allotment of 1,000 credits per user per month; everything past that draws from a purchased credit pool that is shared across every Copilot-metered feature in the tenant, not ring-fenced for Sales Home alone.

Abstract visualization of a metered digital consumption gauge representing Copilot Credit usage

That last detail matters more than it sounds. Organizations running Dynamics 365 Sales alongside Customer Service or Field Service are increasingly stacking multiple agentic features onto the same finite credit budget: a qualification agent working inbound leads, a service agent summarizing cases, perhaps a Copilot Studio agent doing something entirely unrelated to sales. None of these consumption patterns are visible to a sales operations leader evaluating a single feature in isolation, which is exactly the position our manufacturing client found herself in. The fix is not complicated, but it does require a step most teams skip: pull actual Copilot Credit consumption reports from the admin center before approving a new agent, rather than assuming existing licensing already covers it.

A Cautionary Parallel Already Sitting in the Same Interface

Sales Home is not new territory for features that look simpler in a release note than they turn out to be in production, and the platform’s own history with Sequences is instructive. Sequences, the guided step-by-step workflow tool for structuring outbound cadences, shipped years ago with obvious appeal and has been quietly constrained ever since by details that never made it into the initial pitch. It ties automated email steps to a seller’s personal mailbox, so organizations relying on shared or group mailboxes for outbound outreach have had to build custom workarounds. Enterprise-tier licensing caps sequence assignments at 1,500 records a month, a ceiling that arrives faster than most sales operations teams expect once a cadence scales past a pilot team, and lifting it means moving to Premium. Even the interface has friction: when Sequences’ “Next Up” panel and the standard Timeline component both appear on the same record, reps report genuine confusion about which one is actually telling them what to do next.

None of this means Sequences was a bad investment, and it does not mean the new lead research panel will repeat every one of these specific problems. It means that features surfaced in Sales Home tend to carry structural constraints, whether licensing caps, mailbox dependencies, or credit consumption, that only become visible once a team is past the pilot and into real volume. A decision-maker evaluating the new panel should treat that pattern as a reason to pilot deliberately rather than roll out broadly on day one.

What the Early Evidence Actually Shows

Microsoft has published its own benchmark for the underlying Sales Qualification Agent, introduced in December 2025 as the Microsoft Sales Bench, which compared the agent against a general-purpose model across identical synthetic lead datasets judged by both human reviewers and an LLM evaluator. The agent scored roughly six percent higher on research quality, twenty percent better on outreach personalization and timeliness, and sixteen percent higher on multi-turn engagement handling. Those numbers are worth taking seriously as a signal that Microsoft has purpose-built this agent for the sales qualification task specifically, rather than wrapping a generic model around CRM data. They should also be read for what they are: an internally run comparison on synthetic data, not an independent third-party audit, and a reasonable board-level question is whether your own historical lead data, industry, and deal complexity resemble the benchmark’s assumptions closely enough for the numbers to transfer.

A more grounded data point comes from an early adopter, Sandvik Coromant, whose pilot reportedly saved roughly 120 hours and nineteen thousand dollars in labor cost over three weeks, with a forecasted five percent revenue lift once rolled out fully. That is a genuinely useful reference point, and it is also a single case study from one organization’s specific lead volume and sales motion. Treat it as evidence the mechanism can work, not as a guaranteed return for every deployment.

Questions Worth Answering Before Enabling It

Before turning this on for a full sales organization, a few questions deserve real answers rather than assumptions. First, what is your current Copilot Credit consumption across every agent already running in the tenant, and how much headroom does that leave for a new, continuously-running qualification agent working every inbound lead? Second, is your lead data clean enough for a fit-and-engagement model to produce useful rankings, or will the agent simply be scoring noise, since garbage lead records produce garbage prioritization regardless of how good the underlying model is? Third, has your team learned the operational lessons Sequences already taught the organization about mailbox dependencies and licensing tiers, and does the rollout plan account for the fact that Premium licensing changes both the credit allotment and the feature ceiling?

None of these questions should stop a team from adopting a genuinely capable piece of AI-assisted sales tooling. They should shape how the rollout is sequenced: a single team piloting for a full quarter with credit consumption tracked explicitly, rather than a tenant-wide switch flip driven by excitement over a release note. Routeget Technologies has walked several clients through exactly this kind of staged Copilot-agent adoption inside Dynamics 365 Sales, and the pattern holds consistently: the technology performs well when the budgeting and governance work happens first, and creates friction almost every time it happens after the fact.

The lead research panel in Sales Home is a real improvement to a genuine problem, giving sellers a defensible answer to which lead to call next instead of a gut feeling. Just make sure procurement and revenue operations are reading the same release note your sales team is excited about, because the license question and the feature announcement did not ship in the same paragraph.

#SalesHomeAI #Dynamics365Sales #CopilotCredits #SalesQualificationAgent #RevenueOperations #LeadPrioritization

Business Central CAMT.053 Migration: What Actually Needs to Change

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

A finance systems administrator at a mid-size manufacturer got an email last month from the company’s German house bank. Starting in the first week of the new quarter, the daily MT940 statement feed that had fed Business Central’s bank reconciliation for six years would stop. In its place: a CAMT.053 XML file, delivered on a different schedule, with a different structure. The email asked, almost as an afterthought, whether the ERP would “just work” with the new format. It was not a rhetorical question the bank expected an answer to. It was a notice.

That conversation is playing out across Business Central shops right now, and it is worth understanding why the Business Central CAMT.053 migration is arriving in 2026 specifically, what Business Central’s native tooling actually does with a CAMT.053 file, and where that tooling quietly runs out before a consultant finds out the hard way during a month-end close.

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

Why the Business Central CAMT.053 Migration Is Landing Now

The ISO 20022 migration has two distinct halves, and they are not moving on the same clock. The first half concluded in November 2025, when SWIFT ended coexistence for cross-border payment instructions. MT103, MT202, and the rest of the legacy payment message types stopped flowing in their original form; everything now moves as ISO 20022 MX, primarily pacs.008 and pacs.009. Institutions that kept sending legacy MT payment formats after that date found them auto-converted by SWIFT, with additional charges applied starting January 1, 2026.

The second half, covering statement and reporting formats rather than payment instructions, was deliberately left on a slower and less coordinated timeline. MT940 and MT950 (account statements), MT900 and MT910 (debit and credit notifications), and MT941 and MT942 (intraday reporting) are being replaced by camt.053, camt.054, and camt.052 respectively, but SWIFT is not converting MT9xx traffic to camt format automatically. Each bank negotiates its own cutover, account by account, on whatever internal schedule its own core banking migration allows. That is precisely why one Business Central customer converted a year ago without much drama, another is getting the notice this quarter, and a third will not hear anything until 2027. There is no single migration date to plan around. There are dozens of them, one per banking relationship, arriving on nobody’s schedule but the bank’s.

The Business Central Side of the CAMT.053 Migration

Business Central handles SEPA CAMT import through a Data Exchange Definition, a mapping layer that translates XML element paths in the bank’s file into fields across three tables: the General Journal table, the Bank Acc. Reconciliation header, and the Bank Acc. Reconciliation Line table. The mapping itself is fairly mechanical once you see it laid out. The transaction amount and its sign come from Stmt/Ntry/Amt combined with the credit or debit indicator at Stmt/Ntry/CdtDbtInd, with a configurable negative-sign identifier (typically set so that DBIT entries post as negative). Posting and transaction dates come from Stmt/Ntry/BookgDt, which can arrive as either a plain date or a full timestamp; Business Central accepts both. Payer information for matching comes from Stmt/Ntry/NtryDtls/TxDtls/RltdPties/Dbtr/Nm, and the free-text remittance information that drives most of the automatic matching logic comes from Stmt/Ntry/NtryDtls/TxDtls/RmtInf/Ustrd.

The field that actually determines whether any of this works is easy to miss: Stmt/Ntry/NtryDtls/TxDtls/Refs/EndToEndId. This is the identifier Business Central relies on to treat each line as unique within an open reconciliation. If a bank’s first-generation camt.053 export leaves this element empty, or populates it with a placeholder value repeated across an entire batch, the failure mode is not an import error. The file parses without complaint. What actually happens is worse in a subtler way: lines with a missing identifier get silently dropped, and lines that share a duplicated identifier with something already posted will import but fail automatic matching one by one, with no message pointing back to the cause. A team that has not specifically gone looking for this will spend a reconciliation cycle assuming the new statement format is simply less complete than the old one, when the real problem is a configuration gap that a five-minute look at the raw XML would have caught before go-live.

Abstract visualization of two data streams merging, representing a bank statement format migration

Where the Generic Definition Runs Out

Business Central ships a generic SEPA CAMT data exchange definition, and it is a reasonable starting point, not a finished solution. CAMT.053.001.08 is a schema, not a single fixed file layout, and individual banks populate it with their own dialect: some banks include optional elements Business Central’s default mapping ignores, some omit fields the default mapping expects, and namespace versions drift between institutions even within the same country. In practice, most multinational Business Central deployments end up cloning the generic definition per banking relationship rather than trying to maintain one shared version that quietly breaks every time a new bank is onboarded with slightly different habits.

It also helps to be honest about geographic scope. CAMT adoption is heavily concentrated in the EU and a handful of other markets that have committed to the SEPA-aligned schema. Plenty of banks elsewhere, particularly smaller regional institutions in North America and parts of Asia, are staying on BAI2 or proprietary flat-file formats for the foreseeable future, with no camt.053 timeline at all. A single Business Central tenant with entities in four countries can easily end up running MT940, camt.053, and BAI2 in parallel for years, not as a transitional state but as the normal operating condition. For organizations with a long tail of smaller regional banking relationships, this is where an ISV connector such as AMC Banking 365 Fundamentals earns its licensing cost: it converts against several hundred bank-specific format variants through its own service rather than asking an internal team to build and maintain a bespoke Data Exchange Definition for every regional bank quirk. That trade-off is worth evaluating deliberately, since routing statement data through a third-party conversion service is a data-governance decision as much as a technical one.

A Practical Migration Checklist

The teams that get through a bank-driven format change without a rough reconciliation cycle tend to do a few things in a specific order. They start by inventorying every bank account’s current import format code and confirming the actual cutover date per relationship, since assuming all banking relationships move together is the single most common planning mistake. Before the cutover, they request an actual test camt.053 file from the bank, not a sample pulled from vendor documentation, and run it through the Data Exchange Definition in a sandbox company where a bad mapping does no damage. They open that test file as raw XML and check the EndToEndId population line by line rather than trusting that because a mapping worked for one bank’s camt.053 export, it will behave identically for another bank using the same nominal schema version. Where any deviation shows up, they clone the generic SEPA CAMT definition into a bank-specific version rather than editing the shared default, so a fix for one relationship cannot silently change behavior for every other bank account using the same code. They keep the outgoing MT940 or BAI2 definition active and assigned for as long as the bank is willing to run both feeds in parallel, because a same-day cutover with no fallback window turns any mapping problem into an immediate reconciliation gap. And before retiring the old feed for good, they re-test automatic matching rates against a full month of real transaction volume on the new format, since a quiet drop in match percentage is a far more reliable early warning of a mapping issue than an outright import failure would be.

What Copilot’s Bank Reconciliation Assist Does and Doesn’t Solve Here

Business Central’s Copilot-assisted bank reconciliation feature, currently in preview, is genuinely useful for what it does: it analyzes unmatched transaction descriptions and ledger entries to suggest matches and likely G/L accounts, including scenarios where a single deposit needs to be split across several invoices. It is worth being clear about its boundaries in this specific context, though. It operates entirely downstream of the Data Exchange Definition, on statement lines that have already been successfully parsed into the system. If a mapping problem is dropping or mismatching lines before they ever reach the reconciliation worksheet, no amount of AI-assisted matching afterward will surface or correct that. The feature also performs best when transaction descriptions and G/L account names share a single consistent language, which is worth double-checking specifically during a format changeover, since a bank’s new camt.053 export sometimes reformats descriptive text differently than its old MT940 feed did.

The Deadline Is the Bank’s, Not Yours

None of this is a discretionary upgrade a Business Central team can schedule around a quieter month. It is a mapping and validation project with a deadline set by someone else’s core banking migration, arriving on a per-relationship basis rather than a single company-wide date. The organizations handling it well are the ones treating each bank’s cutover notice as a trigger for testing, not as an announcement to file away until the old feed actually stops. Routeget has walked several clients through exactly this kind of parallel MT940 and camt.053 coexistence during multi-entity rollouts, and the pattern is consistent: the mapping work is small, but only when someone does it before the bank forces the issue rather than after.

#BusinessCentral #CAMT053Migration #BankReconciliation #ISO20022 #DataExchangeDefinitions #ERPIntegrations

The Warehouse App V3 to V4 Migration Is an Infrastructure Project, Not an App Update

Warehouse worker scanning a barcode with a handheld mobile device in a distribution center

A distribution center running a fleet of Zebra handhelds on the Warehouse Management mobile app got a call from the floor supervisor in late July: barcode scans on inbound receiving were suddenly failing on about a third of devices, right after an over-the-air Android update pushed through despite the fleet being enrolled in Intune with update deferrals configured. The IT team opened a support ticket. The answer that came back wasn’t a patch. It was a reminder that the app on those devices, version 3, had been out of support since May, and the fix wasn’t going to be a hotfix to V3. It was going to be the V3 to V4 migration the team had scheduled for “sometime in Q3” and then quietly let slide.

That scenario is playing out at more distribution operations than Microsoft’s release notes would suggest, because the framing around this migration has made it sound smaller than it is. Under the hood, this isn’t a UI refresh. Microsoft rebuilt the Warehouse Management mobile app from scratch, moving it off Xamarin, a framework Microsoft itself retired from general support back in 2024, and onto React Native. That single architectural fact explains almost everything else about why this migration behaves differently from a normal app update, and why solution architects planning a fleet rollout need to treat it as an infrastructure project rather than an app-store bump.

Why This Isn’t a Simple App Update

Xamarin’s own end of life is the real driver here, not a desire to add dark mode. A framework built on Mono and .NET for cross-platform mobile development, Xamarin stopped receiving Microsoft support in May 2024, which put every product still built on it, including the warehouse app, on a clock. React Native gets Microsoft a modern, actively maintained foundation, and it shows up concretely in the release cadence: since V4’s staged rollout completed in early 2026, point releases have shipped roughly monthly, each carrying real functional changes rather than just security patches.

The rewrite also changed the authentication stack, replacing legacy libraries with MSAL and OneAuth, and that change has consequences that have nothing to do with barcode scanning. On Windows, the redirect URI registered in Azure AD app registrations needs to include ms-appx-web://microsoft.aad.brokerplugin/{clientId} for the broker flow to work. For on-premises deployments authenticating through AD FS, both Windows and Android need new redirect URIs registered before a single device can sign in to V4, which means this migration touches identity configuration owned by a different team than the one running the warehouse floor, and that handoff is where a lot of rollouts stall.

Abstract visualization of a mobile device platform migration on a handheld scanner screen

What Actually Breaks During a V3 to V4 Migration

Three things trip up fleet migrations that the high-level release notes gloss over, and all three are worth budgeting time for before a rollout window opens rather than during it.

The first is device eligibility. V3 supported Android 5 and later, while V4 requires Android 7. Any handheld still running Android 5 or 6, which is not unusual in a warehouse fleet with a five-to-seven-year hardware refresh cycle, simply cannot run V4 and has to keep running V3 until it’s replaced. That forces a mixed-fleet reality during the transition window: V3 and V4 can run side by side on different devices without conflict, but they cannot coexist on the same device, so the migration has to be planned and executed per device, not as a single global cutover.

The second is the iOS experience, which behaves noticeably worse than Android or Windows during migration. On those two platforms, connection settings carry over automatically from V3 to V4 as long as the device was already on V3 version 3.0.8 or later before the switch. On iOS, none of that carries over. Every connection has to be manually reconfigured after installing V4, and Device Code authentication, which a lot of iOS deployments relied on, isn’t supported in V4 at all; iOS is limited to username and password. The practical workaround worth building into a migration plan is generating QR codes or JSON configuration files ahead of time for each site or device group, so floor staff aren’t hand-typing server URLs and warehouse codes on a phone screen during a go-live window.

The third is the support-window structure itself, which changed again after V4 launched. Starting with version 4.1.1.0, Microsoft introduced a rolling twelve-month support window, effective May 2027, meaning only V4 releases published within the previous twelve months are eligible for support at any given time. A fleet migrated to V4 in early 2026 and left untouched will fall out of that support window well before 2027 arrives, so the actual deliverable of this project isn’t “get to V4.” It’s “get to V4 and keep a patch cadence going,” which is a different kind of ongoing commitment than most IT teams budget for an app migration.

A Practical Migration Sequence

The sequence that has worked cleanly across the fleet migrations worth learning from starts with an inventory, not an install. Pull every device’s current OS version and current app version before scheduling anything, because that inventory determines three separate migration paths: devices already eligible for direct upgrade, devices that need a V3 update to 3.0.8 or 3.0.9 first to preserve their configuration, and devices that need hardware replacement before they can run V4 at all.

For the Android and Windows devices in the first two paths, the upgrade itself is close to routine: push the V4 install through Intune or another MDM tool without uninstalling V3 first, since choosing the in-place upgrade path is what preserves the existing connection settings. Stage this in waves by site or by shift rather than as a single fleet-wide push, because the one-time reauthentication requirement per device means a help desk fielding sign-in questions from three hundred devices simultaneously is a bad night for everyone involved, whereas fifty devices at a time is manageable.

For iOS, treat it as its own project inside the larger migration rather than an afterthought. Confirm every affected user has username and password credentials provisioned before the cutover, since Device Code won’t be available as a fallback. Build the QR code or JSON configuration files in advance, and consider disabling auto-update on iOS devices until those configuration artifacts are ready, so a device doesn’t land on V4 mid-shift with no way to reconnect.

Keep the rollback path in mind but don’t lean on it as a safety net for the whole fleet. Individual devices can be downgraded to V3.0.9 if V4 surfaces a blocking issue during testing, which is useful for a pilot group, but Microsoft has been clear that once a region has fully migrated, that region-level rollback isn’t available. Pilot on a genuinely small, representative slice of the fleet, not just the devices sitting on IT’s desk.

Closing the Loop After Go-Live

The migration doesn’t end when the last device reports in on V4. Recent point releases have shipped capability that’s worth actively adopting rather than ignoring once the fleet is stable: a ProGlove arm scanner bridge for hands-free scanning workflows, editable client settings that let enterprise environments enforce TLS 1.2 and forced sign-in policies centrally, and expanded barcode format support including GS1 batch number separators that some receiving workflows depend on. None of that shows up automatically; it requires staying inside that rolling twelve-month support window Microsoft built into the V4 support model, which means assigning someone ownership of the update cadence the same way a team would own patch management for any other production system.

Routeget has run this exact device-inventory-first sequencing for several clients moving mixed Android and iOS fleets this year, and the pattern holds: the migration itself is mechanical once the inventory and identity prerequisites are sorted out. What actually determines whether it goes smoothly is whether someone treated it as an ongoing operational commitment from the start, rather than a one-time app-store update to check off a list.

#WarehouseManagementApp #DynamicsSCM #MobileFleetMigration #XamarinToReactNative #ERPGovernance #SupplyChainAutomation

Advanced Connector Policies Are GA. Here’s What Still Needs Classic DLP.

IT governance administrator reviewing a Power Platform connector policy dashboard on a widescreen monitor

An admin at a 400-environment tenant spent a Tuesday afternoon tracing why a maker in a finance sandbox could connect a flow to a third-party file-sharing connector that should have been blocked tenant-wide. The tenant-level DLP policy classified the connector as non-business. An environment-specific policy, created eighteen months earlier for a since-retired pilot project, had it classified as business instead, and because classic DLP evaluates every applicable policy and merges the results, the older, looser rule won for that one environment. Nothing was misconfigured in the sense of a typo or a missed checkbox. It was misconfigured in the sense that nobody could reason about which rule applied where anymore.

That kind of drift is the specific problem Advanced Connector Policies were built to close, and as of June 4, 2026, they are generally available across the Power Platform admin center. For solution architects and platform administrators who have spent years managing DLP through the classic business/non-business/blocked model, ACP is not a UI refresh. It changes the underlying enforcement model, and it does not yet cover everything classic DLP does, which means the real work right now is figuring out exactly where the boundary sits.

What Advanced Connector Policies Actually Change

Classic DLP lets an environment inherit from multiple overlapping policies at once: a tenant-wide baseline, group-level rules, environment-specific exceptions, sometimes all three stacked on top of each other. The runtime evaluates all of them and applies the most restrictive result for a given connector, which sounds safe until you have dozens of overlapping policies and nobody has a single view of what’s actually allowed in environment 214. Advanced Connector Policies replace that model with something much narrower: each environment can have exactly one effective ACP, either configured directly on the environment or inherited from an environment group, never both at once.

The more consequential change is the default posture. Classic DLP sorts connectors into three buckets and anything not explicitly sorted lands in a default bucket, which in practice means most connectors are reachable unless someone deliberately restricts them. ACP inverts that. It is a strict allowlist: every connector is blocked until an administrator explicitly allows it, and critically, newly released connectors are blocked by default rather than automatically available. That second part matters more than it looks. Under classic DLP, Microsoft ships a new certified connector and it’s immediately usable in every environment that doesn’t have an explicit block rule against it, which is exactly how ungoverned tools accumulate over time. Under ACP, a new connector requires deliberate action before anyone can touch it, which shifts the operational model from periodic cleanup to ongoing curation.

Action-Level Control and Where MCP Governance Fits

ACP also goes deeper than connector-level allow or block. Within an allowed connector, admins get visibility into individual triggers, regular actions, internal actions, and actions Microsoft has marked deprecated, and can block any of those independently, which is useful for pushing makers off a deprecated action a legacy flow still references without pulling the whole connector. One behavior worth knowing before you rely on it: once a connector is scoped down to specific allowed actions, any new action or trigger Microsoft adds later isn’t automatically included. It has to be added deliberately, consistent with the allowlist philosophy but meaning a connector configured carefully in June can quietly miss a capability Microsoft ships in September until someone revisits the policy.

IT governance administrator reviewing a Power Platform connector policy dashboard on a widescreen monitor

This is also where ACP intersects with agentic AI governance, worth calling out since most classic DLP writeups predate MCP entirely. Advanced Connector Policies give admins visibility into MCP servers alongside standard connectors and let them block an entire server, but they don’t yet offer granular control over individual tools exposed by that server. If a team stands up an MCP server bundling a dozen tools and you need eight of them permitted while two are blocked, ACP can’t currently express that: the block is server-wide or nothing. For organizations moving quickly on Copilot Studio agents and custom MCP integrations, that’s a real gap to plan around, since it means governance over agent tool access is currently coarser than governance over a standard connector’s actions.

What’s Still Missing, and Why Classic DLP Isn’t Going Away Yet

The limitation that will affect the most environments in practice is that ACP currently only governs certified connectors. Custom connectors and HTTP connectors, including HTTP with Azure AD and the endpoint filtering that lets admins restrict a custom or HTTP connector to a specific allowed URL pattern, are not supported in ACP today and have no committed timeline for parity. If your tenant relies on endpoint filtering to say, for instance, that a generic HTTP connector may only call approved internal APIs and nothing else, that control still lives entirely in classic DLP. Virtual connectors are a separate case again: Copilot Studio’s virtual connectors are being moved to a dedicated governance model built specifically for that surface rather than folded into ACP, and Power Automate desktop flow virtual connectors are being converted into certified connectors over time, at which point they’ll fall under standard ACP rules like anything else.

Microsoft’s answer to this gap is mixed mode, which is also the default state for any environment or environment group where ACP has been configured. In mixed mode, both classic DLP and ACP evaluate simultaneously and the platform applies whichever result is more restrictive. That’s a genuinely useful design for migration: an organization can build out its ACP allowlist for certified connectors incrementally, watch how it behaves in mixed mode against real usage for a few weeks, and keep the existing classic policy doing the work ACP can’t do yet, namely custom connectors, HTTP endpoint filtering, and virtual connectors. Only once an environment’s governance needs are fully expressible in ACP, which for most tenants means never for HTTP-heavy environments, should it be switched to ACP-only mode, which turns off evaluation of classic policies entirely for that scope and can only be reversed by reconfiguring the rule.

Abstract network diagram on a laptop screen showing allowed and blocked system connections

Design-Time Enforcement Is Rolling Out Workload by Workload

One detail that’s easy to miss in the announcement is that GA for ACP as a policy engine is not the same as GA for design-time enforcement across every maker surface. Design-time blocking, meaning a maker sees an error while building a flow or app rather than discovering the failure at runtime, is rolling out one workload at a time: Power Automate’s maker portal first, Copilot Studio next, and Power Apps’ maker portal after that. Until a given surface has design-time support, ACP still enforces at runtime there, which means a maker in Power Apps today can build and save a canvas app referencing a blocked connector and only find out it doesn’t work when the app actually runs. That’s a materially different experience from the flow-checker warning a Power Automate maker gets today, and it’s worth setting expectations accordingly with any citizen developer population still working primarily in Power Apps.

A Practical Migration Sequence

The organizations getting this right aren’t treating ACP as a lift-and-shift replacement for their existing DLP policy set. They start with an audit of what their current classic policies actually enforce, separating that into a certified-connector allowlist that can move to ACP and a residual set of custom-connector, HTTP endpoint-filtering, and virtual-connector rules that has to stay in classic DLP indefinitely. From there, building the ACP allowlist environment-group by environment-group, publishing it in mixed mode, and giving it real usage time before considering ACP-only mode avoids the failure pattern of flipping a switch tenant-wide and finding the gaps through a flood of support tickets. It’s also worth reconciling allowed-connector lists periodically through the Power Platform API rather than the admin UI alone, since retired or invalid connector IDs accumulate in a policy’s configuration and throw off the connector count the UI reports without actually blocking anything.

One operational gotcha worth flagging before it surprises anyone: removing an ACP rule from an environment group does not automatically remove that policy from environments that already inherited it, and removing an environment from a group retains whatever ACP configuration it last had rather than reverting to unrestricted. That’s a deliberate design choice to prevent a connector from becoming unexpectedly available during a reorganization, but it means offboarding an environment from group-based governance requires an explicit cleanup step, not just a drag-and-drop out of the group.

None of this makes classic DLP obsolete, at least not on any announced timeline, and treating ACP’s June GA as a mandate to migrate everything immediately would be a mistake for any tenant with meaningful HTTP or custom connector usage. What it does change is the ceiling on how precisely certified-connector access and AI agent tooling can be governed, and for tenants running large numbers of managed environments, that precision is the difference between a policy set someone can actually audit and one that quietly drifts for eighteen months until an admin loses an afternoon tracing it. We’ve walked several clients through exactly this audit-first sequencing this year, and the pattern holds regardless of tenant size: know what you’re moving before you touch the switch.

#AdvancedConnectorPolicies #PowerPlatformGovernance #DataLossPrevention #MCPGovernance #ConnectorSecurity #EnterpriseAI

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

The Power Pages Security Model Is Changing. Your Table Permissions Still Need an Audit.

IT security professional reviewing an abstract portal permissions and access-control dashboard on a widescreen monitor

A CIO at a mid-size insurer found out about the problem during a routine vendor risk review, not from an internal alert. A claims-intake portal built two years earlier by a business analyst on the operations team, using Power Pages because it was faster than waiting for a developer sprint, had an Anonymous Users role configured with Global Access read permission on a table that included policyholder contact information. Nobody had touched the site’s permissions since launch. Nobody on the security team had reviewed it either, because it had never appeared on a list of applications anyone was tracking. That is the quiet risk of low-code external portals: they get built quickly, they work, and they slip out of the governance perimeter that would normally catch a misconfiguration like this one. It is also the backdrop against which every CIO should be reading Microsoft’s current overhaul of the Power Pages security model, because the two changes underway solve different halves of that same problem.

This is not a hypothetical. In late 2024, researchers at AppOmni disclosed that a large number of Power Pages sites across industries, including a UK National Health Service contractor, were exposing sensitive data because of exactly this pattern: table permissions granted at Global Access to the Anonymous Users or Authenticated Users role, on sites where self-registration meant “authenticated” effectively meant “anyone who signed up.” One case alone reportedly exposed contact information for more than a million people. Microsoft’s own documentation on table permissions has warned about this since Power Pages existed under its earlier name, but the setting is easy to get wrong and easy to forget about once a site is live.

Two Different Problems Wearing the Same Name

Microsoft’s response to date has taken two distinct forms, and it is worth CIOs and IT directors being precise about which one solves which problem, because the two get conflated in vendor briefings more often than they should.

The first is a genuine security tool: the Security Scan and Security Hub capability, which reached general availability in the back half of 2025. It scans a site’s configuration and flags the exact patterns AppOmni’s researchers were finding by hand, such as Anonymous or Authenticated roles with unusually broad table access. This is the tool that actually catches the problem described above, and if your organization has Power Pages sites in production and has not run this scan against every one of them, that is the first governance action to take this quarter, independent of anything else in this article.

Abstract close-up of a laptop screen showing a glowing network authorization diagram with role and permission nodes

The second is architectural, and it is easy to mistake for a security fix when it is really a plumbing change. Power Pages has always run two separate authorization systems side by side: Web Roles, which govern what a portal visitor can see and do on the site itself, and Dataverse Security Roles, which govern access to the underlying data. They were related but not unified, which meant a portal’s activity in Dataverse was historically attributed to a shared application user rather than the individual who was actually signed in, and administrators had to document, reason about, and troubleshoot two parallel permission models for the same site. Starting with a preview that shipped July 8, 2026 and targeted for general availability in November 2026, Microsoft is merging the two: each Power Pages user is now represented as both a Dataverse Contact and a Dataverse System User, and each Web Role maps directly to a corresponding Security Role. When a portal visitor calls Dataverse, the request now carries that visitor’s own identity rather than a generic service account.

What Changes in the Power Pages Security Model, and What Doesn’t

For a CIO evaluating whether this matters, the honest answer is that it is a governance quality-of-life improvement, not a vulnerability patch. The practical benefits are real but specific. Audit trails improve meaningfully, because actions taken through a portal now show up in Dataverse tied to the actual visitor rather than a shared identity, which matters for any organization that has to answer a compliance question like “who accessed this record and when.” Administrative overhead drops somewhat, because a security team no longer has to maintain a mental model of two loosely coupled permission systems and explain the seams between them to auditors or new hires. And because Microsoft describes this as a structural consolidation rather than a breaking change, existing sites are not expected to require a manual permissions migration when the rollout reaches them.

What it does not do is retroactively fix an Anonymous role that already has Global Access to a sensitive table, add column-level masking to a site that never configured it, or catch a wildcard entry in a site’s Web API field allowlist. Those are governance decisions, made by whoever configured table permissions when the site was built, and they persist through the unification exactly as they were. A cleaner, more auditable authorization backbone makes it easier to see a bad permission grant once someone goes looking for it. It does not go looking on its own.

What This Means for the Portal Sitting in Your Environment Right Now

If your organization has any Power Pages sites in production, three actions are worth taking before the November GA date, not because the unification itself is risky, but because it is a natural forcing function to finally do the review that should have happened at launch.

Start with an inventory question that is more often skipped than answered: does IT actually have a current list of every Power Pages site running in the tenant, who built it, and what data it touches? Citizen-developer tools succeed precisely because they let business teams build without waiting on IT, which also means those teams do not always think to tell IT what they built. A Power Platform Center of Excellence setup, or even a simple quarterly export from the admin center, closes this gap cheaply.

From there, run the Security Scan against every site on that list and treat any Global Access finding on the Anonymous or Authenticated role as a same-week fix, not a backlog item. Pair that with a manual check the automated scan will not catch on its own: whether column-level security profiles are configured on any table that includes personally identifiable information, since AppOmni’s testing found this control essentially unused across every site they reviewed, scanned or not.

Finally, treat the unification’s traceability improvement as an opportunity rather than a compliance checkbox. Once portal actions in Dataverse are attributed to individual users instead of a shared application identity, that data becomes genuinely useful for security operations and for internal audit, but only if someone owns pulling and reviewing it. Assign that ownership now, while the change is still new, rather than assuming a dashboard will surface it automatically.

We have run this exact audit sequence, security scan first, then a manual table-permission and column-security review, for several clients ahead of their own Power Pages authorization changes this year, and the pattern holds every time: the sites that fail are the ones nobody had looked at since the day they launched. A consolidated security model makes that oversight easier to catch. It does not make it disappear on its own, and the organizations that treat the two as the same thing are the ones that will still be explaining an exposure to their board next year.

#PowerPages #PowerPlatformGovernance #DataverseSecurity #CitizenDevelopment #DataProtection #DigitalTransformation