Power Platform Agent Authentication Governance Reaches GA: What to Audit First

An IT administrator reviewing an agent identity and access governance dashboard on a large office monitor

A CISO at a mid-market manufacturer asked her Power Platform admin a simple question last month: how many Copilot Studio agents does the organization actually have running, and how many of them require anyone to prove who they are before they can use them? The admin came back three days later with a spreadsheet of 214 agents. Nineteen had “No authentication” configured. Four of those nineteen had access to a knowledge source containing vendor contract terms. Nobody remembered turning authentication off for any of them, because nobody had turned it on to begin with. It had simply never been set. That gap is exactly what Power Platform agent authentication governance, which reached general availability this month, was built to close.

Microsoft has been describing this exact scenario in its own guidance for a while. In a February 2026 security post, Microsoft described unauthenticated agents as a recurring pattern rather than an edge case: authentication gets “deactivated for testing, left in its default state, or misunderstood as optional,” and the result is an agent that anyone with a link can use, sometimes surfacing internal information through its topics, actions, or knowledge sources without anyone intending it to. The fix Microsoft has been building toward arrived this month, and it changes who is responsible for catching this problem before it reaches production.

What Power Platform Agent Authentication Governance Actually Does

The feature reached general availability on September 2, 2026, after a public preview that opened in late May. Listed in Microsoft’s release plan as “Manage agent security with enhanced admin controls,” it gives administrators a way to set authentication and access policy for agents centrally, at the environment or environment group level, inside the Power Platform admin center. Rather than relying on individual makers to choose the right authentication setting each time they build or republish an agent, an admin can now require Microsoft Entra ID authentication across a group of environments, permit a defined list of approved external identity providers for agents that genuinely need one, or block anonymous access outright.

The detail that matters most for a governance program is when these policies get enforced. This is not a design-time warning that a maker can dismiss and move past. Microsoft’s own documentation describes the policy as evaluated both when an agent is deployed and again at runtime, so a policy change made after the fact actually reaches agents that are already published, not just new ones being built going forward. That closes a gap that has existed in Copilot Studio governance for a while: DLP data policies could already restrict unauthenticated usage at the tenant level, but that control was blunt. It did not give admins a way to say, for example, that the environment group serving finance requires Entra ID, while a separate environment group hosting a public-facing customer service agent is allowed to run anonymously because that is the intended design.

That distinction is worth sitting with, because the instinct after reading a story like the manufacturer’s spreadsheet is to conclude that anonymous access is always the mistake. It isn’t. A number of legitimate agents, particularly ones embedded in Power Pages sites or public marketing properties, are supposed to be reachable without a sign-in. The problem in most organizations is not that anonymous agents exist. It is that nobody made a deliberate decision about which ones should, and the setting drifted in by default rather than by design.

Abstract illustration of glowing padlock and key icons connected in a network, representing agent identity and access governance

Why This Became Urgent Now

The timing lines up with a broader shift that most IT leaders are already tracking anecdotally even if they haven’t quantified it. Citizen-developer agent creation in Copilot Studio has grown faster than most organizations’ governance processes have kept pace with, and a maker publishing an agent from a template or a quick prototype rarely stops to think about identity architecture. Microsoft’s guidance on securing Copilot Studio deployments at scale describes a zoned model, where agents built by citizen developers are expected to carry the least privilege and the most constrained data access, and where authentication choices become progressively more deliberate as an agent moves toward professional development and broader distribution. Enforcement has lagged the model. Before this release, an admin who wanted to guarantee that zone boundaries actually held had to lean on DLP connector policies and manual audits, neither of which was built specifically to answer the authentication question.

There’s also a compliance dimension that will matter more to some organizations than others. Regulated industries, healthcare, financial services, and any company subject to a SOC 2 or ISO 27001 audit cycle have been fielding questions from auditors about AI agent access controls for a while now, often without a clean answer. A centrally enforced authentication policy, applied at the environment group level and demonstrably active at runtime rather than merely recommended at build time, gives those organizations something concrete to show. It is the difference between telling an auditor that agents are supposed to require authentication and showing them a Power Platform admin center screen where that policy is actually configured and enforced.

What to Audit Before You Roll This Out

The rollout sequence matters more than the feature itself, and getting it backwards creates its own incident. The first step is the one the manufacturer’s CISO already took: get a current inventory of every agent in the tenant and its existing authentication setting, broken down by environment. Most organizations doing this for the first time are surprised by the count, and a meaningful share of that surprise usually comes from test or proof-of-concept agents that were never decommissioned rather than from production systems.

Once the inventory exists, the harder work is deciding environment group boundaries before applying policy, not after. An environment group that mixes internal line-of-business agents with a customer-facing Power Pages chatbot forces an uncomfortable compromise: either weaken the policy to accommodate the anonymous agent or break a legitimate public integration. Splitting those into separate environment groups first, then applying a strict Entra ID requirement to the internal group and an explicit, reviewed exception for the external one, is the pattern that avoids both outcomes.

It is also worth coordinating this rollout with whoever owns DLP policy in the organization, since the two controls now overlap in purpose even though they operate at different layers. A tenant-wide DLP restriction on unauthenticated connector usage and an environment-group-level authentication requirement can either reinforce each other or produce confusing, hard-to-diagnose failures if they are configured without reference to one another. Treating this as a single governance conversation, rather than two separate admin tickets handled by different people, avoids that outcome.

Finally, this is a good moment to revisit whichever Center of Excellence process the organization uses to track agent inventory and ownership, since an authentication policy is only as good as the organization’s ability to know when a new agent shows up outside of it. The policy catches misconfiguration. It does not catch an agent nobody knew existed until the inventory audit runs again.

The Practical Takeaway

None of this requires a large project to act on immediately. A first pass, an inventory of current agents and their authentication settings, a decision about which environment groups genuinely need anonymous access and which don’t, and a staged policy rollout starting with the highest-risk internal environment group, is realistic within a normal sprint or two for most Power Platform admin teams. What changes with this GA release is that the tool for enforcing the decision now exists natively, rather than requiring a workaround built from DLP policies never designed for this specific job.

Routeget Technologies has been walking clients through Copilot Studio governance reviews since well before this feature existed, largely because the underlying problem, agents accumulating faster than anyone tracks their authentication posture, predates any specific Microsoft release. The general availability of centralized agent authentication governance does not solve that problem by itself. It gives the teams already paying attention to it a real lever to pull, and it gives the teams who haven’t started yet a clear, specific reason to.

#CopilotStudio #PowerPlatformGovernance #AgentAuthentication #AIGovernance #EnterpriseAI #DataLossPrevention

Dynamics 365 Service Agent Reached GA. Your Budget Approval Was for the Wrong Number.

A business technology leader reviews a customer service AI analytics dashboard on a large office monitor

