As you grow into the world of “AI” Enabled and tight cost constraints have you considered if you really have the right team for your needs?

“Business Think” has never been the top skill of your heavy technical developer teams and yet, “Business Think” is critical in this age of communicating with all of the newer technical options. Microsoft provides a huge number of choices in their AI Business Application Suite which means that you want to make sure that you have the team that can support you with those choices.

Pick Senior Resources, who have experience delivering business applications and who can support you in how to think about the choices.

Include Business Analysts who know the applications so that Fit/Gap is part of every conversation.

Keep an Open Mind to all that is not only new, but also on the horizon. The horizon tends to be next month, not next year.

Define the Business Goal so that all can contribute to the potential options for delivery.

Understand that maintainability continues to be a variable.

Product Ownership and Technical Translations

A Feature (Business Requirement) should focus on the business outcome and value, not the technical solution. The goal is for it to clearly describe the business need, the user role, and the expected benefit using a format such as “As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast accuracy improves.”

The Feature should include business scenarios and measurable acceptance criteria that define what success looks like. For example, in Dynamics 365 Sales, a qualified lead must result in the creation of an Account, Contact, and Opportunity, while non-qualified leads remain in the lead management process.

A Technical Product Backlog Item (User Story) defines how the approved Feature will be delivered through configuration, customization, extension, security, automation, reporting, or AI capabilities. For a lead qualification Feature, technical user stories may include configuring either the Sales Qualification Agent for AI-assisted qualification or a traditional Business Process Flow-based qualification process.

Each technical user story must trace directly to the originating Feature, contain detailed technical acceptance criteria, and be broken into implementation tasks.

Business Requirement / Feature Standards

A good Business Requirement (Feature) should:

• Follow the format:
  • As a [Business Role] (clearly define the expected access, and/or role-based entitlements for this requirement)
  • I need [Capability] (what are you trying to do?, scenario)
  • So that [Business Value] (Always provide the goal!)
• Focus on the desired business outcome.
• Avoid technical design decisions or details
• Include one or more business scenarios.
• Define clear, measurable, and testable acceptance criteria.
• Align to User Acceptance Test scripts
• Be clearly understandable by business stakeholders, product owners, testers, and the delivery team.

Example Business Requirement (Feature)

Feature

As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast accuracy improves.

Business Scenario

• Leads are generated from events, marketing campaigns, referrals, and web forms.
• Sales representatives review lead information.
• Qualified leads are converted into an Prospective Accounts, Contact, and Opportunities.
• The organization may choose:
  • AI-assisted qualification using the Sales Qualification Agent, or
  • Traditional manual qualification using standard Dynamics 365 Sales capabilities.

Business Acceptance Criteria

• Given I am a sales person and a lead exists, when qualification criteria are met, then the lead can be manually or automatically qualified.
• Given a qualified lead, when qualification is completed, then a prospective Account, Contact, and Opportunity are created or an Account and Contact are created (Opportunity is optional)
• Given that the account and/or contact already exists when qualifying the lead then a new account and/or contact will NOT be created but the new opportunity will be associated to the existing account and/or contact
• Given a lead does not meet qualification criteria, when reviewed, then it remains unqualified.
• Given a completed qualification, when management reviews the lead, then qualification history is available for reporting and audit purposes.

Technical Product Backlog Item (User Story) Standards

Technical Product Backlog Items (PBIs) or Technical User Stories should:

• Support an approved Business Requirement (Feature).
• Describe how the solution will be configured or built.
• Include configuration decisions, security, automation, integration, reporting, or AI capabilities.
• Do not introduce NEW business requirements.
• Be traceable to the originating Feature.
• Include detailed, testable technical acceptance criteria.

Technical Product Backlog Item (User Story)

Parent Feature

As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast is accurate or accuracy improves.

Technical Product Backlog Item / User Story

As a sales representative I need the sales app to be configured to support manual lead qualification capabilities leveraging the new Sales Qualification AI-assisted agent so that I can leverage the most efficient process for qualifying my leads and so that I can create more than one opportunity from any given lead and so that I can see a summary of my lead qualifying efforts.

Option 1: Sales Qualification Agent Configuration

Configuration Scope

