Same Convergence.
Opposite Architecture.

Salesforce and Microsoft agree that CRM, contact centre and AI are converging. They disagree about where the engagement layer should sit relative to the system of record.

Disclosure: My background includes architecture, vendor selection and design review work across both the Microsoft and Salesforce customer service stacks. Views here are my own. Both vendors are assessed against the same evidence thresholds and procurement questions.

“Service Cloud versus Dynamics” used to be a workable shorthand. It no longer describes the products being bought.

Salesforce now brands Service Cloud as Agentforce Service. The change was formalised in the Spring ’26 release after Agentforce 360 made its debut at Dreamforce 2025. Agentforce is no longer presented as an assistant sitting inside the service application. It is the organising idea for the platform: applications, data, orchestration and human work assembled around agents.

Microsoft has drawn a different product boundary. Dynamics 365 Customer Service remains the CRM service application and system of record. Dynamics 365 Contact Center is also sold as a standalone engagement layer designed to work with an existing CRM, including a non-Microsoft one.

That is not merely a naming difference.

Both vendors accept the same direction of travel. CRM, CCaaS and AI are becoming harder to separate. Salesforce is responding by pulling those functions towards one platform. Microsoft is responding by allowing the engagement layer and record system to be purchased independently.

Neither position is standing still. Microsoft’s 2026 release wave 1, running April to September, is framed around agentic automation, higher containment and extensibility. Salesforce’s Summer ’26 release, in production since mid-June, is framed around what Salesforce calls the Agentic Enterprise.

The buyer’s real question is therefore not which product has the longer routing list. It is:

Should the engagement layer live inside the system of record, or beside it?

That choice has a much longer life than any current feature advantage.

Two convergence strategies

Salesforce: convergence by absorption

Salesforce’s strategic claim is unity.

Agentforce Service, Agentforce Contact Center, Data 360, the Customer 360 applications and the Agentforce runtime are presented as parts of one operating model. Customer context, workflow, service records and agent actions can share the same platform controls. The architectural attraction is straightforward: fewer boundaries across which identity, data, policy and interaction state must be reconstructed.

This does not make Salesforce a closed system. It supports external data, third-party applications and a substantial CCaaS partner ecosystem. Its own contact-centre offer also provides native voice and digital options. “Absorption” therefore describes the platform’s centre of gravity, not the absence of integrations.

The strategic intention is still clear. Salesforce wants the customer record, the orchestration layer and the AI runtime to meet inside Salesforce. Integration remains possible, but the promised simplicity is strongest when Salesforce already owns most of the operational truth.

Microsoft: convergence by decoupling

Microsoft’s strategic claim is choice.

Dynamics 365 Contact Center is positioned as a standalone CCaaS product that can connect to the CRM an organisation already uses. A business can retain Salesforce, a custom CRM or another record system while adding Microsoft’s voice, digital engagement, routing, self-service and Copilot capabilities.

That independence has limits. The product is still built on Microsoft’s cloud architecture. Dataverse, Power Platform, Copilot Studio, Azure Communication Services and Microsoft administration surfaces can all form part of the implementation. A product can be independent of Dynamics 365 Customer Service without being independent of the Microsoft platform.

Microsoft also sells Dynamics 365 Customer Service Premium, which combines service CRM and contact-centre capabilities. Decoupling is therefore an available deployment model rather than a claim that separation is always preferable.

There is a second complication. Dynamics 365 Customer Service already supports third-party contact-centre and telephony integrations. Genesys, NiCE and Five9 all have integrations into the Microsoft environment, and some predate the standalone Dynamics 365 Contact Center product by years. Microsoft now supports at least three patterns: a partner CCaaS platform integrated with Customer Service, its own standalone Contact Center connected to another CRM, and the bundled Customer Service Premium route.

That creates a strategic question as well as a technical one. A buyer retaining a partner CCaaS platform should ask how Microsoft will maintain connector depth and roadmap support while expanding its native alternative. A buyer selecting Microsoft’s Contact Center should ask which former partner responsibilities Microsoft now owns directly. The answer determines not just where the seams are, but whose roadmap governs them.

The two strategies are less absolute than their marketing suggests:

• Salesforce absorbs, but supports external contact centres and systems of record.
• Microsoft decouples, but also supports partner CCaaS integrations and an increasingly integrated Microsoft service stack.

The useful comparison is not open versus closed. It is where each platform creates architectural gravity, and what happens when the enterprise does not follow it.

The real decision: where operational truth lives

A customer interaction depends on more than a customer record.

It has identity, intent, consent, channel state, routing history, conversation context, case state, policy decisions, actions already attempted and actions still permitted. AI adds prompts, tools, grounding sources, model versions and evaluation records.

Those elements do not have to live in one product. They do need a clear owner.

If the engagement layer sits inside the record platform, the principal risks are concentration and dependency. A single vendor’s data model and workflow engine become difficult to avoid. Changes that look local can affect the full customer-operation stack. Leaving later may require more than replacing a contact centre; it may mean extracting orchestration, evaluation logic and operating data as well.