A customer service VP at a mid-size distributor got budget sign-off in August for next year’s Dynamics 365 Customer Service renewal, including a line item for “AI capabilities” that her team had been piloting since spring. Then her IT director came back with a different number. Turning on Dynamics 365 Service Agent, the interactive AI layer Microsoft folded into Microsoft 365 Copilot this summer, wasn’t a checkbox inside the Customer Service license she’d already budgeted for. It was a second license, a consumption meter, and a rollout plan that touched roles, queues, and app modules she hadn’t scoped at all.

That gap between what leaders assume “enabling Copilot” costs and what it actually requires is becoming a recurring theme across the Dynamics 365 ecosystem, and Service Agent is a particularly clean example of it, because the feature itself is genuinely useful. The problem isn’t the capability. It’s that the licensing and governance model behind it doesn’t map cleanly onto how most organizations already budget for customer service technology.

What Dynamics 365 Service Agent Actually Does Differently

Dynamics 365 Customer Service has had AI-assisted features for a while: case summarization, suggested knowledge articles, sentiment flags. Service Agent, which reached general availability on June 30, 2026, is a different kind of thing. Microsoft describes the shift as moving from a tool that answers and summarizes to one that reasons and acts, and the distinction holds up in practice. Instead of surfacing a suggestion inside the Customer Service workspace, Service Agent operates through more than 90 Model Context Protocol tools that let a service representative, or a supervisor, update a case, reassign it, draft and send a reply, pull the next item from a queue, or generate a coaching note, all from inside Microsoft 365 Copilot itself. That means Teams, Outlook, and the Copilot chat surface, not just the Dynamics 365 application.

The practical effect is that a rep no longer has to open the Customer Service workspace to get value from the AI. A supervisor can ask Copilot in Teams for SLA exposure across a queue and get an answer grounded in live Dataverse case data, then reassign three at-risk cases without leaving the conversation. Microsoft’s own reference customer, Northern Trust, framed the change as moving from reactive search to proactive intelligence, which is a fair description of what changes when action, not just information, becomes available inside a chat interface.

That is a meaningfully different product than the Case Management Agent capability covered in this publication’s prior look at autonomous email resolution. That feature handles inbound email triage and resolution on its own, largely without a human in the loop for routine requests. Service Agent is closer to a force multiplier for people who are still doing the work, giving them a faster path to the same actions they’d otherwise take by clicking through the workspace. Both features draw on the same underlying AI infrastructure and the same consumption-based billing, which is exactly why they need to be budgeted together rather than as separate, unrelated line items.

The License Stack Nobody Scopes on the First Pass

Getting Service Agent in front of a customer service team requires three separate commercial commitments, and skipping any one of them stalls the rollout partway through.

The first is the Dynamics 365 Customer Service license itself, at Enterprise or Premium edition, which is what grants access to the underlying case data, knowledge base, and workflow engine that Service Agent reads from and writes to. Most organizations already have this if they’re running Customer Service at any scale, so it rarely surprises anyone.

The second is a Microsoft 365 Copilot license, and this is where the August budget conversation usually goes sideways. As of the licensing consolidation Microsoft rolled out in October 2025, the M365 Copilot license at thirty dollars per user per month now includes what used to require a separate twenty-dollar Copilot for Sales, Service, and Finance add-on on top of a fifty-dollar bundled SKU. That’s a genuine simplification from where the pricing sat a year earlier, but it doesn’t change the fact that every representative or supervisor who needs the integrated Service Agent experience, meaning access from Teams and Outlook rather than only inside the Dynamics 365 workspace, needs this license in addition to their Customer Service seat. For a fifty-person service organization, that’s an incremental cost that has to be modeled explicitly rather than assumed to already be covered by whatever Customer Service tier they’re on.

The third layer is consumption-based: Copilot Credits, which meter usage of the premium tools inside Service Agent’s toolset, on top of whatever is included in the base licenses. This requires a Power Platform pay-as-you-go plan with an attached Azure subscription, which in most enterprises means a separate procurement conversation with whoever owns the Azure relationship, not the team that owns the Dynamics 365 or Microsoft 365 contract. Organizations that have already gone through this exercise for the Case Management Agent’s autonomous email resolution feature have a head start, since the billing infrastructure is the same. Organizations tackling Service Agent as their first Copilot Credits commitment are effectively standing up a new procurement process from scratch, and that process alone can take longer than the technical rollout.

None of this is disclosed as a single number anywhere in Microsoft’s GA announcement, because it can’t be. Actual cost depends on how many representatives get the integrated experience versus a Customer-Service-only rollout, and how heavily premium tools get used once it’s live. That’s a reasonable design choice given how differently organizations will deploy this, but it means the budgeting exercise has to happen internally, with IT, finance, and the service organization in the same room, before a number goes to a steering committee.

Abstract illustration of stacked translucent layers representing tiered software licensing above a glowing customer service headset icon

Governance Controls That Make a Phased Rollout Realistic

The part of Service Agent’s design that deserves more credit than it gets is the rollout mechanism itself. Microsoft built in role-based access at three levels of granularity: per role, per application module, and per queue, and every one of those controls is reversible. That means an organization doesn’t have to choose between an all-or-nothing switch and doing nothing at all.

In practice, this supports a pilot pattern that’s more disciplined than what most AI rollouts get. A service leader can enable Service Agent for a single queue handling a well-understood, lower-risk category of requests, watch how representatives actually use the action-taking tools versus the summarization ones, and expand module by module rather than committing the entire service organization to an integrated experience on day one. Running the new experience side by side with the existing Customer Service workspace, rather than replacing it outright, gives teams a genuine off-ramp if adoption or accuracy doesn’t meet expectations in a given queue.

That control granularity is also what makes the licensing conversation tractable. Instead of asking “how many M365 Copilot licenses does the whole service organization need,” the real question becomes “which roles and queues justify the incremental license and credit consumption in phase one,” which is a much smaller number to defend to finance and a much easier one to revise later.

What to Settle Before the Next Budget Cycle

Before committing spend to a broader Service Agent rollout, it’s worth resolving three questions concretely rather than deferring them to the implementation team. First, determine how much license overlap already exists: any representatives who already hold M365 Copilot seats through other departments or through the Sales and Finance Copilot consolidation don’t need a second license, and that overlap can materially change the incremental cost. Second, get a real consumption estimate for Copilot Credits from a pilot queue before assuming what full deployment will cost, since usage patterns for action-taking tools tend to run higher than for pure summarization once representatives get comfortable with them. Third, decide who owns the Azure and Power Platform pay-as-you-go relationship before the rollout stalls waiting on a procurement approval that nobody flagged early enough.

Service Agent is a legitimate step forward for how customer service teams work inside Dynamics 365, and the reversible, granular rollout controls are a genuinely well-designed answer to the usual all-or-nothing AI adoption problem. The organizations that get the most value from it are the ones that treat the licensing stack as part of the technical evaluation from the start, not as a surprise that shows up after the pilot already has executive attention. That’s the pattern Routeget Technologies has seen repeatedly across Dynamics 365 AI rollouts: the technology rarely disappoints, but the budget conversation that should have happened in parallel with the pilot usually happens after it, and that sequencing is what turns a good capability into a frustrating procurement delay.