• Enable Sales Qualification Agent.
• Configure qualification criteria.
• Configure lead scoring thresholds.
• Enable AI-generated lead research and recommendations.
• Configure seller review and approval process.
• Configure security roles.
• Configure qualification reporting and audit tracking.

Technical Acceptance Criteria

• Given the Sales Qualification Agent is enabled, when a new lead is created, then the agent evaluates the lead using configured qualification criteria.
• Given qualifying information is available, when analysis is completed, then recommendations are presented to the salesperson.
• Given qualification thresholds are met, when seller approval is provided, then the lead can be qualified.
• Given a lead is qualified, when qualification is executed, then an Account, Contact, and Opportunity are automatically created.
• Given qualification activities occur, when reports are reviewed, then agent actions are available for auditing and analysis.

Option 2: Traditional Qualification Process Configuration

Configuration Scope

• Configure Lead table fields.
• Configure Business Process Flow.
• Configure qualification checklist.
• Configure business rules and validations.
• Configure lead scoring fields.
• Configure security model.
• Configure reporting and dashboards.

Technical Acceptance Criteria

• Given a sales representative opens a lead, when required fields are completed, then the lead can advance through the qualification process.
• Given qualification criteria are met, when the user selects Qualify Lead, then an Account, Contact, and Opportunity are created.
• Given required data is missing, when qualification is attempted, then the process is blocked and validation messages are displayed.
• Given qualification is completed, when records are created, then data mapping follows approved business requirements.
• Given security restrictions exist, when an unauthorized user attempts qualification, then access is denied.

Agile Requirement Hierarchy example

Recommended Traceability Model

• Epic → Lead Management and Qualification
  • Feature (Business Requirement) → Consistent Lead Qualification Process
    • Technical Product Backlog Items (User Stories) → Configure Sales Qualification Agent
      → Configure Traditional Lead Qualification Process
      → Configure Lead Scoring
      → Configure Security Roles
      → Configure Data Mapping
      → Configure Reporting and Analytics
      • Tasks → Configuration, Testing, Documentation, Deployment, and Training activities required to complete each Technical Product Backlog Item.

This approach provides clear business-to-technical traceability while aligning with common Agile and Scrum practices of Epic → Feature → User Story → Task.

M365 Copilot Has made huge leaps in its ability to generate great pictures and given that the world is very visual, and a lot of people appreciate a good diagram. I thought I would share a few.

We try out AI, we hear about AI, we layer on AI tools, but what needs to be considered is how the whole infrastructure aligns with the business application feature sets such as the features in Microsoft Dynamics 365 Customer Engagement (Configured for your industry) layered on top of common features such as Sales, Customer Service, Contact Center, Field Service and more..

For the last few years Microsoft has been quietly (or perhaps not so quietly) adding Copilots to every feature within every business application and within the development tools that feed those applications. The last I counted there were at least 150 different Copilots and they add the steroids to the features (sometimes more, sometimes less). Sure, we could search on activity history, but now we have a Copilot that summarizes that history for us and that is just one example of many.

It is not getting people to “Add Data” into their CRM system, it is providing the ability for people to get data out when they need it and from where they need it from.

The Visual Reporting (Power BI) and the Dynamics Views that tie easily to Excel (for people who just do not want to give up Excel), the Dashboards that pull from the Dataverse and sometimes from many other sources of data and the power of predictive data.

For those living on the bleeding edge, Copilots are just part of their every day productivity and now they are embracing all of the new Agents and Agents that talk to other Agents. The Sales Research Agent in Microsoft Dynamics 365 is just “there” and part of your Spring menu. As a development team, we don’t have to work magic to get multiple vendor offerings aligned to provide you with Agent power and clients don’t have to juggle multiple vendor pricing and as a +1 Copilot Studio allows us to quickly configure agents based on your needs.

Sales Research running in Microsoft Dynamics 365 Sales with the Microsoft Teams Embedded open.

The Sales Research Agent Menu Item in Microsoft Dynamics 365 Sales

As much as we all love to hate Microsoft when any gap is stepped into. They are pushing the envelope hard with all of their development and product teams. The key is to work with teams who know the FIT/GAPs and although GAPS disappear as fast as the technology changes knowing and listening to the key variables is a critical way to avoid frustrations.