If the engagement layer sits beside the record platform, the principal risks are synchronisation and split ownership. The architecture must decide which system owns routing state, which one writes the case, how customer context is refreshed during a conversation and what happens when one side is available but the other is not.

Neither structure is inherently superior. Each moves complexity to a different place.

Salesforce asks the buyer to accept platform concentration in exchange for fewer internal seams. Microsoft asks the buyer to accept more visible seams in exchange for greater independence between engagement and record systems.

The right answer depends on which risk the organisation is better equipped to govern.

The architecture becomes an operating model

The product boundary eventually becomes a team boundary.

Absorption can consolidate more administration, data policy and workflow ownership around one primary platform skillset. That can simplify release coordination and reduce the number of teams required for routine change. It does not eliminate specialist skills: Data 360, integration, telephony and external systems can still require separate ownership.

Decoupling preserves product independence but usually commits the operating model to more than one platform. A non-Microsoft CRM, Dataverse and Power Platform, Azure, Azure Communication Services and the integration layer may all require durable skills and support paths. Those responsibilities may sit in one cross-platform team or across several teams that share incidents and releases.

This is a hiring and organisational-design decision, not just an implementation estimate. Before choosing either model, identify who can change a journey end to end, who leads a cross-platform incident, which certifications must be retained and how many vendor release cycles the team must absorb. The architecture that looks most flexible in procurement can become the hardest one to staff two years later.

How to test Salesforce’s claim

Salesforce’s strongest case is an organisation in which Salesforce already owns customer service data and workflow. The architecture becomes more demanding when the authoritative record sits elsewhere.

The proof should therefore begin outside Salesforce:

1. Use the real system of record

Demonstrate an interaction grounded in core banking, policy administration, ERP or another authoritative platform. Show real-time reads, transactional write-back, conflict handling and audit history. A customer profile copied into a service view is not the same as shared operational truth.

2. Separate Data 360’s roles

Identify which journeys require Data 360, what data is copied, what can use zero-copy access and which operations still need a transactional integration. Include consumption, latency, data residency and deletion in the design. A unified analytical profile does not automatically replace the source transaction.

3. Test the third-party contact-centre path

If the buyer intends to retain another CCaaS platform, test whether routing context, AI assistance, quality data and interaction outcomes cross the boundary at full depth. “Integrated with” can mean anything from a deeply coordinated workflow to an embedded panel.

4. Remove a platform component

Show what happens to voice, routing, the agent desktop and self-service if Salesforce, Data 360 or an integration endpoint is impaired. Unity reduces some hand-offs but can increase the blast radius of a shared dependency.

5. Price the exit as well as the entry

List the workflows, prompts, actions, data products and evaluation rules that would need to be moved if the organisation later changed CRM or contact-centre platform. The absence of seams during implementation can become a larger seam during exit.

How to test Microsoft’s claim

Microsoft’s strongest case is an organisation that wants to preserve an existing CRM while changing the engagement layer. The architecture becomes more demanding when “works with your CRM” is tested beyond the desktop.

The proof should therefore begin with a non-Microsoft record system:

1. Demonstrate depth, not presence

Show customer identification, context retrieval, routing decisions, case creation, write-back and audit history using the buyer’s actual CRM. An embedded contact-centre widget proves that the interface can travel. It does not prove that responsibility for state is clear.

2. Declare the Dataverse footprint

Identify which records, events and configuration objects must exist in Dataverse. Explain whether data is copied, synchronised or referenced; how conflicts are resolved; and which system is authoritative for each object. CRM independence is weakened if Dataverse quietly becomes a second customer record.

3. Map the administration boundary

Show which responsibilities live in Dynamics 365 administration, Power Platform, Copilot Studio, Azure Communication Services, Azure and the retained CRM. A modular architecture creates choice, but it can also distribute operational ownership across teams and consoles.

4. Test partial failure

Demonstrate what agents and customers experience when the CRM is unavailable but the engagement layer remains online, and when the reverse occurs. A separation strategy is valuable only if its failure behaviour is designed rather than accidental.

5. Prove the long-term operating model

Identify who owns connectors, schema changes, regression testing and incident diagnosis. The cost of a seam is rarely the initial API call. It is the permanent responsibility for keeping two products aligned as both change.

Why the prices should not be put in a simple table

The public prices are real. A direct comparison built only from them is not.

As at 25 July 2026, Salesforce’s public US pages display Agentforce Contact Center at $125 per user per month and Contact Center Plus at $250. A separate Contact Center Voice package at $75 is available only to Agentforce 1 Edition customers. Salesforce says Contact Center is compatible with Enterprise, Unlimited and Performance editions, that the editions require an annual contract, and that special pricing applies for Agentforce 1. Agentforce 1 Editions themselves start at $550 per user per month and fold 2.5 million Flex Credits per org per year into the seat price.