#ServiceAgentGA #CopilotLicensing #DynamicsCustomerService #CustomerServiceAI #CopilotCredits #ITBudgetPlanning

The Dataverse Git Integration GitHub Preview Needs a Key Vault, Not Just a Login

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

A Power Platform ALM engineer at a mid-market manufacturer spent a Tuesday afternoon trying to move a client’s Dataverse Git integration off Azure DevOps and onto GitHub, where the rest of the company’s engineering org already lived. The Azure DevOps connection had taken fifteen minutes to set up the year before: sign in, pick a project, pick a repository, done. She assumed GitHub would be the same flow with a different login screen. Four hours, one Azure Key Vault resource, one GitHub App registration, and one role assignment to a service principal she’d never heard of later, she had a working connection, and a much clearer idea of why Microsoft shipped Azure DevOps support first.

That gap between expectation and reality is worth understanding before any team commits to the GitHub option, because it is not a bug or an oversight. It reflects a real architectural difference in how the two providers authenticate, and it changes the planning and staffing conversation for anyone treating this as a same-day migration.

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

What Dataverse Git integration actually does

Dataverse Git integration is Microsoft’s native, in-product answer to a problem that Power Platform teams have patched around for years: getting solution components out of an environment and into a real source control history without standing up a full pro-dev toolchain. Instead of relying solely on the Power Platform CLI, Azure Pipelines, and a developer’s local machine to export, unpack, and commit solution XML, makers and admins can now connect an unmanaged solution directly to a Git repository from inside make.powerapps.com, commit changes as they’re made, and let Power Platform Pipelines handle promotion to test and production from there.

The mechanics matter because they explain the limits. Only unmanaged solutions in development environments connect to Git; managed solutions still move downstream through Power Platform Pipelines, not through branch merges. Component changes sync to a human-readable, YAML-based file format designed to diff cleanly, a deliberate departure from the sprawling XML that classic solution exports produce. And a full solution commit is atomic: you cannot cherry-pick individual component changes within a solution the way you would stage individual files in a typical Git workflow. Teams coming from a code-first background, expecting Git semantics all the way down, tend to hit that ceiling first.

Azure DevOps was the first provider Microsoft supported, and it reached general availability well ahead of GitHub. The connection setup leans on infrastructure Azure DevOps and Dataverse already share inside the same Microsoft Entra tenant: create a project with Git version control enabled, confirm the connecting user has Contributor access to the repository, enable managed environments on both the source and target environments, and connect from the solution’s source control panel. There is no separate secrets store to provision and no custom application registration required, because the trust relationship rides on existing Azure identity.

Why the GitHub path looks different

GitHub support entered public preview in the 2026 release wave 1 cycle, and the setup reflects the fact that GitHub sits outside the Azure AD trust boundary that made the Azure DevOps connection comparatively simple. Rather than a native OAuth handshake alone, the documented path requires registering a dedicated GitHub App under organization settings, granting it read-and-write access to repository contents, generating a private key for that app, and then storing that key somewhere Dataverse can retrieve it securely. That somewhere is Azure Key Vault, in the same Microsoft Entra tenant as the Dataverse environment, which means a team without an existing Key Vault footprint is now standing one up specifically to support source control.

Abstract illustration of a secure vault connected to a code repository network and a cloud identity shield, representing credential management between GitHub and Dataverse

The chain continues from there. After the private key lands in Key Vault, the environment’s own managed identity, provisioned automatically as something like PPMI-githubappconfigmanagedidentity followed by a GUID, needs the Key Vault Crypto User role assigned to it through Key Vault’s access control settings before Dataverse can actually use the stored credential. Only after that RBAC assignment resolves does the GitHub connection in the solution’s source control panel have what it needs to authenticate. None of this is exposed as a single wizard; it’s a sequence across GitHub’s developer settings, the Power Apps maker portal’s Connections page, and the Azure portal, and a missed step in any of the three stops the whole chain cold with a generic authentication failure that doesn’t point back to which link broke.

Two additional constraints are worth flagging before a team plans around this path. GitHub-based connections are not currently compatible with Dataverse environments that have virtual network support enabled; if VNET injection is part of your environment’s security posture, the documented workaround is a GitHub personal access token instead of the OAuth connection, which trades one credential management problem for another. And if the organization has restrictions on third-party OAuth application access, which many regulated enterprises do by default, an org admin has to explicitly approve the GitHub App before any maker can complete the connection, adding an approval-queue dependency that Azure DevOps setups don’t carry.

Planning the rollout instead of the demo

None of this makes the GitHub option a bad choice. For an organization that has already centralized its application source, its pull request review culture, and its CI/CD runners around GitHub, keeping Power Platform solutions in a second, Azure DevOps-only silo creates its own governance problem: two source control systems, two access review processes, two places an auditor has to look. The GitHub preview closes that gap. It just closes it with real infrastructure work attached, not a checkbox.

Two prerequisites tend to get discovered late rather than planned for. Managed environments must be enabled on every environment in the chain, development and target alike, and that entitlement itself is included at no extra cost with standard Power Apps, Power Automate, Copilot Studio, Power Pages, and Dynamics 365 licenses, but explicitly excluded from the Developer Plan. A team piloting this in a free developer environment will hit a wall before they hit the GitHub App registration screen. Second, this is explicitly documented as a preview capability intended for development environments only, not test or production, so any rollout plan that assumes it is production-ready today is planning against documentation that says otherwise.

The practical sequencing that avoids the four-hour surprise looks like this: confirm managed environments are already enabled or budgeted for, decide up front whether VNET requirements in any target environment rule out the OAuth path in favor of a PAT, and treat the GitHub App registration, Key Vault provisioning, and managed identity role assignment as three discrete, ownable tasks rather than one setup step, ideally assigned to whoever already owns Key Vault and Entra app registrations in the organization rather than the Power Platform maker who happens to be doing the connecting. Teams that scope it that way tend to get through it in an afternoon. Teams that treat it like the Azure DevOps flow tend to get the same four-hour afternoon the engineer in the opening scenario had, just with more frustration attached.

Routeget Technologies has walked several clients through exactly this kind of ALM tooling decision, usually as part of a broader review of where Power Platform governance sits relative to the rest of an organization’s engineering practices. The right answer isn’t universally GitHub or universally Azure DevOps; it’s whichever one matches where the organization’s source of truth already lives, evaluated with the actual setup cost in view rather than the marketing description of “now supports GitHub.”

For architects scoping this now, the preview label matters less than the identity and secrets infrastructure it assumes you’re willing to stand up. If that infrastructure already exists in your tenant, the GitHub path is a reasonable few hours of work. If it doesn’t, budget for building it before you budget for the migration itself.

#DataverseGitIntegration #PowerPlatformALM #GitHubIntegration #EnterpriseDevOps #ITGovernance #PowerPlatform

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

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’s Outlook Integration Deadline Is October 1, 2026

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

