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

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

What the Sales Opportunity Agent Risk Criteria Actually Do

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

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

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

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

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

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

Writing a Risk Criterion That Actually Earns Its Place

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

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

Multiple Instances, One Shared Capacity Pool

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

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

Getting Useful Signal Out of the Rollout

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

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

---

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