Salesforce also states that some components require additional usage purchases over time, including messaging packs, surveys, bot sessions and hours of conversation insights. Its AI consumption can be priced through Flex Credits at $500 per 100,000 credits — a standard action meters at 20 credits and a voice action at 30 — or through conversations at $2 each. Salesforce publishes sterling rates for both consumption models, at £400 per 100,000 credits and £1.60 per conversation, though the Contact Center packages themselves are shown in US dollars only. The two consumption models cannot be used in the same Salesforce org, and unused Flex Credits do not roll over between subscription terms.

The worked examples are more useful than the headline rate. Salesforce’s own case-management example uses three actions, consumes 60 Flex Credits and costs approximately $0.30 per journey. Its field-service appointment example uses five actions, consumes 100 credits and costs approximately $0.50. Those examples exclude other costs such as Data 360. They show why journey design, not conversation volume alone, determines the consumption line.

Microsoft lists Dynamics 365 Contact Center at $110 per user per month, or the Digital and Voice products at $95 each. Dynamics 365 Customer Service Premium, combining service CRM and contact-centre capabilities, is listed at $195 per user per month.

Agentic use can consume Copilot Credits. A capacity pack is listed at $200 for 25,000 monthly credits, with pay-as-you-go and enterprise pre-purchase alternatives. Voice can also introduce Azure Communication Services, calling-plan, carrier or direct-routing costs.

These figures do not describe the same boundary. One buyer may already own the qualifying CRM licences. Another may retain a third-party CRM. One may use native voice; another may bring its carrier. One may contain a high proportion of simple contacts with AI; another may execute several expensive actions before escalating to a person.

Total cost is therefore not unknowable, but it should be expressed as a range rather than a single confident number.

A credible bid model needs at least:

• licensed users by role and product;
• interactions and minutes by channel and country;
• AI actions or credits per journey;
• containment and escalation assumptions, with variance bands;
• telephony, number and carrier costs;
• data ingestion, storage and retention;
• recording, quality and workforce-management packaging;
• integration runtime and support;
• implementation, migration and operating ownership.

Run low, expected and high scenarios against the same workload. If a proposal cannot show how the cost moves when containment falls or actions per journey rise, it is a unit-price comparison rather than a total-cost model.

Prove the architecture, not the presentation

The decision should be made through a proof of architecture rather than a presentation. The same scenarios should be used for both vendors, including when one appears to fit the existing estate more naturally.

Use the same scenarios for both vendors:

1. Identify a customer and retrieve context from the authoritative non-native system.
2. Change important customer data during an active interaction and prove where it is committed.
3. Allow AI self-service to act, fail and transfer to a person with usable context.
4. Remove one major platform dependency and show the degraded operating state.
5. Trace consent, recording, retention and deletion across every system involved.
6. Recalculate the commercial model after changing containment, channel mix and AI actions.

Those tests expose the architecture more effectively than a feature checklist.

The conclusion is not a product ranking

Salesforce and Microsoft are moving towards the same market and placing the boundary in different locations.

Salesforce is making the agentic platform the centre of service operations. That can remove seams where Salesforce already owns the truth, while increasing platform gravity and exit cost.

Microsoft is making the contact-centre layer independently deployable. That can preserve an existing record system, while increasing the importance of Dataverse boundaries, integration depth and distributed operational ownership.

Both approaches can be coherent. Both can also fail when their strongest marketing claim is accepted without testing:

• Salesforce unity fails when the authoritative truth remains elsewhere.
• Microsoft independence fails when the implementation quietly recreates the CRM inside Microsoft.

The decision is not which diagram contains fewer boxes. It is which organisation can most clearly own the data, failures, economics and change across those boxes for the next seven to ten years.

The accompanying CCaaS 60-Capability Benchmark Methodology addresses functional breadth and public evidence. This article addresses the architectural commitment behind the purchase. The two questions should inform each other, but they should not be collapsed into one score.

Evidence note

Product names, positioning and public list prices were checked against first-party material current on 25 July 2026. Prices are public list prices, quoted in US dollars unless a sterling figure is stated, normally based on annual billing, and exclude negotiated discounts, promotional offers, taxes and implementation unless a source states otherwise. Vendor positioning is reported as positioning rather than treated as proof of implementation depth.

• Salesforce Spring ’26 Service release notes
• Salesforce: Five Key Takeaways from Dreamforce 2025
• Salesforce Summer ’26 release overview
• Salesforce Agentforce Contact Center pricing and edition requirements
• Salesforce service add-on pricing
• Salesforce Agentforce consumption pricing and worked examples
• Microsoft Dynamics 365 Contact Center overview
• Microsoft Dynamics 365 2026 release wave 1 plan
• Microsoft Dynamics 365 Contact Center pricing
• Microsoft Copilot Studio pricing
• Microsoft Copilot Studio licensing guidance
• Microsoft training: configure Contact Center with a non-Microsoft CRM
• Genesys: Dynamics 365 data-actions integration
• NiCE CXone Agent for Microsoft Dynamics
• Five9 Adapter for Microsoft Dynamics 365