An IT Director at a distribution company we work with found out about this deadline the way most people do: from a support ticket, not a Microsoft email. A sales rep’s Outlook add-in stopped letting her attach a quote from Business Central mid-thread, and the contact she’d synced from BC to Outlook six months ago had quietly vanished from the folder it used to sit in. Nothing had changed on her machine. What had changed was that her company’s Business Central environment was still two release waves behind, and Microsoft had already started tightening the plumbing underneath a feature nobody in IT had flagged as fragile.

That plumbing is Exchange Web Services, the aging protocol Outlook add-ins and contact sync in Business Central have leaned on for over a decade. Microsoft is retiring it, and the resulting Outlook integration deadline that Business Central’s own product team has set is considerably firmer than the platform-wide retirement schedule most IT leaders have heard about. If your organization runs Business Central and anyone in sales, purchasing, or accounting touches customer or vendor contacts through Outlook, this is worth twenty minutes of your attention before the end of the month.

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

What’s Behind the Outlook Integration Deadline

Exchange Web Services, usually shortened to EWS, is the API that has quietly connected Outlook to a long list of Microsoft and third-party applications since the mid-2000s. Microsoft first announced its deprecation back in 2018, but the timeline accelerated meaningfully after the Midnight Blizzard security incident in January 2024 pushed the company toward faster retirement of legacy authentication and API surfaces across Exchange Online. The result, as published by the Exchange engineering team, is a phased shutdown: EWS begins to be disabled globally starting in October 2026, with full disablement across all tenants by April 2027.

Business Central’s product group didn’t wait for that full window to close. Because the older Exchange-based contact synchronization and Outlook add-in deployment in Business Central depend directly on EWS calls, the team attached a much nearer deadline to its own 2026 release wave 1 features: organizations need to be on Business Central version 28.0 or later, and Microsoft has stated plainly that after October 1, 2026, Outlook add-in functionality and contact sync built on the older Exchange connection may stop working in earlier versions. That is a considerably tighter window than the broader EWS retirement calendar, and it is the one that actually matters if you’re planning around this.

What Breaks in Practice, Not in Theory

For a company still running a pre-28.0 version, the practical failure points are the ones your sales and finance teams touch daily rather than anything IT usually monitors. The Outlook add-in that lets a salesperson pull up a customer’s Business Central record, attach a quote, or check open invoice balances without leaving their inbox depends on that Exchange connection to authenticate and retrieve data. The legacy Exchange Sync. Setup page, which many mid-market Business Central customers configured years ago and then never touched again, uses EWS to keep a “Business Central” folder of synced contacts current in each user’s Outlook. Automatically tracking email correspondence against a customer record, a feature accounting and account management teams tend to rely on more than they realize until it’s gone, runs through the same plumbing.

None of this fails with a dramatic outage. It fails quietly: an add-in that used to load now times out, a contact that used to sync now sits stale, an email that used to log itself against a customer record now just sends. That’s a worse failure mode for a CIO to manage than a hard outage, because it doesn’t generate an incident ticket. It generates a slow trickle of user complaints that get diagnosed as one-off glitches for weeks before anyone connects them to a platform deprecation that IT technically knew about.

Abstract visualization of data synchronization flowing between two connected systems on a laptop screen

What Version 28 Actually Replaces It With

Business Central 2026 release wave 1, generally available since April 1, 2026 and auto-enabled for all users on that version, rebuilds this integration on Microsoft Graph instead of EWS. The most visible change is a new “Synchronize with Outlook” action added directly to the Contacts list, which copies selected contacts from Business Central into Microsoft 365, making them usable in both Outlook and Teams. Unlike the old Exchange Sync. Setup configuration, which required a separate admin setup flow and validated an Exchange connection before anything would sync, this action sits where sales and account teams already work, and it supports syncing in either direction if an organization wants contacts created in Outlook to flow back into Business Central.

The other change worth flagging to your security and IT operations teams directly is that Outlook add-in installation now requires a one-time additional setup step to verify the account, a deliberate friction point Microsoft added for account protection reasons rather than a bug. If your organization uses centralized deployment to push the Business Central add-in to users automatically rather than relying on individual installs, that deployment process still works, but the added verification step means it is worth testing the rollout against a pilot group rather than assuming a push that worked in 2025 will behave identically in 2026.

Who Is Actually at Risk

If your Business Central environment is a standard SaaS deployment on Microsoft’s evergreen update cadence, there’s a reasonable chance you’re already on version 28.0 or close to it, since Microsoft pushes two release waves a year to every SaaS tenant on a schedule customers don’t fully control. The organizations that should be checking their version today rather than assuming they’re covered fall into a narrower but not small group: companies running Business Central on-premises, where upgrades are a deliberate IT project rather than an automatic platform event; companies that migrated from Dynamics GP, NAV, or SL in the last two years and may still be running an early post-migration version they haven’t touched since go-live; and any organization that has deliberately delayed a release wave update because of a customization or third-party integration compatibility concern, which is common enough in manufacturing and distribution environments with heavily extended BC implementations.

Checking your version takes a few minutes: in Business Central, the Help and Support page shows the current version and build number directly, and any IT Director who can’t answer “what release wave are we on” from memory should treat that itself as a minor governance gap worth closing regardless of this specific deadline.

What to Do Before October 1

The organizations that will sail through this deadline without incident are the ones treating it as a two-part check rather than a single upgrade task. The first part is confirming the Business Central version itself, since anything at 28.0 or later already has the Graph-based integration and doesn’t need to do anything further beyond being aware the old Exchange Sync. Setup pages are being phased out and shouldn’t be reconfigured going forward. The second part, and the one that gets missed, is validating that Outlook add-in deployment and any automated email-tracking workflows actually work end to end after an upgrade, not just that the version number changed. An upgrade that technically completes but leaves the add-in’s new security verification step unaddressed for most users produces the same quiet failure pattern as not upgrading at all, just with a shorter fuse. For any organization using EWS-dependent integrations beyond Business Central itself, Microsoft’s own EWS Usage Reports in the Microsoft 365 admin center are worth a look this month, since Business Central is rarely the only application in a tenant still calling that API.

None of this requires a large project. It requires someone in IT confirming a version number, someone in sales or finance confirming the add-in still authenticates cleanly, and roughly three weeks of runway that is shrinking by the day. Routeget Technologies has walked several clients through exactly this check in the past month, and in every case the fix was smaller than the anxiety the deadline initially produced, provided someone looked at it before October 1 rather than after.

#BusinessCentral #OutlookIntegration #ExchangeWebServices #ERPGovernance #Microsoft365Integration #DynamicsMigration

Standard vs Custom Dataverse Tables: The Schema Decision That Compounds

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

A solution architect reviewing a Dataverse environment for a mid-market industrial services client recently found three separate custom tables, each carrying a different prefix from three different implementation phases, all describing the same thing: a physical site where equipment lived. One had been built by an internal power user modeling “Locations.” Another arrived bundled with an asset management add-on that already shipped a standard table for exactly this purpose. A third was created eighteen months later by a consulting partner who never checked whether either of the first two existed. None of the three synced with each other. Field technicians updated one, finance reported from another, and a Copilot Studio agent built the following year queried a fourth table that didn’t even have the data anyone actually needed.