In this day of Big Data Centers and incredible compute power, we often forget to think hard about what might impact performance.

Performance is not about the speed of the processor or the speed of your computer. Performance is all about managing the bottlenecks.

If you have the fastest car in the world and you are on a highway where the toll bridge is raised, you are not going to go very fast. The cars in front of you are stopped and the road is unavailable.

There are two areas in Microsoft Dynamics 365 Customer Engagement architecture that people need to be aware of when configuring the system.

The first is often ignored. “Sharing” If you allow your users to “Share” various components you are basically asking for an exception. This exception needs to bypass all Role Based Entitlement architecture and internal user access and give exception to the person an individual is sharing too. As a best practice we try to limit sharing and prefer to architect with good requirements and needs in mind.

The second is Role Based Entitlement security roles. If you have 100s of role based entitlements and you layer these extensively, your performance will be impacted. Minimal layering of security roles is encouraged, heavily redundant layering of the same permissions in every role or excessive layering (more than 10) causes the system to do some pretty heavy lifting. We architect with these key concepts in mind.

As many know, Microsoft has been obsessed with creating Agents, Agent Template libraries and all of the associated derivatives. Agents that call other Agents and that totally change the way we work.

If you want to dip your toes into the new features, you can start here.

Microsoft Dynamics 365 2026 release wave 1 plan | Microsoft Learn

Microsoft Dynamics 365 Sales What’s New and Planned?

Microsoft Dynamics 365 Customer Service What’s New and Planned

Microsoft Dynamics 365 CcaaS Contact Center What’s New and Planned?

and sooo much more!!

A Reference Architecture for Financial Services Institutions

Delivering Trusted, Compliant, and Intelligent Client Experiences

In financial services, customer experience is inseparable from trust. Whether the interaction occurs in a branch, through a relationship manager, or via a digital channel, institutions must balance personalization with regulatory rigor, data privacy, and operational resilience.

Microsoft Dynamics 365 Customer Engagement (CE), built on the Power Platform with Microsoft Dataverse and integrated with Microsoft 365, and optionally Microsoft Fabric, provides financial institutions with a modern reference architecture that does exactly that, connecting client engagement, compliance, and intelligence on a single, governed platform.

This architecture enables banks, insurers, and capital markets firms to move from fragmented client data and disconnected processes to a unified, auditable, and insight‑driven operating model.

Dynamics 365 Customer Engagement supports core client‑facing functions across the financial services lifecycle:

• Sales and Relationship Management for commercial, and wealth clients
• Client Service and Case Management aligned to SLAs and regulatory obligations
• Client Onboarding, and Lifecycle Events
• Targeted Marketing and Client Communications

What differentiates Dynamics 365 CE in financial services is not just functionality, it is the underlying platform architecture that ensures controls, organization, reduced complexity, transparency, and scale.

The Common Data Universe, “Dataverse” = The Trusted Client Data Backbone

At the heart of the architecture is Microsoft Dataverse, serving as the operational system of record for client engagement data.

For financial institutions, Dataverse provides:

• A canonical client data model across accounts, account hierarchies, households, contacts, relationships, products, and interactions
• Granular security controls, including row‑level and field‑level access to protect PII information
• Full auditability, supporting regulatory and internal compliance requirements
• Policy‑driven business logic, ensuring consistent execution of onboarding, servicing, and escalation processes

Dataverse becomes the “single version of the truth” for client engagement—controlled, governed, and resilient.

Integration with Microsoft 365: Secure Productivity for Front Office Teams

Relationship managers, advisors, and service agents like to live in Outlook or Teams or Excel or all three. Dynamics 365 CE integrates client data directly into these tools while maintaining compliance boundaries.

Examples include:

• Outlook and Teams integration for secure client communications and internal collaboration linked to client records
• Excel integration for controlled analysis and data updates, without exporting sensitive data unmanaged
• Document management with retention and compliance policies enforced

This integration improves productivity while ensuring that interactions remain traceable and compliant.

Azure Data Lake: Analytical Scale Without Risk