This is not an unusual story. It is close to the default outcome when the standard vs custom Dataverse tables decision gets made under sprint pressure by whoever is in the room that week, without anyone asking a simple question first: does a standard table already do this?

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

Why the standard vs custom Dataverse tables decision is easy to get wrong

Dataverse ships with hundreds of standard tables (Account, Contact, and Case are the obvious ones, but plenty of others arrive silently through installed solutions like Asset Management, Project Operations, or Customer Service) built on the Common Data Model, Microsoft’s shared schema for representing common business concepts consistently across apps. These tables carry no prefix. A custom table, by contrast, always carries one, whether that’s a publisher prefix like cra_ or a legacy new_. That naming convention is the fastest way to tell which category a table belongs to, but it only helps if someone actually looks.

The reason teams skip that check is rarely laziness. It is usually that building a new custom table feels faster and safer than researching whether a standard one already covers the need, especially early in a project when the backlog is long and the standard table’s full column list and relationship graph aren’t obvious from a quick glance at the maker portal. The problem is that this shortcut doesn’t cost you anything visible in week one. It costs you eighteen months later, when a Fabric Link migration, a cross-application integration between Finance and Operations and Customer Engagement, or a Copilot Studio agent expects the canonical CDM entity and instead finds three partial, disconnected substitutes.

What actually distinguishes standard, custom, and virtual tables

The decision isn’t really binary. There are three categories worth holding in mind, and each answers a different question about who owns the data’s lifecycle.

Standard tables are the right choice when Dataverse itself is the authoritative source for that data and the concept maps to something Microsoft has already modeled: a contact, an account, a case, a work order. Even when a standard table doesn’t fit perfectly out of the box, most standard tables are customizable, meaning you can add columns, choices, and relationships to extend them without forking the concept into a parallel structure. Extending a standard table keeps every existing app, flow, security role, and future Copilot agent that already understands that entity working correctly, because they’re still querying the same canonical table, just with a few more fields on it.

Custom tables earn their place when the data genuinely doesn’t correspond to anything in the Common Data Model and is specific to how your organization actually operates: an internal certification tracking table, a custom approval matrix, something with no reasonable standard analog. The mistake isn’t creating custom tables. It’s creating one before checking whether the concept already has a home.

Virtual tables solve a different problem entirely: they matter when an external system, not Dataverse, remains the true owner of a record’s lifecycle. A virtual table stores only metadata in Dataverse and queries the external source (an ERP system, a warehouse management platform, a legacy line-of-business database) live, through a data provider. This matters more than it sounds like it should, because the alternative, replicating that external data into a standard or custom Dataverse table on a schedule, introduces a staleness window that can turn into a real operational failure. If a warehouse system shows zero units on hand but the last Dataverse sync ran six hours ago and still shows ten, a sales rep can quote stock that doesn’t exist, and the order gets canceled after the customer has already been told it’s on the way. Virtual tables avoid that gap by not caching the data at all, at the cost of depending entirely on the external system’s availability and performance for every query.

Close-up of a laptop screen showing an abstract database table relationship diagram on a desk

The decision doesn’t stop at the table level

Getting the table category right is only the first layer of the structure question. Once you’ve decided a standard table is the right home for a concept, the choice columns and relationships you add to extend it are where a lot of the same discipline quietly gets abandoned. A choice column added to the standard Case table to capture an industry-specific status, for instance, is a reasonable extension. A parallel custom table built solely to hold a lookup list of those same statuses, connected back to Case through a one-to-many relationship that duplicates logic the choice column could have handled directly, is the same mistake as the duplicate-table problem, just one level down. Relationships matter here too: a standard table’s existing relationships to Account, Contact, or Activity records represent years of Microsoft’s own modeling work and every prebuilt view, form, and security role built around them. Recreating an equivalent relationship structure on a new custom table means none of that inherited tooling applies, and every new integration has to be taught the relationship from scratch. The pattern to watch for is simple: if you’re building a new table or relationship whose only real justification is that it mirrors something a standard table’s fields or connections already do, that’s usually a sign to extend the standard structure instead of building a parallel one next to it.

Where this decision shows up again at the platform level

Microsoft’s own tooling has started reflecting how much this decision matters beyond a single app. Guided table selection for Dataverse-to-Fabric sync, which reached general availability in March 2026, now lets administrators choose which tables get synced to Microsoft Fabric before any data movement happens, rather than syncing everything by default and cleaning up storage and compute costs after the fact. That capability is far more useful, and far cheaper to operate, when the tables being selected are standard, CDM-aligned entities that Fabric, Copilot, and cross-application processes already expect, instead of a scattered set of custom tables that each need to be individually understood, mapped, and maintained by whoever inherits the environment next.

The same logic applies to Copilot Studio agents built against Dataverse. An agent configured to reason over the standard Account or Case table benefits from every piece of existing metadata, relationship, and security context Microsoft has already built around that entity. An agent pointed at a custom table invented to avoid learning the standard schema starts from nothing, and every future integration against that data has to rediscover the same ground.

A practical check before the next table gets created

Before greenlighting a new custom table, it’s worth spending twenty minutes on three checks that would have caught the industrial services example above. First, search the environment for a standard table whose name or description plausibly matches the concept, since standard tables installed by add-on solutions often don’t surface in a maker’s mental model of “what’s already in this environment” the way tables they built themselves do. Second, if a standard table exists but seems incomplete, check whether it’s marked customizable before assuming it needs to be replaced rather than extended, since most standard tables accept new columns, choices, and relationships without any loss of the functionality that came with them. Third, before replicating any externally-owned data into Dataverse on a schedule, ask explicitly whether the business can tolerate a sync delay, because if the answer is no, a virtual table is very likely the more honest architectural choice, even though it takes more setup effort than a straightforward custom table import.

None of this is exciting work, and it rarely shows up as a line item any client asks for by name. But schema decisions are the one architectural choice in a Dataverse implementation that nobody revisits for years, which is exactly why they deserve more scrutiny at the start than they usually get. Routeget Technologies typically includes a standard-table gap analysis as one of the first steps in any new Dataverse engagement, precisely because the cost of fixing a schema mistake grows every quarter it goes unnoticed, while the cost of catching it early is measured in a single afternoon of research.

#DataverseArchitecture #CommonDataModel #PowerPlatformGovernance #DataverseSchema #FabricLink #EnterpriseDataStrategy

Configuring Parallel Archive Processing in Dataverse Long-Term Retention

IT operations team reviewing data processing and capacity dashboards in a modern operations center

A solution architect running Dynamics 365 Finance and Operations across forty legal entities kicks off an archive job for General Ledger transactions on a Friday afternoon, then checks back a week later to find eleven entities still sitting in the queue. Each job runs start to finish before the next one begins, so a single line of sequential processing does all the work no matter how much idle capacity sits behind it. That queue is a direct consequence of how Archive with Dataverse Long-Term Retention was originally built: one job in flight per scenario, and everything else waits. Microsoft’s March 2026 private preview changes that constraint, and it does so through one new configuration concept worth understanding before requesting access: the job criteria key that makes parallel archive processing possible.

Why Dataverse Archive Jobs Queue Up Today

Archive with Dataverse Long-Term Retention moves data through three stages: active, historical but retained for compliance, and eventually deleted. Getting a record from the first stage to the second is a six-step background process: replication into Dataverse, marking the source record as eligible, updating its retention status, reconciling that the copy landed correctly, migrating it out of the live table, and finally exposing it to inquiry pages that can still read history. Depending on data volume, that full cycle runs seven to fourteen days, and it runs at a deliberately low priority so it doesn’t compete with transactional workloads during business hours.

The scenarios supported today span general ledger and tax transactions in Finance, inventory transactions, inventory journals, and sales orders in Supply Chain Management, and commerce transactions in Commerce, with more expected in future releases. None of that changes with parallel processing. What changes is how many of those seven-to-fourteen-day cycles a tenant can have running at once. Until this preview, the answer was one, regardless of whether an organization operates three legal entities or three hundred. A multi-entity deployment with a genuine general ledger archiving need could watch a backlog grow for months simply because the platform had no concept of running two independent jobs side by side, even when the two jobs touched completely unrelated data.

What Parallel Archive Processing Actually Requires

The mechanism Microsoft introduced is narrower than “run everything at once.” It hinges on a job criteria key, a partition identifier assigned when an archive job contract is created. When the scheduler sees two jobs with different criteria key values, it checks whether they target non-overlapping sets of records, and if they do, it lets both run concurrently instead of forcing the second to wait. If they don’t, or if the system can’t establish that they don’t, the original sequential behavior still applies.

That non-overlap condition is stated as an absolute in Microsoft’s own documentation: each job with a different criteria key value must process a completely distinct set of records, with zero overlap. There is no partial-credit version of this feature where jobs run concurrently and reconcile conflicts afterward. DataAreaId, the field that already partitions Finance and Operations data by legal entity, is the criteria key Microsoft is leading with in preview, and it’s an obvious starting point precisely because it satisfies that zero-overlap requirement by construction. Two legal entities never share a General Ledger transaction, so keying parallel jobs off DataAreaId is close to a free performance win rather than a configuration exercise with real risk attached, provided the archival scenario itself doesn’t reach across entity boundaries somewhere a solution architect hasn’t accounted for.

Solution architect reviewing a parallel data partition and processing pipeline diagram

Configuring the Job Criteria Key

The scenario itself doesn’t change; the contract does. When an archive job contract is created, the criteria key value is set alongside the usual scope of tables and date ranges, and it’s this value the scheduler reads to decide whether two in-flight jobs can share the pipeline. In practice, that means an implementation planning parallel General Ledger archiving across, say, twelve legal entities creates twelve contracts, one per DataAreaId value, rather than a single contract configured to somehow fan out internally.

Once jobs are running, the Archive with Dataverse Long-Term Retention workspace is where the criteria key earns its keep operationally. It surfaces each job’s key value alongside its status, so an administrator can confirm at a glance that the jobs actually running in parallel are the ones intended to run in parallel, rather than discovering after the fact that two jobs quietly targeted overlapping data. For organizations building custom archival scenarios against custom tables, the sequencing matters here specifically: those custom scenarios and their criteria key logic need to be defined and validated before the first parallel job runs against them, not adjusted afterward, because the zero-overlap guarantee has to hold from the first concurrent execution onward.

Where This Can Go Wrong

The zero-overlap requirement is also where the risk concentrates. A criteria key that looks like a clean partition on paper, a custom dimension that’s supposed to map one-to-one with a business unit, for instance, can turn out to have edge cases where two values legitimately touch the same record, particularly in customized environments where table relationships have been extended past their original design. Because the preview enforces zero overlap by requirement rather than by runtime detection of every possible conflict, the burden of proving that a custom criteria key is safe sits with the team configuring it, not with the platform.

Two other details are easy to miss because they don’t show up until after a job finishes. First, capacity reporting lags the actual archival work: history table capacity reductions from automatic tuning can take up to seven days to appear, and Dataverse’s own capacity figures take up to a day to catch up. Running four jobs in parallel instead of one doesn’t make that lag disappear, so finance and IT stakeholders expecting an immediate storage win on the day parallel jobs complete need that timeline set correctly in advance. Second, organizations that use customer-managed encryption keys should know that long-term retained data lands under Microsoft-managed keys regardless of how many jobs move it there in parallel, which means a CMK migration for that retained data is a separate project, not something parallel processing resolves as a side effect. Finance and operations attachments still aren’t supported in any configuration, and while data that hasn’t yet been archived can be handled through normal processes, data that has already made the trip into Dataverse long-term retention cannot be pulled back to live tables.

Piloting Before You Commit

Because this is a private preview, access starts with an enrollment request rather than a feature flag, and the honest advice for anyone requesting it is to have a specific backlog problem in mind rather than general curiosity about the feature. Organizations with dozens of legal entities and a General Ledger or inventory transaction archive that has been queuing for weeks are the clearest fit. A three-entity organization archiving a modest transaction volume is unlikely to notice much difference between sequential and parallel processing, since the queue was never the real bottleneck to begin with.

IT and finance team reviewing a data storage capacity and governance chart

Once enrolled, the safer rollout path is to pilot parallel jobs against two or three legal entities in a sandbox first, confirm through the workspace that the criteria keys behaved as expected and that no overlap issues or data inconsistencies surfaced, and only then scale up to the full legal entity list in production. Given that archived data can’t be moved back to live tables, a misconfigured criteria key is not a mistake worth discovering at production scale. Treat the capacity reporting lag and the CMK migration question as items to raise with finance and security stakeholders during that same pilot, not after the first production jobs complete, so nobody is caught explaining an unexpected reporting delay or an encryption gap after the fact. For organizations already running Archive with Dataverse Long-Term Retention against a multi-entity Finance and Operations deployment, this preview is worth requesting now. Routeget has been helping clients sequence long-term retention rollouts around exactly this kind of phased validation, and parallel archive processing is a natural next step for any environment where the backlog, not the archive design itself, has become the actual problem.

#DataverseArchive #ParallelProcessing #LongTermRetention #DynamicsFinanceOps #DataCapacityPlanning #CloudArchitecture

Configuring Dynamics 365 Email Sensitivity Labels Without Losing Copilot

IT security and compliance professional reviewing an email data classification and encryption dashboard