Operational systems like Dataverse are designed for transaction integrity, not massive analytical workloads. To meet regulatory reporting, risk analysis, historical point in time analysis, and other advanced analytics needs, data is replicated to Azure Data Lake using Dataverse Synapse Link.

This enables:

• Near‑real‑time replication of client engagement data
• Secure, read‑only analytical copies of operational data
• No performance impact on client‑facing systems

For financial services, this separation is critical. It ensures that reporting, risk modeling, and analytics never compromise operational stability or data integrity.

Microsoft Fabric: Intelligence, Risk Insight, and Regulatory Reporting

Microsoft Fabric provides a unified analytics and AI platform built directly on Azure Data Lake. In Dynamics 365 architecture, Fabric powers even more enterprise intelligence.

Key financial services use cases include:

• Client profitability and relationship analytics
• Conduct risk and service quality monitoring
• Regulatory reporting and supervisory analytics
• Advanced AI and predictive modeling, responsibly governed

Fabric enables institutions to move beyond static reporting toward continuous insight—all while maintaining lineage, governance, and security.

Power Platform: Controlled Agility

Across this architecture, the Power Platform enables innovation without sacrificing control and it supports the constant change of technology so Enterprise Accounts don’t fall behind. We also get

• Power BI which delivers trusted dashboards to executives and regulators
• Power Automate which orchestrates exception handling, business process automation and cross‑system workflows
• Power Apps which can extend customer engagement processes, subset features into department specific needs and safely and efficiently deliver results

This allows financial institutions to adapt quickly to regulatory change and evolving client expectations.

High Level Architecture

The diagram below illustrates how these capabilities come together in a financial services context where you might have people outside of the enterprise accessing and offering a subset of data through Power Page Portals and where inside the Enterprise people are using Single Sign on authentication and leveraging off of Microsoft 365 Office with Microsoft Dynamics 365 Customer Engagement Apps.

Flow Overview:

1. Client interactions occur across branches, contact centers, and digital channels
2. Dynamics 365 CE orchestrates engagement and process execution
3. Dataverse serves as the secure, auditable system of record
4. Microsoft 365 enables compliant productivity and collaboration
5. Azure Data Lake and/or Microsoft Fabric deliver analytics, AI, and regulatory insight

Why This Architecture Matters for Financial Leaders

From an executive perspective, this architecture enables:

• Client‑centric growth without compromising compliance
• Regulatory confidence through auditable, governed data flows
• Operational resilience via clear separation of transactional and analytical workloads
• AI readiness grounded in trusted, secure data

In an era where regulators, clients, and markets demand both transparency and intelligence, this is not just a technology architecture—it is a strategic advantage.

Final Thought

Financial institutions that modernize client engagement on Dynamics 365, Dataverse, Microsoft 365, Azure Data Lake, and Fabric are not simply upgrading CRM systems. They are establishing a platform for trusted growth—where every client interaction is compliant, contextual, and informed by real‑time insight.

If you’d like, I can:

• Adapt this article for banking vs. insurance vs. wealth management
• Add Copilot and AI scenarios specific to financial services
• Create a board‑ready version focused on risk, ROI, and transformation outcomes

One of the most critical concepts to understand when thinking about Microsoft Dynamics 365 Customer Engagement is the centralized experience of the Common Data Universe (Dataverse). When working with Dynamics 365 Customer Engagement modules (or call them Microsoft Developed Power Apps), they are all sharing a common source. We can take this common source and extend it out into Microsoft Azure Data Factory or Microsoft Fabric, but it is not required.

Azure AI Language service can be used to access the Azure AI Language service, but not the Azure AI Translator and Azure AI Speech services.

The Machine Learning service is used to design, implement, and deploy Machine Learning models.

Azure AI Bot Service provides a framework for developing, publishing, and managing bots in Azure.”

Get started with translation in Azure – Training | Microsoft Learn

REGRESSION

“Predicting rainfall is an example of regression machine learning, as it will predict a numeric value for future rainfall by using historical time-series rainfall data based on factors, such as seasons.

Clustering is a machine learning type that analyzes unlabeled data to find similarities in the data.

Featurization is not a machine learning type, but a collection of techniques, such as feature engineering, data-scaling, and normalization.

Classification is used to predict categories of data.”

Regression – Training | Microsoft Learn