A Customer Service administrator at a regulated financial services firm spent most of Q1 rolling out Microsoft Purview sensitivity labels across the organization’s email traffic, a project driven by a compliance mandate that had nothing to do with the contact center. Once Dynamics 365 email sensitivity labels went live in the Customer Service workspace, the security team considered the job done. Three weeks later, a supervisor noticed that case summaries were quietly missing for a cluster of escalated tickets, and Copilot’s intent detection wasn’t firing on a subset of inbound email at all. The two projects, security and AI, had never been evaluated together, and nobody had checked whether the feature that satisfied the compliance mandate was compatible with the feature the contact center had spent the prior year building its workflows around.

That collision is becoming common enough to plan for directly. Data sensitivity labels for email reached general availability in Dynamics 365 Customer Service on May 1, 2026, giving service representatives a native way to classify and protect outbound and inbound messages using labels defined centrally in Microsoft Purview. It is a genuinely useful capability, and for regulated industries it is close to mandatory. But it was shipped as a security feature, evaluated by security teams, and its interaction with Copilot-driven case automation is easy to miss until an agent asks why a summary never generated.

What Actually Ships With the Feature

The capability itself is narrow and well-scoped: agents get a Sensitivity Label dropdown in the command bar, available both when reading an inbox item and when composing or replying to an email, inside the Customer Service workspace and Contact Center apps. Labels are not created in Dynamics 365 at all. They are authored in the Microsoft Purview compliance portal, under Information Protection, where an administrator defines the label’s name, priority, scope, and, critically, its protection settings, including whether it carries encryption, a Do Not Forward restriction, or a visual marking like a watermark or header. Once that label policy is published tenant-wide, it becomes available inside Dynamics 365 without any additional publishing step on the Dataverse side.

What surprises a lot of technical teams is how much of the actual behavior is inherited from Purview rather than configured in Dynamics 365. A label that carries an encryption policy behaves identically whether it was applied from Outlook, from Word, or from a Customer Service email form: the message becomes a protected, rights-managed object the moment the label is applied, not a cosmetic tag on a Dataverse record.

Configuring Dynamics 365 Email Sensitivity Labels: The Two-Step Setup

The rollout has two distinct halves, and skipping the prerequisites is the most common reason a pilot stalls. Before anything happens inside Dynamics 365, the environment needs an email server profile configured for Server-to-Server Authentication against the same tenant’s Exchange Online, and server-side synchronization for email has to already be running. Neither of those is new infrastructure specific to this feature, but plenty of sandbox and dev environments never had them fully wired up, since basic email testing doesn’t require them.

With that in place, enabling the feature itself is a single toggle: in the Power Platform admin center, under the target environment’s Settings, expand Email, open Email Settings, and switch on “Enable data sensitivity labels for emails.” The second half of the work happens in Power Apps rather than the admin center. Inside the relevant solution, add the Email table’s main form to the solution if it isn’t already there, open the form in the designer, locate the “Sensitivity label” column, and drag it onto the canvas. On its own that column just stores a value, so the practical step is adding the “Email sensitivity label control” component to the same field and configuring it, then saving and publishing the form. Skip that control and the column exists on the record but agents never see anything to interact with.

One detail worth flagging to the security team directly: the Entra ID identity associated with the mailbox needs its own permissions in Microsoft Purview to apply the labels that are relevant to that queue. This is a common gap in shared-mailbox and queue-based routing setups, where the mailbox identity was provisioned years ago for basic send/receive and never touched again.

Solution architect configuring email sensitivity label settings in a Dynamics 365 environment

How Enforcement Actually Behaves in Practice

Once labels are live, the enforcement rules mirror what a user would expect from Outlook, and that consistency is deliberate. A label like Do Not Forward or Do Not Reply restricts the corresponding action for recipients inside the organization, and an agent cannot manually downgrade a message to a less restrictive label than the one already applied, so a “Confidential” thread can’t be quietly relabeled “General” to make it easier to forward externally. Replies and forwards inherit the label of the message being responded to by default, which is the behavior most compliance teams actually want, since it removes the judgment call from the agent in the moment they’re least likely to think about it. Attachments carry their own labels independently, and when an attachment’s label conflicts with the email’s label, the interface surfaces which one takes precedence rather than silently picking one.

Where this gets operationally interesting is auto-labeling. Purview supports content-based auto-labeling, where a label gets applied automatically based on what the message contains, and that setting lives entirely in Purview, invisible from the Dynamics 365 side. A queue that starts seeing a spike in encrypted, auto-labeled mail didn’t necessarily have a policy change made against it directly. Somewhere upstream, a Purview label’s auto-apply conditions matched more content than before.

The Gap Nobody Tests For: Encrypted Mail and Copilot

This is the part of the rollout that deserves its own test plan rather than a footnote. When a label applies encryption protection, Dataverse does not decrypt or store the message content. The email still appears in the case timeline, so an agent knows the correspondence exists, but the body is not readable inside the application at all. Agents are redirected to Outlook on the web to open and decrypt the message there.

That gap propagates directly into every Copilot capability that depends on reading email content. Case summarization skips encrypted messages entirely, meaning a case summary generated near the end of a long thread may be missing the specific email that actually contains the customer’s core complaint, if that thread’s most detailed message happened to carry a Confidential-and-Encrypted label. Case enrichment, intent detection, and any Copilot workflow built around analyzing inbound email content behave the same way: they simply do not see encrypted mail, and there is no fallback summarization or partial analysis. From the AI feature’s perspective, the message is invisible, not redacted.

For a technical team that built intent-based routing or auto-summarization as part of a Copilot rollout, this means the encryption policy decided in a completely separate Purview governance project can silently degrade the reliability of automation the contact center is depending on operationally. Neither team is wrong about their own configuration. The interaction between the two simply isn’t visible from inside either admin surface on its own.

Rolling This Out Without Breaking What Already Works

The practical fix isn’t to avoid sensitivity labels, since for a regulated organization that usually isn’t optional, and blanket-disabling encryption defeats the purpose of the compliance project in the first place. The fix is sequencing the two conversations that normally never happen in the same room. Before a label policy that carries encryption goes anywhere near production mailboxes tied to Customer Service queues, pull a sample of real case threads that currently drive summarization or intent detection, and run them through the label to see which specific messages would become invisible to Copilot under that policy. That test takes an afternoon and reliably surfaces problems that would otherwise take weeks to notice in production, one confused agent at a time.

It’s also worth treating auto-labeling as a change management event even though it technically lives entirely in Purview. Any time compliance adjusts an auto-apply condition on a label with encryption attached, that change has a direct, measurable effect on Copilot coverage in the contact center, and the service delivery team should be in the notification loop for that change, not discovering it through a drop in summarization quality. Finally, agents need to know the Outlook-on-the-web redirect path exists and why it exists, rather than treating an unreadable encrypted email in the case timeline as a bug to escalate. A short addition to onboarding material covers this permanently; a support ticket every time it happens doesn’t.

Routeget has walked several clients through exactly this sequencing problem when a compliance-driven Purview rollout landed on top of an existing Copilot investment in Customer Service, and the fix is almost always coordination rather than reconfiguration. Getting the security and the AI roadmap talking to each other before go-live is considerably cheaper than untangling the symptoms afterward.

#DynamicsCustomerService #DataSensitivityLabels #MicrosoftPurview #CopilotService #EmailSecurity #ComplianceGovernance

Configuring Cost Estimate Revenue Recognition in Dynamics 365 Project Operations

Finance professional reviewing a project revenue recognition dashboard in a modern office

A Project Operations consultant closing out a nine-month fixed-price engagement watches the percentage-of-completion figure move in a direction nobody on the delivery team predicted: down. Hours logged in August exceeded July. Actual costs tracked to plan. And yet the estimate-at-completion number jumped, because a resource manager quietly revised a forecast line two weeks before close, and revenue recognized in July has to be partially reversed to correct it. Finance wants to know why a project that delivered more work somehow recognized less revenue. The honest answer, until now, has been some version of “that’s how EAC-based recognition works.” As of September 11, 2026, that is no longer the only answer available. Microsoft has moved cost estimate revenue recognition in Dynamics 365 Project Operations to general availability, giving project accounting teams a second calculation baseline that does not move every time someone touches a forecast.

Why EAC Made Revenue Recognition Unpredictable

Fixed-price projects using the percent-completion method calculate recognized revenue as a share of total contract value, driven by percentage of completion. Under the standard approach, that percentage is actual costs incurred divided by the estimate at completion, and EAC is a living number. Every time a project manager updates a forecast line, adjusts a resource assignment, or revises an expense estimate, the denominator in that calculation shifts. A team can deliver exactly the work it planned to deliver in a given period and still see recognized revenue swing, purely because someone updated a forecast that has nothing to do with what actually happened that month.

Consider a $180,000 fixed-price contract line. Two months in, the team has incurred $54,000 in actual cost, tracking cleanly to a 30 percent completion rate against the original estimate. Then a resource manager flags scope creep on an upcoming deliverable and revises the EAC upward to $210,000. Recompute the percentage against the new denominator and completion drops to roughly 26 percent, even though nothing changed about the work already delivered. Finance now has to explain a revenue reversal to a client or an auditor for a project that is, by every operational measure, on track. Multiply that across a portfolio of active fixed-price engagements and month-end close turns into a chase for forecast revisions rather than a review of actual delivery.

Solution architect configuring project accounting revenue recognition settings

What Cost Estimate Revenue Recognition Changes

The new method replaces EAC in that denominator with a cost estimate: the original forecasted or budgeted total cost for the project, set once and held fixed unless someone deliberately revises the baseline. Percentage of completion becomes actual costs incurred divided by total forecast amount, full stop. Using the same numbers as above, the $54,000 in actual costs against the original $180,000 estimate still shows 30 percent completion in month two, regardless of what happens to the EAC afterward. If costs eventually run past the original forecast, the system does not reinterpret that as new revenue to recognize. It treats the overrun as margin erosion, which is arguably closer to what actually happened: the team spent more to deliver the same contracted scope, and that gap should show up as reduced profitability, not as a phantom revenue swing.

That distinction matters more than it sounds. EAC-based recognition quietly conflates two separate questions: how much revenue should be recognized this period, and how is the project trending against its budget. Cost estimate revenue recognition splits them apart. Revenue recognition stays anchored to the contracted baseline; budget performance becomes a separate conversation that shows up in variance reporting rather than in the revenue line itself.

Configuring the Feature: Cost Templates and Parameters

Enabling this requires Dynamics 365 Finance version 10.0.48 or later, along with the feature flag “Enable Project Revenue recognition by using the cost estimate instead of the estimate cost at completion in Project Operations,” which any user, admin, maker, or analyst with the right permissions can turn on through feature management. That self-service enablement path is worth flagging to your change control process on its own, since it alters financial calculation logic rather than a UI element, and it deserves the same review rigor as any other change to how revenue gets recognized.

Once the flag is on, the actual configuration happens at the cost template level. Navigate to Project management and accounting, then Setup, then Estimates, then Cost templates, and open the relevant cost line. On the General tab, set Cost to complete method to Total forecast minus actual, and set Use forecast amount for revenue recognition to Yes. That combination tells the system to calculate cost-to-complete from the forecast rather than from a manually entered total, and to use that forecast figure specifically for revenue recognition math rather than treating it as informational only.

A second setting matters just as much and gets missed more often. Under Project management and accounting parameters, on the Revenue recognition tab, set Allow posting when cost to complete is less than the check value to Warning rather than leaving it at its default blocking behavior. Because actual costs can legitimately run ahead of an unrevised forecast under this method, a hard block here will stop legitimate period-end postings. Warning mode lets the transaction post while flagging it for review, which is the right tradeoff once you have accepted that overruns are supposed to show up as variance rather than as a posting error.

Two scope limitations are worth knowing before you commit to a rollout. The feature currently supports completion methods based on cost amount or quantity. Projects using an effort or hours-based completion method were not part of the documented scope as of GA, so confirm your contract lines’ estimate methods before assuming this applies portfolio-wide. And because configuration lives at the cost template and cost line level, a project stitched together from multiple templates, some forecast-based and some not, can end up with genuinely inconsistent recognition behavior across its own cost lines. That is worth an audit of your template library before flipping the switch broadly, not something to discover during a client’s fiscal year-end.

Rollout Considerations for Projects Already in Flight

Project accounting team reviewing budget versus actual cost trends in a meeting room

Microsoft’s own documentation does not spell out how this interacts with periods that have already posted revenue under the old EAC-based calculation, and that ambiguity is reason enough for caution rather than assumption. Treat this as a forward-looking configuration change. Apply it to new fixed-price projects and to contract lines that have not yet posted revenue, and validate the behavior in a sandbox environment against a handful of representative project types before touching anything live in production. Run the same project through both calculation methods side by side for a period or two if your close calendar allows it. Seeing the actual delta between EAC-based and cost-estimate-based percentages on real data will tell you more about whether this is the right default for your portfolio than any amount of reading the release notes.

There is also a governance conversation worth having before this becomes the standing configuration. Cost estimate revenue recognition trades EAC’s volatility for a different kind of risk: a bad forecast set at project kickoff now drives revenue recognition for the life of the contract unless someone deliberately revises the baseline. That is a feature, not a bug, for teams whose real problem was noisy month-to-month recognition. It is a liability for teams whose original estimates were never particularly reliable to begin with. Stabilizing a number does not make it more accurate. It just makes it stop moving, which can look like accuracy without being it.

At Routeget, we have started building a review of this setting into 2026 release wave 1 upgrade assessments for clients running Project Operations at scale, rather than leaving it as an optional toggle someone discovers by accident. The fixed-price portfolios most exposed to EAC-driven revenue swings tend to be the ones with the tightest client reporting requirements, which means they stand to gain the most from a stable baseline and have the least tolerance for getting the transition wrong. Pilot it deliberately, audit your cost templates before rollout, and keep the forecast-accuracy conversation alive even after the volatility disappears from your month-end close.

#ProjectOperations #RevenueRecognition #CostEstimateMethod #ProjectAccounting #FinancialClose #EnterpriseERP