Dynamics 365 Customer Service vs. Zendesk, Freshdesk, and Native Microsoft 365 Tools: Real Integration Benefits for Microsoft 365 Shops

If your company is already fully on Microsoft 365, the customer service decision is not just about ticketing features. It is about identity, collaboration, content, and automation, and how much of that you already own.

For companies invested in Microsoft 365, choosing a customer service platform involves more than feature lists. Zendesk is a good standalone help desk that goes live quickly. If you are already fully on Microsoft 365, Dynamics 365 Customer Service runs on the identity, collaboration, content, and automation you already own: native integration with Entra ID, Teams, SharePoint, and Power Automate reduces admin overhead, improves agent productivity, and lowers long-term TCO. For a smaller team, Planner, Lists, SharePoint, and Teams channels may still be enough, and this page lists the signals that show you have outgrown them. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia.

Here is the honest comparison, plus a worked answer for a team of 15 agents weighing Freshdesk against Dynamics 365, a full comparison against running support on the Microsoft 365 tools you already have, meaning Planner, Lists, SharePoint, and Teams channels, with ten signals that tell you when to upgrade, and a crisis playbook if you need a desk running before you can decide. If what brought you here is the Teams question specifically, jump to the Power Automate guide to integrating Dynamics 365 Customer Service with Microsoft Teams, which covers connector configuration, a step by step flow build, adaptive card quick actions, and troubleshooting. If you are reading this from Armenia or the wider Caucasus, there is also a full Dynamics 365 vs. HubSpot comparison written for this market further down: dram budgeting against USD list prices, local partner coverage, interface languages, and what expansion into a second country actually needs, followed by the Dynamics 365 CE vs. HubSpot Microsoft ecosystem decision for any Microsoft 365 shop: what the HubSpot premium connectors really cost next to native Entra ID and Dataverse, where approvals and custom SLA rules outgrow the HubSpot workflow engine, and a decision matrix by user count, process complexity, and how much Microsoft 365 you already run.

How do Dynamics 365 Customer Service and Zendesk compare on Microsoft 365 integration?

Both platforms handle cases, queues, SLAs, and a knowledge base well. The real difference for a Microsoft 365 shop is how each one sits against the identity, collaboration, and content plane your tenant already owns. Here is how they compare on the factors that usually decide it.

Factor	Dynamics 365 Customer Service	Zendesk
Identity and sign-in	Runs on the same Microsoft Entra ID (formerly Azure AD) as the rest of Microsoft 365. Single sign-on, conditional access, and group-based licensing apply with no separate identity to provision or deprovision.	Supports SAML and SSO into Entra ID, but remains a separate application. Provisioning, deprovisioning, and access reviews are an extra integration you configure and maintain.
Agent collaboration	Embedded Microsoft Teams. Agents swarm on a case, chat with experts, and link the conversation to the record without leaving the app. Presence and calls are native.	Connects to Teams and Slack through apps and webhooks. It works, but the link is an integration surface rather than a shared runtime, and context can live in two systems.
Knowledge and documents	Knowledge articles live in Dataverse and attachments can sit in SharePoint, so case documents share the same governance, retention, and search as the rest of your tenant.	Has a capable native help center and Guide knowledge base, but content and files live in Zendesk. Aligning them with SharePoint governance means additional connectors.
Automation	Power Automate is first class. The same low-code engine that automates the rest of Microsoft 365 drives case routing, approvals, and notifications, reusing connectors you already own.	Has strong built-in triggers, automations, and a marketplace. Reaching into Microsoft 365 for approvals or document steps still routes through Power Automate or custom middleware.
Reporting and data	Case data sits in Dataverse, so Power BI reports directly on it alongside your other business data. No export or sync layer is required to build a single view.	Ships with Explore for its own analytics. Combining Zendesk metrics with data already in Dataverse or a Microsoft 365 warehouse means an export or connector to maintain.
Licensing and admin	Purchased and administered through the same Microsoft agreement and admin centers you already use, so vendor management, billing, and security posture stay in one place.	A separate vendor, contract, and admin console. That is manageable, but it is a second platform to budget, secure, and keep current on its own release cadence.

Zendesk is a strong standalone help desk. The point is not that it is worse; it is that for a company already fully on Microsoft 365, Dynamics 365 Customer Service reuses infrastructure you have already paid for, while Zendesk asks you to bridge back to it.

Which platform is right for you, Zendesk or Dynamics 365 Customer Service?

Choose Zendesk when

•Customer service is a standalone function and you do not need cases tied into sales, marketing, or the wider Microsoft 365 data plane.
•You want a support desk live in days with minimal configuration and a mature out-of-the-box help center.
•Your team already knows Zendesk well and the switching cost outweighs the integration gains.
•Your support volume and channels fit Zendesk pricing better than Dynamics 365 Customer Service licensing for your seat count.

Choose Dynamics 365 Customer Service when

•You are already fully on Microsoft 365 and want customer service on the same identity, collaboration, and content plane you already run.
•Cases need to connect to Dynamics 365 Sales, Dataverse, or Power BI so support and the rest of the business share one record.
•You want automation, approvals, and document handling to reuse Power Automate and SharePoint rather than a second stack.
•Reducing the number of separate vendors, identities, and admin consoles matters as much as raw ticketing features.

What does the practical architecture look like for a Microsoft 365 shop?

The integration benefits are not marketing claims; they come from Dynamics 365 Customer Service sharing the same underlying services as the rest of Microsoft 365. Here is what that actually means in the four areas that matter most.

One identity with Microsoft Entra ID

Because Dynamics 365 Customer Service authenticates against the same Microsoft Entra ID (formerly Azure AD) as the rest of Microsoft 365, agents sign in once, conditional access and multi-factor policies apply automatically, and joiners and leavers are handled by the same group-based process that already governs your tenant. There is no second directory to keep in sync.

Teams as the collaboration layer

Embedded Microsoft Teams lets agents swarm a hard case, pull in a subject matter expert, and keep the whole conversation attached to the case record. For a Microsoft 365 shop this is the collaboration tool the whole company already lives in, rather than a bolt-on chat integration that keeps context in a separate place.

SharePoint and Dataverse for content

Knowledge articles sit in Dataverse and case documents can be stored in SharePoint, so support content inherits the same search, retention, and governance as the rest of your tenant. You are not maintaining a separate document store with its own permissions model and its own backup story.

Power Automate for automation and reporting

Case routing, escalations, approvals, and notifications run on Power Automate, the same low-code engine that automates the rest of Microsoft 365, reusing connectors you already own. Case data lives in Dataverse, so Power BI reports on support alongside sales and the rest of the business without an export layer.

Do you need Dynamics 365 Customer Service, or are native Microsoft 365 tools enough for support?

Before Zendesk or Freshdesk are even on the list, most Microsoft 365 shops are already running support on the tenant they own: a shared mailbox, a Planner board or a SharePoint list of tickets, documents in SharePoint, a Teams channel where the actual conversation happens, and a handful of Power Automate flows holding it together. That is a legitimate way to run a desk, and for a smaller team it is often the correct one. The useful question is not whether Microsoft 365 tools can do support. It is where they stop, how you will know, and what specifically you get for the money when you move to Dynamics 365 Customer Service.

The comparison below is against the tools themselves rather than against a product brochure. It covers the four things that decide it in practice: how the case is represented, how automation is built and maintained, what you can honestly report, and how deep the integration goes when support has to know about the rest of the business.

What you are comparing	Microsoft 365 tools (Planner, Lists, SharePoint, Teams, Power Automate)	Dynamics 365 Customer Service
The request record itself	A Planner task, a Lists item, or a Teams thread. It holds a title, an assignee, and whatever columns you added. None of them know what a customer is, so the requester is a text field and nothing connects this request to the five the same person raised last quarter.	A case in Dataverse related to a contact and an account, with status and status reason, parent and child cases, merge, and a full history. Opening one case shows every previous case for that customer without a lookup somebody had to build.
Intake across channels	Email into a shared mailbox becomes list items through a Power Automate flow you wrote and now own. Phone, web form, and requests raised in a Teams channel are three more builds, and each one is a flow that can fail quietly overnight.	Automatic record creation rules turn inbound email and activity into cases with the same handling for every channel, configured rather than built, and failures surface in the product instead of in a run history someone has to remember to open.
Assignment and routing	Manual, or a rota list and a flow that cycles through names. Capacity, skills, shift, and language are things you would model yourself, and nobody rewrites that logic the week half the team is on leave.	Queues and unified routing assign by rule, capacity, and skill, with overflow and reassignment handled in the product. Changing how work is distributed is an admin configuration change rather than a flow rewrite and a redeploy.
SLAs and entitlements	Not present. You can approximate a due date with a calculated column and chase overdue items with a scheduled flow, but there is no clock that pauses while you wait on the customer, and nothing that records what a contract actually promised.	Entitlements record what the customer bought, how many cases it covers, and which SLA applies. SLA KPIs track first response and resolution with warning and failure actions, including pause behaviour while the case sits with the customer.
Automation	Power Automate, and only Power Automate. Every rule you want is a flow you designed, named, and maintain: acknowledgement, assignment, escalation, reminders, closure. It is genuinely capable, and it is also a small application that nobody wrote a specification for.	The same Power Automate, plus the case logic that ships in the product: routing rules, SLA actions, business rules on the form, and server side logic in Dataverse for anything that has to run on save. You write flows for the edges rather than for the fundamentals.
Reporting	Grouped list views, and Power BI pointed at the list when you need more. Every metric is one you compute from timestamps you remembered to stamp, so first response time only exists if every path in every flow wrote that column.	Case timestamps, SLA outcomes, ownership changes, and resolutions are part of the model, so the built-in Customer Service dashboards and historical analytics answer volume, resolution time, and backlog on day one. Power BI still reads the same Dataverse data for anything specific to you.
Knowledge	SharePoint pages and documents. Good content, kept in a different place from the request, with no review and expiry process tied to support and no way to record which article actually resolved a ticket.	Knowledge articles with drafting, review, versioning, and expiry, searchable from inside the case form and linked to the cases that used them, so you can see which articles deflect work and which are quietly out of date.
The customer side	Email replies, and nothing else unless you build a portal. Customers cannot see status or history, so a steady share of your inbound volume is people asking where their request got to.	Customer self service on Power Pages runs on the same Dataverse case data rather than on a separate application you integrate, so status and knowledge can be exposed to customers with the case as the source of truth. Price the portal licensing separately before you plan on it.
Scale and limits	SharePoint list views degrade past the 5,000 item threshold without indexed columns, per item permissions get unpleasant when some tickets must be private, and Power Automate runs are capped by your plan. A busy team tends to meet all three in the same quarter.	Dataverse is a relational store with a security model built for this, so volume, row level access, and private records are configuration decisions rather than workarounds you have to keep explaining.
Cost and who carries it	No new license spend while you stay on Lists, Teams, and standard connectors under a plan such as Microsoft 365 E3. The real cost is the person who maintains the flows, and the fact that it is almost always one person.	A per user subscription on top of Microsoft 365, offset by identity, collaboration, content, and automation being already bought, and by the case behaviour being Microsoft supported rather than owned by whoever happened to build it.

None of the Microsoft 365 tools in that first column were designed to be a service desk, and the fact that they get as far as they do is the reason so many teams stay on them for years. Dynamics 365 Customer Service is one of the Customer Engagement apps built on Dataverse, so it starts from a customer record rather than a task list. Our practical overview of Dynamics 365 Customer Engagement covers what the wider suite includes and where Dataverse sits underneath it, which is worth reading first if this would be your first Microsoft business application.

Automation: Power Automate flows vs. the case logic inside Dynamics 365

People frame this as Power Automate against Dynamics 365 workflows, and framed that way it is misleading, because Power Automate is the automation engine on both sides. Dynamics 365 Customer Service does not replace it. The real difference is what you are forced to build with it.

On Microsoft 365 tools, your flows carry the state of the ticket. One flow acknowledges, one assigns, one escalates, one nudges, one closes. Each runs asynchronously, each can fail on its own, and the state of a ticket is whatever the last successful run happened to write. There is no transaction across them, so a flow that dies halfway leaves a ticket that is assigned but never acknowledged, and nothing in the system considers that an error. In Dynamics 365 Customer Service, the case state, routing rules, and SLA actions are product behaviour, business rules run on the form, and logic that must not half apply runs server side in Dataverse on save. Power Automate is then used for what it is genuinely good at: posting to a Teams channel, generating a document, calling another system.

The practical test takes five minutes. Open your flow list and count how many flows exist only to make a ticket behave like a ticket rather than to connect it to something else. If that is more than about a third of them, you have already built a case management product out of flows, and you are paying to maintain it in someone’s time rather than in a subscription.

Reporting: Power BI over a SharePoint list vs. Customer Service dashboards

Both routes end in Power BI, so this is not a question of which tool draws better charts. It is a question of what the numbers are made of. Reporting over a SharePoint list means every metric is derived from a column something remembered to stamp. Backlog age is easy because it comes from the created date. First response time is not, because it only exists if every path wrote it, including the reply an agent sent straight from Outlook, which is exactly where the number quietly becomes wrong. Reopen rate needs a status history you are probably not keeping at all.

In Dynamics 365 Customer Service, case creation, first response through the SLA KPI, resolution, reactivation, and ownership changes are part of the data model, so the built-in dashboards and historical analytics answer the standard questions without a modelling exercise, and Power BI on the same Dataverse tables handles the questions that are specific to your business. SLA behaviour is also where a homemade desk misleads you most, and even in the real product the pause rules deserve care, which we cover in our write-up on fixing Customer Service SLA timers that pause incorrectly.

So the criterion is defensibility rather than prettiness. If the first response time you would put in front of a customer depends on a flow having run, it cannot be defended, and the reporting difference has decided the comparison for you.

Stay on Microsoft 365 tools when

•Volume is low and steady, one or two people can see every open request in a single view, and nothing is being lost.
•Requests arrive on one channel, usually a shared mailbox, and nobody is asking for phone, web, or portal intake.
•No response time has been promised in a contract, so an approximate due date and a daily chase is an honest representation of what you offer.
•The requesters are colleagues. IT, HR, and facilities desks serving people inside the tenant do not need an account, an entitlement, or a customer portal.
•Support is not connected to revenue, so nobody needs the account, the contract, or the open opportunity in front of them while they answer.
•Someone genuinely owns the lists and flows, and the reporting you are asked for is volume and backlog rather than first response time by customer.

The upgrade checklist: ten signals you have outgrown Planner, Lists, and Teams

These are the conditions we actually see when a team calls us about moving. Count how many are true of your desk today. Each one is checkable in an afternoon, without a vendor call and without a workshop.

1
The ticket list has passed roughly 5,000 items, or you have already added indexed columns and archive views to keep it usable.
2
The team has grown past roughly eight to ten agents. Below that, coordination happens in the room. Above it, coordination has to live in the system.
3
More than one intake channel is real: email plus a web form, a phone log, or requests raised in Teams that never reach the list.
4
Assignment takes a person. If someone spends the first twenty minutes of every morning handing work out, that is a routing engine being run by hand.
5
You need the clock to stop while you wait on the customer. Approximating an SLA with a due date column stops being defensible the first time it is reported on.
6
Somebody has asked what you promised a specific customer and the answer is in a contract document rather than in the system.
7
A reporting question takes more than an hour to answer. First response time by customer, reopen rate, or backlog age by agent should not require an export.
8
Customers email to ask for status. That volume is the running cost of having no portal, and it usually grows faster than ticket volume does.
9
Agents need context the list cannot hold: the account, the last order, the open opportunity, the entitlement, the previous five cases.
10
Flow maintenance has one name attached to it, or you cannot answer who changed this record and when. Both are the point where a list based desk fails an audit.

Now score it honestly. Zero to two signals means stay where you are and spend the budget on something that hurts more; a well kept list and a few flows is a good answer at that size. Three to five means start the conversation and plan the move over the next two quarters, because you are already paying for the gap in agent time and you now know which gap it is. Six or more means you have been running a support platform by hand for a while, and another year of that costs more than the move does.

One thing worth saying plainly, because it changes how the decision feels: moving up does not throw the Microsoft 365 work away. Teams stays the collaboration layer and becomes embedded rather than adjacent, SharePoint stays the document store for case attachments, your Power Automate flows keep running with Dataverse in place of the list, and identity never moves at all because it was Microsoft Entra ID the whole time. The tickets themselves are rows with clean columns, so loading them in as cases is an ordinary data migration rather than a rescue. If you are not there yet and need something working this week, the crisis playbook further down this page builds exactly this kind of desk on SharePoint Lists, Power Automate, and Teams inside licensing you already hold. When the checklist says it is time to move, that is the work our Dynamics 365 developers and CRM consultants in Armenia do: the Dataverse model, the queues, routing, SLAs and entitlements, the migration off the list, and the custom controls where the standard form falls short.

How do you integrate Dynamics 365 Customer Service with Microsoft Teams using Power Automate?

Everything above says the Teams integration is the reason a Microsoft 365 shop chooses Dynamics 365 Customer Service. This section is the part that claim is usually missing: exactly how you build it, connector by connector, with the trigger settings that decide whether it works for anyone other than the person who made it, and the failures that show up two weeks after go live. It is written from the Dynamics 365 Customer Service and Power Automate builds we deliver from Yerevan, so the awkward details are in it rather than smoothed out.

Start with the decision that saves the most work, which is deciding whether you need a flow at all. Three different things get called the Teams integration, and only one of them is a build.

Where Dynamics 365 meets Teams	What it actually gives you	When to use it
Embedded Teams chat on the case form	Switched on in the Customer Service admin centre under the collaboration settings. It puts a Teams chat panel on the case record itself, so an agent starts a chat from the case, invites whoever they need, and the chat stays linked to that case for the next person who opens it.	Use it for agent to agent conversation about a case. It needs no Power Automate at all, and turning it on first removes roughly half of the notification requests a support team will otherwise ask you to build.
The Dynamics 365 app and channel tabs inside Teams	Adds Dynamics 365 as an app inside Teams and lets a view or a single record be pinned as a tab in a channel. Users sign in with their own Entra ID account and their Dynamics 365 security roles still apply, so nobody sees more in Teams than they would in the app.	Use it where a team lives in Teams and only visits Dynamics 365 for context. It is configuration rather than a build, so do it before anyone writes a flow whose real purpose is to copy case fields into a channel message.
Power Automate flows on the Dataverse and Teams connectors	Everything the first two cannot do: notifications on conditions you define, adaptive cards carrying the exact fields agents need, buttons that write back to the case, a chat created for a swarm, and scheduled digests instead of one card per case.	Use it for anything event driven, anything conditional, and anything that has to reach people who do not open Dynamics 365 during their working day. This is the part that is genuinely built, and the rest of this section is about building it so it survives production.

The order matters. Turn on the embedded chat, add the app in Teams, see what is still missing, and only then open Power Automate. A meaningful share of the Teams notification work we are asked to quote disappears at that second step.

The four patterns behind almost every Teams request

Requirements arrive as sentences rather than as designs. Nearly all of them are one of the four patterns below, described in the requester own words, and recognising which one you have been handed is worth a fortnight of not building the wrong thing.

Notification: one card, the fields that decide the next action

A new or escalated case posts a card into the support channel or to the owner directly. The value is in restraint. Fire on a condition worth interrupting somebody for, carry the fields that decide what happens next, and link to the record for everything else. A notification flow that fires on every case at any volume above a few dozen a day trains the team to scroll past the ones that mattered.

Collaboration: a swarm chat with the case attached

For a case that needs several people, create a group chat named with the ticket number, add the owner and the resolved experts, post the case card as the first message, and write the chat link back onto the case. The point of writing the link back is that the conversation stays findable from the record six months later. Where the embedded Teams chat on the case form already covers this, use it and build nothing.

Quick actions: buttons that write back to Dataverse

Acknowledge, assign to me, and needs escalation are the three that earn their place, because each one saves an agent a context switch at the moment they are deciding whether to act. Keep the write back narrow, set only the columns that action owns, and record who pressed the button. Resist adding a resolve button: closing a case is a decision that belongs on the record with the resolution written down.

Volume control: a digest instead of a card per case

A scheduled flow that posts one card at the start of each shift listing unassigned cases, cases with no first response, and cases ageing past target does more for a busy desk than per case notifications do, and it does not hit connector throttling. On most projects we build both and then turn the per case card down to priority one and SLA at risk within the first month.

Connector configuration: the settings that decide whether it works

The connector reference tells you what each action does. It does not tell you which settings quietly decide the outcome. The third column below is the useful one: each entry is a failure we have either fixed for somebody else or hit ourselves before it reached a client.

Connector and action	Configuration that matters	What goes wrong if you skip it
Microsoft Dataverse: When a row is added, modified or deleted	Change type Added or Modified. Table name Cases. Scope Organization. Set Select columns to the fields you actually read, for example title, ticketnumber, prioritycode, statuscode, and the customer and owner lookups. Add a trigger condition so the flow ignores rows that its own service account has just written.	Scope decides more here than anything else. A flow left on User or Business unit scope works perfectly for the maker and silently ignores every case owned by anybody else. That is the most common reason a Teams notification build passes testing and then appears to do nothing in production.
Microsoft Dataverse: Get a row by ID and Update a row	Get a row by ID resolves the owner, the customer, or the entitlement when the trigger has handed you only a lookup GUID. Update a row is how a card button writes back, and it should set only the columns that button is allowed to change.	An Update a row against the table the flow triggers on will retrigger the flow unless the trigger condition excludes the account the flow runs as. That loop is cheap to create and slow to spot, because it surfaces as duplicated channel posts rather than as a failed run.
Office 365 Users: Get user profile (V2)	Feed it the Dataverse system user's primary email to resolve the Entra ID account behind the agent. That identity is what both an @mention and a direct chat need, and the Dataverse record alone will not give it to you.	Where the Dataverse domain name and the Entra ID user principal name have drifted apart, and after any domain change they usually have, the lookup returns nothing or returns the wrong person. Resolve on primary email and handle the not found branch instead of assuming a match.
Microsoft Teams: Post adaptive card in a chat or channel	Post as Flow bot for system notifications, or as the user when the message should read as coming from a person. Choose Channel for team wide visibility and Group chat for a named set of agents. Take the team and channel identifiers from environment variables rather than from the design time dropdown.	The dropdown bakes the development team and channel identifiers into the flow definition. Import that solution into production and the cards carry on posting into the environment you built them in. Environment variables cost ten minutes at design time and prevent a genuinely embarrassing go live week.
Microsoft Teams: Post adaptive card and wait for a response	This is the action behind a quick action button. It posts the card, waits, and returns both the card inputs and the identity of whoever responded, which is what you write back to the case as the person who acknowledged it.	Only the first response is captured and the run holds open until it arrives or the action times out. In a channel of fifteen agents that is exactly right for an assign to me card and exactly wrong for anything two people are meant to answer. Set the timeout deliberately rather than leaving it open.
Microsoft Teams: Create a chat and Add member to a chat	The swarm pattern. Create a group chat named with the case number, add the owner and the experts you resolved, post the case card as the first message, then write the chat link back to a column on the case so anyone opening the record later can find the conversation.	A chat per case with no naming rule and no link written back is unfindable within a week, and you have quietly built a second place where case history lives. Either name it with the ticket number and store the link, or use the embedded Teams chat on the form and build nothing at all.
Approvals: Start and wait for an approval	Use the Approvals action rather than a card you designed yourself whenever the step is a real authorisation, for example an escalation that commits an engineer or a goodwill credit that costs money. Approvers respond from Teams or Outlook and the decision, the comment, and the timestamp are all recorded.	An approval rolled by hand on an adaptive card leaves no audit trail beyond the flow run history, and run history ages out. If somebody may have to defend the decision months later, this is not the place to save an hour.
Solution components: connection references and environment variables	Build every one of these flows inside a Dataverse solution from the first save. Connection references let the flow authenticate as a service account instead of as the person who built it, and environment variables hold the environment URL, the app id, and the target team and channel.	A flow built under My flows on a maker's personal connection stops working the week that person leaves or their licence is reclaimed, and it cannot be moved between environments without being rebuilt by hand.

Building the case notification flow, step by step

This is the build in the order we do it on a project, from the solution to the failure path. Follow it and you end up with a flow that can be imported into another environment, survives the person who wrote it leaving, and does not post the same case three times. The collaboration chat and the quick action card in the patterns above are variations on the same skeleton, so build this one first.

1
Start inside a solution, never in My flows
Create a Dataverse solution with your publisher prefix and build the flow in it. Add a connection reference for Dataverse, one for Teams, and one for Office 365 Users, all authenticated as a service account rather than as you. Add environment variables for the environment URL, the model driven app id, the target team, and the target channel. Everything after this step assumes those five things exist, and retrofitting them once the flow is live is a rebuild rather than an edit.
2
Configure the Dataverse trigger precisely, then test the scope
Use When a row is added, modified or deleted. Change type Added or Modified, Table name Cases, Scope Organization. Set Select columns to the handful of fields the card needs so the flow does not fire every time server side logic touches an unrelated column. Then verify the scope properly: create a case owned by somebody else and confirm the flow runs. A build that only ever fires for its maker is the standard failure of this integration.
3
Stop the flow from triggering on its own writes
Add a trigger condition that excludes the account the flow runs as, comparing the modified by lookup on the trigger output against the service account GUID. Where the message must fire exactly once per case, add a small flag column on the case, check it in the condition, and set it in the same run. Routing rules, SLA actions, and business logic all write to a new case within seconds of creation, so without this you are posting the same case three times before an agent has read it once.
4
Resolve the audience before you compose the message
Decide who this card is for and turn that into a real identity. Get a row by ID on the owner or the queue, then Office 365 Users Get user profile (V2) on the primary email to get the Entra ID account, then Get an @mention token for that user. Branch on ownership: an unassigned case goes to the team channel, an assigned one goes to the owner as a chat, and an escalation goes to both. Handle the branch where the lookup finds nobody, because a card addressed to no one is worse than no card.
5
Compose the card as data, not as a paragraph
Build the adaptive card with a short title, then a fact set: case number, customer, priority, created time, SLA due time, and the first line of the description. Anything longer is not read on a phone at eleven at night, which is when the cards that matter are read. Keep the card to what a person needs in order to decide the next action, and put the detail behind the link rather than in the message.
6
Build the record deep link from environment variables
The link is the environment URL, then main.aspx with appid set to the model driven app id, pagetype set to entityrecord, etn set to incident, and id set to the case GUID from the trigger. Take the environment URL and the app id from environment variables, because the organisation URL is specific to both the environment and the region it sits in. A card whose Open case button lands in the development environment is the fastest way to lose the support team.
7
Post it with the Teams connector, as the right sender
Post adaptive card in a chat or channel, posting as Flow bot for system notifications and as the user only where the message genuinely comes from a person. Read the team and channel identifiers from the environment variables rather than from the dropdown. For a direct message to an owner, post to a chat with the recipient resolved in the previous step rather than to a channel everybody can see.
8
Convert every timestamp before it reaches the card
Dataverse hands you UTC. Convert with convertFromUtc into the reading time zone before composing the card, or use the adaptive card date and time functions so Teams renders each reader local time. For a team in Yerevan the zone is Caucasus Standard Time and it holds at GMT+4 all year, so a hardcoded four hour offset works here and quietly breaks twice a year for colleagues or clients in Europe whose clocks move and ours do not.
9
Add quick actions only where the write back is safe
Swap the post action for Post adaptive card and wait for a response, and give the card an Action.Submit with a small choice set rather than free text: acknowledge, assign to me, needs escalation. On the response, run Update a row against the case setting only the columns that action is allowed to change, and record the responder identity the action returns so the case shows who claimed it. Anything that needs a genuine authorisation goes to the Approvals action instead, so the decision is recorded outside the run history.
10
Build the failure path, then test with two accounts and with volume
Wrap the Teams and Dataverse calls in scopes with configure run after on failure, and have the failure branch post to an admin channel with the case number and the run link, because a notification flow that fails silently is worse than no notification flow. Then test properly: a second agent account for the scope and the mention, a burst of cases for throttling and readability, and the deep link opened on a phone. If the burst produces a wall of cards, move the routine cases into a scheduled digest before go live rather than after the complaints.

Two of those steps carry most of the value and neither is glamorous. Setting the trigger scope to Organization and testing it with a second agent account is what makes the flow work for the whole team rather than for its author. Putting the environment URL, the app id, and the target channel into environment variables is what lets the same solution move from development to production without editing anything by hand. The same discipline of service accounts, retries, structured failure handling, and monitoring applies to any automation you intend to leave running unattended, and we set it out in full in our guide to Power Automate Desktop production reliability, where the consequences of skipping it are more visible than they are in a cloud flow.

Where the button on the card is a genuine authorisation rather than a status change, use the Approvals action instead of an adaptive card you designed yourself, so the decision, the comment, and the timestamp are recorded outside the run history. The routing, escalation, and audit patterns are the same ones we use for finance sign off, which we work through in how Power Automate approval flows save mid-market finance teams time. A case escalation that commits an engineer for a week deserves the same treatment as an invoice over a threshold.

Troubleshooting: symptom, cause, fix

Problems arrive as symptoms. Nobody reports that the trigger scope is wrong; they report that the notifications only work for one person. This table is ordered the way the problem reaches you, and every row is something we have diagnosed on a live Dynamics 365 Customer Service and Teams build.

Symptom	What is actually happening	The fix
The channel gets the same case posted two or three times within a minute	The Dataverse trigger fires on every column change, and a new case is written to several times in its first seconds by routing rules, SLA actions, and any server side logic you have. Your own Update a row counts as another change.	Set Select columns on the trigger to the fields you actually read, add a trigger condition excluding the service account the flow runs as, and where the message must fire exactly once, gate it on a flag column the same run sets.
It works perfectly for the person who built it and ignores everyone else	The trigger scope was left at User or Business unit, so it only ever sees rows within that scope for the account the flow runs as.	Set Scope to Organization, and make sure the service account behind the connection reference holds a security role that can read every case the notification is meant to cover. Test by creating a case owned by a different agent.
After a solution import, cards keep posting into the development channel	The team and channel were picked from the design time dropdown, so the development identifiers are part of the flow definition and travel with it.	Move both identifiers into environment variables and set their values per environment at import. Do the same for the environment URL and the app id used in the deep link.
The Open case button lands on a blank page or in the wrong app	The URL is missing the appid parameter, or it points at the environment where the flow was built. The organisation URL is specific to the environment and to the region it was created in.	Compose the link from an environment variable base plus appid, pagetype entityrecord, etn incident, and the record GUID from the trigger, and open the exact string once on a desktop and once on a phone before you ship it.
The @mention renders as plain text and nobody is notified	The mention was never resolved to a real Entra ID identity, usually because the flow passed a Dataverse domain name that no longer matches the user principal name.	Resolve the agent with Office 365 Users Get user profile (V2) on their primary email, pass that to Get an @mention token, and branch on the lookup finding nobody rather than posting a card with a broken mention in it.
Every time on the card is four hours out	Dataverse returns UTC and the card prints what it was given. A team reading in Yerevan is at GMT+4, so created and due times are all wrong by four hours.	Convert with convertFromUtc into Caucasus Standard Time before composing the card, or use the adaptive card date and time functions so Teams renders each reader local time. Do not hardcode the offset if any recipients sit in Europe, because their clocks move twice a year and ours do not.
Quick action buttons stop working after the first person clicks	Post adaptive card and wait for a response captures exactly one response and then completes, but the card stays on screen, so the second person to press the button gets nothing back.	Update the card once the response is in so it reads as claimed and names the person who claimed it. Where two people genuinely have to act, use two cards or move the step to the Approvals action.
Notifications stopped one morning with nothing changed on our side	The flow was running on a named person's connection and that person left, changed a password, or lost a licence. Nothing breaks on the day. It breaks weeks later when the connection is finally invalidated.	Run production flows on a service account through connection references, put a second owner on everything that matters, and route Microsoft platform notices to a shared mailbox or a channel somebody actually reads.
A busy hour produces a wall of cards and agents stop reading them	One card per case is right at ten cases a day and useless at two hundred, and it is also the point where Teams connector throttling starts to shape what arrives.	Notify per case only where a human decision is needed, for example priority one or an SLA about to breach, and move everything else into a scheduled digest listing what is unassigned and what is ageing.
The build needs a licence nobody budgeted for	The Dataverse connector is premium. The standard connector tier included with a plan such as Microsoft 365 E3 does not cover it, even though the Teams and Office 365 Users connectors in the same flow are standard.	Check the use rights for your own agreement before design, not after. Dynamics 365 licences carry flow rights within the context of the licensed app, and outside that context a Power Automate premium licence is what covers the flow. Confirm which case you are in with the current Microsoft licensing documentation.

What delivering this from Armenia changes about the build

These are the parts a global documentation set has no reason to cover, and they are the parts that decide whether the support team keeps using the integration after the first month. Each one comes from delivering Dynamics 365 Customer Service and Power Platform work from Yerevan for clients in Europe and the US.

The escalation schedule is not Monday to Friday nine to five

A support team in Yerevan working for a client in Western Europe has two holiday calendars and a working day that overlaps the client by four to six hours. A flow with a hardcoded working week will page people on an Armenian public holiday and stay silent on a day the client expects cover. Drive the schedule from the customer service calendar in Dynamics 365, which is configured once and honoured by both the SLA and the flow, rather than from a condition on the day of week.

Cards get read in three languages, so write the labels in one

Delivery teams here work in Armenian, Russian, and English, often within the same case. Keep the field labels on the card in a single language the whole team reads, and put the customer own words in their own block rather than mixed into a label. Armenian and Russian strings are noticeably longer than the English equivalent, so a card that fits neatly in English wraps badly on a phone once real content arrives.

Check who is in the channel before the card carries customer data

Nearshore delivery normally means at least one shared Teams channel with the client, and shared channels acquire guests. An adaptive card carrying a customer name, a contract reference, and the first line of a complaint is case data, and posting it into a channel with external members is a disclosure decision rather than a design detail. Keep anything with customer detail in an agent only channel and let the shared channel carry the ticket number and the link.

On call means mobile, so test the card on a phone

Out of hours, every one of these cards is read on Teams mobile. Test the rendering, the mention, and the deep link on an actual phone before you promise anyone that the notification is the on call mechanism. A link that opens a browser sign in prompt instead of the record is the difference between a fifteen minute response and a missed one.

The flow outlives whoever built it, including us

We build these as part of a solution on a service account precisely because the person who wrote the flow, whether that is our engineer or an internal maker, will not always be the person who owns it. Connection references, a second owner, environment variables, and a short runbook for each flow are what make a handover an email rather than a project. It is the same discipline we apply to any automation estate we take over.

One last thing worth saying plainly, because it is the honest counterweight to a section this long. Most support teams need two flows and a checkbox, not a programme of work: the embedded Teams chat turned on, one notification card for the cases that warrant interrupting somebody, and one scheduled digest. If you find yourself building the fifth flow to make a case behave like a case, that is the signal discussed further up this page rather than a Teams problem. Where the automation estate is the work, our Power Automate consulting practice covers the build, the takeover of flows somebody else left behind, and the monitoring that tells you a notification stopped arriving before an agent does.

How does total cost of ownership compare over time?

Per-agent pricing is the easy number to compare, and on that line alone Zendesk can look cheaper for a small support team. The costs that actually add up over years are the ones around the edges: a second vendor and contract to manage, a separate identity and admin console to secure, connectors to build and maintain when support needs to reach Teams, SharePoint, or Power Automate, and a separate reporting stack to reconcile against the data already in Dataverse.

For a company already fully on Microsoft 365, Dynamics 365 Customer Service reuses infrastructure that is already paid for and already governed. That does not make it the right answer for everyone, but it is why the long-term total cost of ownership often favors Dynamics for a Microsoft 365 shop, once the integration and administration work is counted rather than just the license line.

Should a team of 15 agents choose Freshdesk or Dynamics 365 Customer Service?

Freshdesk turns up in this decision for a different reason than Zendesk does. Teams shortlist it because it is fast and cheap to start, and they are usually shortlisting it while support is already under water. So the question is rarely which product is better in the abstract. It is whether a team of about 15 agents in a company that already pays for Microsoft 365 should buy a separate help desk this month, or spend those weeks putting cases on the platform it already owns.

Here is the comparison on the terms that actually decide it at this size, then the numbers, then what to do if you need something working before either project can finish.

Factor at 15 agents	Freshdesk	Dynamics 365 Customer Service
Time to a working desk	Genuinely fast. A team of 15 can have a mailbox, ticket forms, canned replies, and a portal running in days with no partner involved, which is why it wins when support is drowning right now.	Slower to a first working desk. Queues, routing, SLAs, entitlements, security roles, and knowledge are all real configuration decisions, and a single module rollout for a team this size is normally measured in weeks rather than days.
Initial cost	Lower on the license line, and the sticker price is the whole visible cost on day one. For 15 agents on a mid tier plan that is a small, predictable monthly number.	Higher on the license line, and a full Customer Service Enterprise seat costs multiples of a mid tier Freshdesk agent. The offset is that the identity, collaboration, content, and automation layers underneath it are already bought.
Identity and offboarding	Supports single sign-on with Microsoft Entra ID, but agents remain a second population to provision, review, and remove. At 15 agents that is manageable by hand, which is exactly why it is usually never automated.	Agents are the Entra ID accounts you already govern. Joiners and leavers, conditional access, and multi-factor policies are the tenant processes you already run, with nothing separate to remember at offboarding.
Where the work already happens	Has Teams and Microsoft 365 apps and connectors. They work, but the case, the Teams thread, and the SharePoint document stay in three systems joined by integrations you own.	Teams is embedded, case documents can sit in SharePoint, and knowledge sits in Dataverse, so the conversation, the file, and the record are one thing under one governance and retention model.
CRM depth	A help desk first. Customer context is what you sync into it. Tying tickets to pipeline, accounts, contracts, or field work means either Freshworks CRM as a second purchase or an integration back to whatever holds the truth.	Cases sit in Dataverse next to accounts, contacts, opportunities, and any other business data you keep there, so support, sales, and reporting share one record with no sync layer to reconcile.
What it costs to leave	Low at 15 agents if you leave early. It rises quickly once automations, a public portal, and two years of ticket history live there, because all of it has to be rebuilt and migrated rather than moved.	The build is solution based and the data is in Dataverse in your own tenant, so extending it, reporting on it, or handing it to another partner does not start with an export.

Freshdesk is a good product and it wins the first two rows outright. Those two rows are also the ones that matter least in year three, which is the whole tension in this decision.

The numbers for 15 agents, including Microsoft 365 E3

Start with the fact that decides the shape of the whole budget: Microsoft 365 E3 does not include Dynamics 365 Customer Service. The two are licensed separately, so your E3 seat count is not your Dynamics seat count. What E3 does include is the platform underneath, which is Entra ID, Teams, SharePoint, and the standard connector tier of Power Apps and Power Automate. That is the asymmetry in this comparison. A Freshdesk subscription is entirely new spend on top of Microsoft 365. A Dynamics 365 Customer Service subscription is an incremental purchase on a platform you have already bought and already govern.

The figures below are Microsoft and Freshdesk list prices at the time of writing, given so the arithmetic is checkable rather than as a quote. Confirm them against your own agreements before you build a budget on them.

Option	Roughly, per year	What the number hides
Freshdesk, 15 agents on a mid tier plan	In the region of 50 USD per agent per month at list, so roughly 9,000 USD a year of genuinely new spend.	This is on top of the Microsoft 365 you already pay for, not instead of it. Any Teams, SharePoint, or reporting bridge you build afterwards is additional effort you own.
Dynamics 365 Customer Service Professional, 15 full agents	About 50 USD per user per month at list, so roughly 9,000 USD a year, which lands in the same place as the Freshdesk line.	Professional is the tier to price first for a team of 15. Check unified routing, entitlements, and the knowledge features you actually need against Enterprise before assuming it fits.
Dynamics 365 Customer Service Enterprise, 15 full agents	About 105 USD per user per month at list, so roughly 18,900 USD a year.	Only worth it if the Enterprise capabilities are genuinely used. Putting all 15 people on Enterprise by default is the single most common way this comparison is lost on price.
A realistic mix: 9 Enterprise agents, 3 attach, 3 Team Members	Nine full seats at about 105 USD, three attach licenses at about 20 USD for people who already hold a full base license in another Dynamics 365 app, and three Team Members at about 8 USD, which is about 1,029 USD a month or roughly 12,350 USD a year.	This is the base plus attach model doing its job. A team of 15 is almost never 15 full agents, and the three way split between full, attach, and light users is where the real saving is.
The Microsoft 365 E3 you already own	No new license spend for SharePoint Lists, Teams, and the standard connector tier of Power Apps and Power Automate that E3 already includes.	Microsoft 365 E3 does not include Dynamics 365 Customer Service. It does include enough of the Power Platform on standard connectors to run the crisis playbook below while you decide properly.

Two things fall out of that table. First, on the license line alone Freshdesk and Dynamics 365 Customer Service Professional land in roughly the same place for 15 agents, so the cheaper option is not as cheap as the tier comparison suggests, and the argument has to be settled on integration and CRM depth rather than on price. Second, the expensive way to buy Dynamics is to put all 15 people on Enterprise seats without asking who actually needs one. A team of 15 is rarely 15 full agents. Splitting them into full users, people who already hold a full base license in another Dynamics 365 app and therefore qualify for an attach license, and light or read mostly users on Team Members is where the base plus attach model earns its keep. We work that split, and how to hold it at renewal, in our guide to Dynamics 365 licensing costs and renewal negotiation.

The line the license comparison never shows is implementation. Freshdesk for 15 agents is largely self serve. Dynamics 365 Customer Service is a configuration project, and whether you need help with it is a real question with a real answer rather than a foregone conclusion. Our decision guide on hiring a Dynamics 365 consultant versus doing it yourself names the specific walls where a configuration-only build stops working, so you can price the honest version of this comparison instead of the optimistic one.

The crisis playbook: a ticketing system inside the tenant you already own

Most teams comparing Freshdesk against Dynamics 365 at 15 agents are not making a calm architectural choice. Support is on shared mailboxes and spreadsheets, something has been missed, and the platform decision is being taken under pressure by whoever can sign fastest. That is the worst possible condition for a decision you will live with for years.

So separate the two problems. Stop the bleeding this week inside Microsoft 365 with no new licenses and nothing signed, then choose the permanent platform next month on evidence you collected in the meantime. Here is how we build that bridge, using SharePoint Lists, Power Automate, and Power Apps on standard connectors only, with no Dataverse and no premium connectors, which is what keeps it inside the E3 rights you already pay for. Confirm the current use rights in the Microsoft Product Terms for your own agreement before you rely on that.

1
Create the ticket list in SharePoint
In a SharePoint team site the support team already uses, create a list called Tickets. Columns: Title, Requester (Person), Requester Email (Text, for people outside the tenant), Description (Multiple lines), Status (Choice: New, Assigned, Waiting on customer, Resolved), Priority (Choice), Assigned To (Person), Received (Date and time), First Response (Date and time), Resolved (Date and time), and Source (Choice: Email, Teams, Phone). Set Received and Status defaults so nothing is ever created blank.
2
Point the shared mailbox at it
Build a Power Automate flow on the When a new email arrives in a shared mailbox trigger for support@yourcompany. Create a list item, map subject to Title, body to Description, sender to Requester Email, set Status to New and Received to the received time, then reply to the sender with the item ID as a reference. This is the only step that must work perfectly, so test it against a real mailbox before you tell anyone the desk exists.
3
Assign work with a rule you can explain
Do not attempt clever routing in a stopgap. Either assign manually from a Team channel each morning, or add a second flow that sets Assigned To from a small Rota list, cycling through the agents on shift. A round robin everyone understands beats routing logic nobody can debug at week three.
4
Give agents a view, not an app, on day one
Create list views: My open tickets, Unassigned, Waiting on customer, and Resolved this week, with column formatting so priority and age are visible at a glance. Add the list as a tab in the support Teams channel. Most teams of 15 need nothing more than this, and every hour spent on UI before the intake is reliable is an hour spent on the wrong thing.
5
Add a Power Apps canvas app only where the list falls short
If agents genuinely need a faster triage screen, or a phone intake form, build a canvas app over the same SharePoint list. Keep it to the two screens that earn their place: a filtered queue and an edit form. The list stays the source of truth, so the app is disposable and nothing is lost if you abandon it.
6
Automate the chasing, not the thinking
Add a scheduled recurrence flow that posts an adaptive card to the support Teams channel listing tickets with no first response, tickets older than your target, and anything left unassigned. This is not an SLA engine and should not pretend to be one, but it is the behaviour that an SLA engine mostly buys you, and it takes an afternoon.
7
Report from the list before anyone asks
Group views by status and assignee, and if you need more, point Power BI Desktop at the SharePoint list. Capture volume per week, first response time, and backlog age from the first day. This data is what makes the permanent platform decision an evidence based one rather than an argument, and it is why the stopgap is worth doing properly.
8
Know exactly where this breaks
Be honest about the ceiling: SharePoint list views degrade past the 5,000 item threshold without indexed columns, there is no entitlement or contract model, no real SLA pause behaviour, no customer facing portal without more work, per item permissions get unpleasant if tickets must be private, and Power Automate flow runs are capped by your plan. This is a bridge for weeks or a few months, not an architecture.
9
Set the exit date on the day you build it
Write down the date you will decide, who decides, and the numbers that will decide it. Because tickets are rows in a list with clean columns, migrating them into Dynamics 365 Customer Service cases or into a help desk later is an ordinary data load rather than a rescue. A stopgap with no exit date is how organisations end up running support on a spreadsheet for four years.

Built this way, the stopgap is not wasted work even when you go on to buy Freshdesk. You end up with clean intake, real volume and response data, and a written decision date, and those three things are worth more to the platform choice than another week of vendor demos. If the reason you are in this position is a Dynamics 365 or Power Platform rollout that stalled rather than a desk you never had, that is a different problem with a different fix, and our guide to rescuing a failed or stalled Dynamics 365 implementation covers how we assess and take those over. Where the answer is to do this properly on Dynamics 365, our Dynamics 365 Customer Engagement consulting practice runs the implementation, and we are happy to build the bridge above first and the permanent desk second.

Should a business in Armenia choose Dynamics 365 or HubSpot?

For a business in Armenia choosing between Dynamics 365 and HubSpot, the honest short answer is this. HubSpot is the better fit when growth is marketing led, the sales process behind it is short, and you need something live in weeks with no configuration project. Dynamics 365 is the better fit when your company already runs Microsoft 365 for mail, documents, and Teams, when selling is complex enough to need quotes, negotiated pricing, approvals, and several people writing to one customer record, or when expansion into a second currency, a second legal entity, or a second country is on the plan. Three things decide it locally rather than globally: both vendors bill in USD while you budget in dram, only one of them can be implemented by a partner sitting in your own time zone, and only one of them ships a Russian interface. Everything below is the working for that answer.

HubSpot belongs on this page for the same reason Zendesk and Freshdesk do. It is the standalone product a Microsoft 365 company shortlists without asking what the Microsoft tenant already gives them. The difference is that HubSpot arrives from the marketing side, so the comparison runs on a different axis: marketing led growth against complex selling, rather than ticketing features. We write this from Yerevan, so the parts a comparison produced elsewhere cannot cover, meaning currency, invoicing, partner coverage, language, and what a second country actually costs, are the parts we have spent the most words on.

1. Pricing, and what USD list prices mean when you budget in dram

Every figure below is vendor list price at the time of writing, published so the arithmetic is checkable rather than as a quote. Confirm each one against your own proposal before you build a budget on it. The right hand column is the part that a comparison written in London or Boston never contains.

Line	List price at the time of writing	What it means for an Armenian company
HubSpot Sales Hub Professional	In the region of 100 USD per seat per month at list, with the better price attached to an annual commitment, plus a one time onboarding fee on the Professional tier.	Billed in USD by an overseas vendor, normally on a corporate card or a SWIFT transfer. The dram cost of a twelve month commitment therefore moves with the AMD to USD rate across the term, so the figure finance approved in January is not the figure they pay in December. Ask what document you receive as well: a card receipt in USD is a harder object for Armenian bookkeeping than a proper invoice.
HubSpot Marketing Hub Professional	From roughly 800 USD per month at list for a bundle that includes a small number of seats and a marketing contact allowance, stepping up as the contact list grows, plus a one time onboarding fee.	This is the line that surprises buyers here, because it scales with the size of your database rather than with headcount. A six person sales team with fifty thousand contacts is paying for the contacts. If your growth plan is to reach far more people with the same small commercial team, this curve is the whole comparison and you should model it over three years rather than one.
Dynamics 365 Sales Professional	About 65 USD per user per month at list.	Also priced in USD, but buyable through a Microsoft Cloud Solution Provider, and a reseller in the region can put the subscription on a local invoice. Ask any reseller directly whether they bill in AMD and how VAT at 20 percent is presented, rather than assuming it either way.
Dynamics 365 Sales Enterprise	About 105 USD per user per month at list.	Worth the step up only where the Enterprise capabilities are genuinely used. Putting an entire Armenian sales team on Enterprise by default is the most common way this comparison is lost on price before anyone has looked at a feature.
Team Members and attach licences for everyone else	Team Members at about 8 USD per user per month, and an attach licence at about 20 USD for a user who already holds a full base licence in another Dynamics 365 app.	Most mid-market companies in Yerevan have four or five people who genuinely sell and a dozen who need to read. HubSpot has its own free and view only seat arrangements, so compare the equivalent split on both sides instead of multiplying the headline seat price by your total headcount.
The Microsoft 365 you already pay for	No new licence spend for Microsoft Entra ID, Teams, SharePoint, and the standard connector tier of Power Apps and Power Automate.	Most companies in Yerevan choosing a CRM already run Microsoft 365 for mail and documents. That is the asymmetry in this comparison. A HubSpot subscription is entirely new spend on top of what you have. Dynamics 365 is an increment on a platform already bought, already governed, and already invoiced through a supplier your finance team has onboarded.
Implementation, which neither price page shows	Not a licence line at all. It is engineer days, and the total depends far more on where you buy them than on which product you buy.	A senior certified engineer from a Yerevan consultancy sits in a very different rate band from a Western European one, and on a project that is mostly configuration that gap is the single largest lever on the total cost. Because HubSpot delivery in this region is normally sourced from outside it, the implementation line is often where the cheaper licence stops being the cheaper project.

Two conclusions fall out of that table for a buyer here. The licence lines are closer than the marketing suggests once you count the seats you actually need rather than your total headcount, so price alone will not settle this. And the line that decides the real total is implementation, which appears on neither vendor price page. Our guide to hiring a Dynamics 365 consultant versus building it yourself compares relative partner cost by region, from Yerevan to Western Europe, and publishes effort ranges per line item such as migration, integration, and custom pricing logic, so you can assemble that number yourself instead of waiting for a proposal to tell you what it is.

2. Complex sales processes against marketing led growth

This is the axis that actually separates the two products, and it is worth being blunt about it: they were built for different motions and each one wins where it was built to win. The useful question is which motion describes your company in two years, not today.

Factor	HubSpot	Dynamics 365
Where each one is genuinely strongest	Marketing led growth. Landing pages, forms, email nurture, lifecycle stages, and attribution reporting work out of the box and work well. If your pipeline is created by content and inbound, HubSpot is built around exactly that motion and it shows.	Complex, multi stakeholder selling. Long cycles, several people writing to one customer record, quotes and negotiated pricing, approval steps, and a process that has to be enforced rather than suggested.
Quotes, pricing, and discounts	Products, quotes, and an approval step are present and are fine for a standard price list. Pricing that depends on a customer specific agreement with validity dates, compounding tiers, bundles, or a margin floor that must block a save is where teams quietly move the calculation back into a spreadsheet.	Price lists, price list items, discount lists, and unit groups ship in the product, and anything the price list cannot express runs as server side logic in Dataverse, so it applies whether the record arrived from a form, a bulk import, or an integration.
Process enforcement	Deal stages with required properties, plus workflows on the higher tiers. Good guidance, largely convention, and straightforward for a seller in a hurry to route around.	Business process flows with stages and branching by deal type, business rules on the form, and server side logic that cannot be skipped. That distinction is irrelevant until the process protects a margin, a compliance step, or an approval, which is precisely the complex sales case.
The marketing engine itself	One product, one login, and the strongest part of the offering. This is the honest point in its favour and it is a real one, not a courtesy.	Journeys, segments, and marketing automation sit in Dynamics 365 Customer Insights, which is a separate purchase and a separate configuration effort. If marketing automation is the actual requirement and the sales process behind it is simple, HubSpot is the shorter road and we would tell you so.
Reporting beyond the CRM	Dashboards and the custom report builder inside HubSpot are capable. Putting CRM numbers next to operational or accounting data means an export, a connector, or a warehouse that somebody has to maintain.	Records live in Dataverse, so Power BI reads them directly alongside anything else already in your tenant, with no export layer and no second copy of the customer to reconcile at month end.
The ceiling when standard is not enough	A solid API, custom objects on the top tier, and an app marketplace. A genuinely custom screen means building an external application against the API and asking users to leave the CRM to use it.	PCF controls written in TypeScript and React run natively on the form, alongside custom API and plug-ins, and ship as managed solutions with source code you own. That is the difference between extending the product and building beside it.

HubSpot wins the marketing rows outright and it is not close. Dynamics 365 wins wherever the process has to be enforced rather than suggested, and wherever the customer record has to be shared with people who are not in sales. Most Armenian mid-market companies we speak to sit on the second side of that line and did not realise it until the first time a discount had to be approved by someone who does not use the CRM.

3. Scalability when you grow out of the Armenian market

Armenia is a small market, so growth here means leaving it: Georgia first for many companies, then the Gulf, the EU, or the US. That makes expansion a design requirement on day one rather than a later problem, and it is where a CRM decision quietly becomes expensive. These are the five things that are cheap to decide now and costly to retro fit after two years of records.

Selling in more than one currency

The moment an Armenian company sells outside the dram, and most eventually do, the CRM has to hold a base currency and transaction currencies with their own rates, so an opportunity in EUR, a quote in USD, and an order in GEL still roll into one forecast. Dynamics 365 Sales does this in the product, with the exchange rate stamped on the record at the time of the deal. Check how any shortlisted CRM reports a mixed currency pipeline before you have one, because adding it after two years of history is a data migration rather than a setting.

The interface language your team actually works in

This decides more rollouts in this region than feature lists do. Dynamics 365 ships user interface languages including Russian and English, which is what most teams in Yerevan work in day to day. Armenian is not among the shipped Dynamics 365 interface languages at the time of writing, so plan on a Russian or English interface with Armenian in the data. On the other side, the HubSpot product interface does not ship in Russian at the time of writing. Verify the current language lists on both products yourself before shortlisting, because for a mixed language team this is a hard blocker and not a preference.

Opening a second entity in Georgia, the Gulf, or the EU

Regional expansion usually arrives as a second legal entity before it arrives as a second office. Dynamics 365 handles that with business units, teams, and hierarchy security, so a Tbilisi or Dubai team owns its own records while the group still reports on one pipeline. HubSpot addresses the same need with teams and partitioning on its higher tiers. The question to put to both is not whether it is possible but which tier it requires and what that tier costs at your seat count once you get there.

Where the data sits and who you have to satisfy about it

Armenian companies selling into the EU end up signing a data processing agreement whether they expected to or not, and Armenian personal data rules apply at home regardless. Both vendors offer European hosting, so that is not the differentiator. The practical difference is that with Dynamics 365 the hosting region is a decision you already made for your Microsoft 365 tenant and the data processing agreement is one you already have with Microsoft, rather than a second vendor assessment and a second contract for your lawyer to read.

Which cost curve you are actually on

Dynamics 365 scales with the number of people who need a seat. HubSpot Marketing scales with the number of contacts in the database. Those are different growth stories, and for a company reaching a far larger audience with the same small commercial team the two curves cross at some point. Model both over three years against your own contact growth rather than a vendor example, because that crossing point, not the day one price, is the number that should decide it.

What leaving costs, in both directions

A Dynamics 365 build is solutions and data in your own tenant, so extending it, reporting on it, or handing it to a different partner does not begin with an export. That matters more in a small market than a large one, because the number of firms who could take the system over is smaller and you want none of those options foreclosed. Ask the same question of every platform you shortlist and treat a vague answer as the answer.

4. Local partner support in Armenia and the Caucasus

Software is bought once and supported for years, and in a market this size the question of who will still be available to fix it matters more than it does in a large one. This is the section where the two platforms differ most for a buyer in Yerevan, and it has nothing to do with features.

Partner coverage in Armenia and the Caucasus

Microsoft has a partner ecosystem in this region, and Dynamics 365 Customer Engagement work can be bought from a company registered and staffed in Yerevan. Solzet is one of them. For HubSpot, the Solutions Partner directory at the time of writing points an Armenian buyer to firms in Türkiye, Poland, the Gulf, or further west, so implementation, customization, and rescue tend to be remote and priced in a Western band. Check the current directory for your own location rather than taking our word for it. It is the most checkable claim on this page and we would rather you verified it.

The same working day, not an overlapping one

Armenia is GMT+4. A Yerevan or Tbilisi team gets a whole shared working day with a local partner, and roughly six to eight hours with the UK and Western Europe. A vendor support queue running on US Eastern time answers your morning problem after your day has finished. That is survivable for a question and expensive during a go live week.

Armenian, Russian, and English on the delivery team

Requirements get gathered in the language the business actually runs in. Our engineers work in Armenian, Russian, and English, so a workshop with a sales director in Yerevan does not have to happen in a second language, and the documentation can be produced in whichever one your team will genuinely read afterwards.

Certification you can verify by name

Microsoft certifications are held by individuals and can be checked. For Customer Engagement and the Power Platform, ask for PL-200, PL-400, and PL-600, and MB-210 or MB-230 depending on the app, and ask for them for the engineers who will build rather than the people who present. Run that check on every partner in this region, including us.

Who owns the result in year two

Whichever platform you choose, agree before signing who owns the source, the solutions, and the documentation, and what support looks like once the project is over. On our side that answer is fixed: the solutions, the code, and the documentation are yours, and support ranges from a part time consultant of around twenty hours a month up to a managed team.

How to source Dynamics 365 delivery in this region is a longer subject than one section, including how a local consultancy compares with a freelancer, a global integrator, or a distant offshore agency, and what to ask each of them. Our local delivery guide for Dynamics 365 and Power Platform in Yerevan covers those models side by side and includes the due diligence checklist to run over any partner here, including us.

5. The Microsoft 365 integration HubSpot cannot match

HubSpot does integrate with Microsoft 365, so it is worth stating exactly what the integration is and where it stops rather than pretending it does not exist. Each point below names the HubSpot equivalent first. The pattern is consistent: with HubSpot the connection is a surface you configure, own, and maintain, and with Dynamics 365 it is the same underlying service running the rest of your tenant.

•One identity. Dynamics 365 authenticates against the same Microsoft Entra ID as the rest of Microsoft 365, so conditional access, multi factor policies, and the leaver process you already run cover the CRM automatically. HubSpot supports single sign on, but it sits in the higher tiers and its users remain a second population to provision, review, and remove at offboarding.
•Teams as the place the work happens. The Dynamics record can be surfaced and worked on inside Teams, where the conversation about the deal already is. HubSpot has a Teams application for notifications and calling, which is useful, and it is still a bridge between two systems rather than one working surface.
•Documents under governance you already have. Opportunity and case documents can live in SharePoint under your existing retention, search, and permissions model. HubSpot keeps files in its own file manager, which is fine until someone asks where a signed contract is and the answer is a different system with a different retention policy and a different leaver process.
•Outlook and Excel as first class citizens. Sellers work the pipeline from the Outlook app and pull a live refreshable grid into Excel. For an Armenian sales team those are the two tools already open all day, so adoption is not competing with a new habit.
•Automation you have already licensed. Power Automate drives approvals, notifications, and document generation using connectors your tenant already owns. HubSpot is reachable from Power Automate too, and that connector is an integration surface you configure, own, and maintain rather than a shared runtime.
•Reporting without a second copy of the truth. Power BI reads Dataverse directly, so CRM numbers sit next to whatever else your tenant holds. Getting the same picture out of HubSpot means an export or a warehouse, and the monthly reconciliation that comes with it.
•One vendor, one agreement, one admin surface. For a finance team in Yerevan that is one less international supplier to onboard, pay in foreign currency, and account for. That is a rounding error in a large company and a real saving of somebody’s time in a company of forty people.

None of that makes HubSpot a bad product. It makes it a second platform. For a company in Yerevan already paying for Microsoft 365, the choice is between adding a module to a platform you already own and already govern, or onboarding a second international vendor with a second identity store, a second document store, a second reporting stack, and a second invoice in foreign currency. That calculation is the same one this whole page makes about Zendesk and Freshdesk, and it lands in the same place for the same reasons. What that second platform costs in connector licences, where its workflow engine stops, and how the two automation models differ are worked through line by line in the Microsoft ecosystem decision section below.

Which one to choose, stated plainly

Choose HubSpot when

•Growth is marketing led. Pipeline is created by content, inbound, and email, and the sales process behind it is short enough that one person owns a deal from first touch to signature.
•You need something working in weeks with no configuration project and no partner, and that speed is worth more to you right now than depth.
•Nobody needs the CRM joined to service, field work, operations, or accounting. Sales is a self contained function and you expect it to stay that way.
•Your company does not really run on Microsoft 365, in which case most of the integration argument on this page simply does not apply to you.

Choose Dynamics 365 when

•You already run Microsoft 365 for mail, documents, and Teams, which in Yerevan describes most mid-market companies.
•Selling is complex: several stakeholders, quotes, pricing that is negotiated rather than listed, approvals, and cycles measured in months rather than days.
•Expansion is on the plan. A second currency, a second legal entity, or a second country inside two years all favour a platform that treats those as configuration rather than as a tier upgrade.
•Part of your team needs the product interface in Russian.
•You want a partner in the same city and the same working day, and an answer during your afternoon rather than after it.
•You expect the system to be genuinely customized to how you sell, rather than configured from a menu and then worked around in a spreadsheet.

If the answer is Dynamics 365, the work itself is ordinary and the people who do it are in Yerevan. Our Dynamics 365 and CRM developers in Armenia build the Dataverse model and security roles, the pricing and approval logic that has to run server side, the migration off HubSpot or off spreadsheets with relationships and history preserved, the integrations to whatever else you run, and the custom PCF controls in TypeScript and React where the standard form is not enough. If the answer is HubSpot, we will say so on the call and you will have lost an hour rather than a year.

Should a Microsoft 365 shop choose Dynamics 365 CE or HubSpot?

For a company already running Microsoft 365, the Dynamics 365 Customer Engagement against HubSpot decision is not settled by the seat price. It is settled by three things the price pages do not show: what the HubSpot integrations into Microsoft actually cost once you count tier upgrades, Operations Hub, and the premium connector licence inside Power Automate; whether your business process still fits inside the HubSpot workflow engine once it involves multi stage approvals and custom SLA rules; and whether you want automation to be one runtime shared with the rest of your tenant or a second layer you own and staff. Below is each of those with the arithmetic shown, and then a decision matrix by user count, process complexity, and how much Microsoft 365 you already run. Two of its six rows point at HubSpot, because for those companies HubSpot is the right answer.

The section above answers this comparison for a buyer in Armenia, where currency, invoicing, partner coverage, and interface language decide it. This one answers the architectural version of the same question, which is the one a Microsoft 365 shop anywhere arrives with. If the terms Customer Engagement and Dataverse are new, our overview of what Dynamics 365 Customer Engagement is and why Dataverse sits underneath it is the shorter read to take first, because the whole argument below rests on that one platform being shared.

1. The true cost of the HubSpot connectors against native Entra ID and Dataverse

HubSpot integrates with Microsoft 365 and we are not going to pretend otherwise. The question is what each of those integrations costs and who maintains it, because on the Microsoft side the same capabilities are properties of the platform rather than purchases. Every figure below is vendor list price at the time of writing, published so you can check the arithmetic rather than as a quote. Confirm each against your own proposal.

What you are buying	HubSpot on Microsoft 365	Dynamics 365 CE on Microsoft 365
Single sign on against Microsoft Entra ID	Single sign on sits in the higher HubSpot tiers at the time of writing, so joining the CRM to the identity you already govern is a tier upgrade multiplied across every seat rather than a setting. HubSpot users remain a second population to create, review, and remove when somebody leaves.	Dynamics 365 Customer Engagement authenticates against the same Entra ID tenant as the rest of Microsoft 365. Conditional access, multi factor policy, group based licensing, and your existing joiner and leaver process cover the CRM from day one with no additional licence line.
Keeping CRM data in step with everything else	Two way data sync and programmable automation live in Operations Hub, a separate hub priced from roughly 800 USD per month at list on the Professional tier at the time of writing. Check the current figure yourself. Whatever it is, it is the price of keeping a second copy of the customer honest.	Records sit in Dataverse, and every Dynamics 365 Customer Engagement app, canvas app, flow, and report reads and writes that same store. There is no sync product to buy because there is no second copy to reconcile at month end.
Reaching the CRM from Power Automate	The HubSpot connector in Power Automate is a premium connector. Any user who runs a flow that touches it needs Power Automate Premium at about 15 USD per user per month, or a per flow plan at about 100 USD per flow per month. This is the line that most often turns a free integration into a budget item, and it is worth pricing before the contract rather than after.	The Dataverse, Teams, Outlook, SharePoint, and Approvals connectors that Dynamics 365 Customer Engagement flows use are standard connectors, and the Dataverse use rights come with the Dynamics 365 licence itself. The automation you build is covered by what you have already bought.
Where signed documents end up	Files live in the HubSpot file manager. Landing contracts and case attachments in SharePoint under your existing retention and permissions model means a marketplace app or a scheduled job, plus whoever owns it in year two.	SharePoint document integration is configuration inside the product, so opportunity and case documents inherit the search, retention, and permissions your tenant already applies to everything else.
Reporting next to the rest of the business	The dashboards and custom report builder inside HubSpot are capable and this is not a weak point. Putting those numbers beside operational or finance data still means an export, a sync tool, or a warehouse, each with its own subscription and its own owner.	Power BI reads Dataverse directly, and for larger analytics Dataverse can surface the same tables into a lake without a bespoke export job. The CRM numbers and the rest of the tenant data sit in one place from the start.
Modelling something the standard objects do not cover	Custom objects arrive on the top tier at the time of writing, so one unusual entity, a vessel, a policy, a subscription line, can move an entire seat count up a tier before a single field is created.	Custom tables, relationships, alternate keys, and column level security are part of the platform rather than a tier. Modelling the thing your business actually sells is a design decision, not a purchasing one.
How many agreements finance is administering	A separate vendor, a separate contract, a separate admin console, a separate security review, and a separate renewal date, plus whatever the connector and hub lines above add to it.	One Microsoft agreement, one set of admin centers, and one security posture covering identity, documents, collaboration, and the CRM together.

The pattern is the same in every row and it is worth naming once. With HubSpot, integration with Microsoft 365 is a set of products and tiers you buy, configure, and then own for as long as you run it. With Dynamics 365 Customer Engagement it is the same identity, the same data store, and the same automation engine your tenant is already running, so there is nothing to buy and nothing sitting between two systems. Neither is free. One of them is already paid for.

2. Where complex processes outgrow the HubSpot workflow engine

HubSpot workflows are a good tool and most companies never reach the end of them. These are the five places we have actually watched a process arrive at the edge, and they are worth checking against your own before you sign anything, because every one of them is cheap to design for now and expensive to discover in month nine.

Approvals with more than one stage

HubSpot workflows can notify an approver and wait, and quote approval exists on the higher tiers for that specific object. The pattern that does not fit is a chain: the regional manager first, then finance only if the discount passes a threshold, then legal only if the terms are non standard, with delegation while somebody is on leave, a full audit trail, and a deal that genuinely cannot advance until each stage returns. In Dynamics 365 Customer Engagement that is a Power Automate approval writing state back to Dataverse and a business process flow stage that refuses to move, which is a configuration exercise rather than a workaround.

SLA rules that pause, warn, and differ per customer

Service level targets that count working hours only, stop while the case is waiting on the customer, restart on their reply, warn at eighty percent of the clock, and run to a different target for the customers who negotiated one are the normal shape of a support contract. Dynamics 365 Customer Service expresses that with entitlements, SLA KPI instances, and pause conditions, and where the standard rules genuinely cannot say it, a plugin can. We have written up what goes wrong with those timers in practice on our page about fixing Customer Service SLA timer pauses.

Rules that cannot be routed around

A HubSpot workflow reacts to a record that has already changed, and required properties on a deal stage are guidance that a seller in a hurry can work around by editing elsewhere. Dynamics 365 Customer Engagement can run logic inside the Dataverse event pipeline, so a margin floor, a mandatory approval, or a validation applies identically whether the record arrived from a form, a bulk import, an integration, or the API. That difference is invisible until the day the rule is protecting a margin or a compliance step.

What happens when automation fails at three in the morning

Both platforms will tell you that something failed. The useful question is what you can do about it. Power Automate gives you run history per record, a retry policy on the action, a configure run after path for the failure case, and an alert into the Teams channel of the team who owns the process. Building the failure path is part of the normal work rather than an extra product, and on a process that touches money it is the part that has to exist before go live.

Changing the process without changing production

Automation that carries real process needs somewhere to be tested. Dynamics 365 Customer Engagement work moves through development, test, and production environments as managed solutions, held in Azure DevOps or GitHub, with the two Microsoft release waves a year tested before they land. Ask any platform on your shortlist where a change is authored, how it is tested against real data, and how it is promoted, and treat editing live in the production portal as the answer it is.

The SLA point in particular has a longer version, because pause conditions are where most Customer Service implementations go wrong: read how we fix SLA timers that will not pause. If none of the five paragraphs above describe your process, take that as the answer it is: the workflow ceiling is theoretical for you, and this section should not move your decision.

3. Power Platform as a shared runtime against an API first automation layer

This is the strategic part of the decision and the part usually argued dishonestly, in both directions. Committing to the Power Platform is a commitment, and it has a bill. So does running a separate automation layer. Here are both, so you can decide which one you would rather carry.

One runtime, not one more integration

The flows that route a case, chase an approval, generate a document, and post to a Teams channel run on the same Power Automate that already automates the rest of your tenant, using connectors that tenant already owns. The CRM is not something the automation reaches out to. It is one of the things the automation is made of, which is why adding the next process is usually a day rather than a project.

API first is real, and it is a different thing

The HubSpot API is good, the webhooks work, and custom coded actions exist on the higher tiers. That is genuinely more open than the marketing pages of most competitors, and we would not pretend otherwise. It is still a separate automation layer: the code runs at HubSpot or in hosting you provide, with credentials to rotate, logs to watch, and a developer who owns it. Two automation layers is not a fatal architecture. It is a second thing to staff.

What the Microsoft commitment actually costs

The honest version of the trade is this. Choosing Power Platform commits you to Dataverse capacity, to premium licence tiers when a flow leaves the standard connectors, to an environment strategy somebody has to own, and to testing two release waves a year. Those are real obligations and we would rather you priced them at the start than discovered them in month nine. What you get for accepting them is that the CRM, the automation, the identity, and the reporting are one platform instead of four contracts.

The exit, asked of both sides

A Dynamics 365 build is managed solutions and data inside a tenant you own, exportable, with the source code yours by contract, so handing it to a different partner does not begin with a migration. HubSpot data exports too. Put the same question to every platform you shortlist, in the same words, and treat a vague answer as an answer.

Where we would not push the Power Platform

If the only automation your company will ever need is marketing nurture, form routing, and a lifecycle stage that updates itself, Power Platform is a layer you do not need and HubSpot does that work well out of the box. We say this on calls often enough that it belongs on the page. The argument in this section starts to matter when the automation has to reach outside the CRM, and until it does it is theoretical.

4. The decision matrix: user count, process complexity, and Microsoft 365 investment

Find the row that describes your company and read across. Where two rows fit, the one with the more complex process wins, because process complexity is what changes over the life of a CRM while headcount only grows.

Commercial users	Process complexity	Microsoft 365 investment	What we would recommend
Up to about 10 commercial users	Linear pipeline, one owner per deal, no approvals, a standard price list	Microsoft 365 for mail and files, lightly governed	HubSpot. Most of the ecosystem argument on this page needs scale to pay for itself, and at this size the faster start is worth more than the integration.
10 to 25 users	Marketing led growth, quotes rarely negotiated, one approver at most	Microsoft 365 E3 across the company, Entra ID properly governed	Genuinely close, and the connector and hub lines in the table above decide it. Price Power Automate Premium and Operations Hub into the HubSpot column before you compare, then choose.
10 to 50 users	Multi stage approvals, negotiated pricing, custom SLA rules, several people writing to one customer record	Microsoft 365 E3 or E5, with Teams and SharePoint in daily use	Dynamics 365 Customer Engagement. This is the company the rest of this page is written about, and the workflow ceiling above is the reason rather than the licence price.
50 users and up, or more than one legal entity	Any	Microsoft 365 is the identity and document plane for the whole company	Dynamics 365 Customer Engagement. At this size the second identity store, the second document store, and the access review nobody owns are the real cost, not the seats.
Any size	Any	No Microsoft 365, or the company runs on Google Workspace	Judge on features and price alone, and HubSpot will often win that. Every argument in this section is void without the tenant underneath it.
Any size	Marketing automation is the actual requirement and the sales process behind it is short	Any	HubSpot. Journeys and segmentation on the Microsoft side mean Dynamics 365 Customer Insights, which is a separate purchase and a separate project, and we would tell you so on the call.

If the matrix lands you on Dynamics 365 Customer Engagement, the build is ordinary work and the shape of it is known: the Dataverse model and security roles, the approval and pricing logic that has to run server side, the SLA and entitlement configuration, the migration off HubSpot with relationships and history preserved, and PCF controls in TypeScript and React where the standard form is not enough. Our Dynamics 365 and CRM developers in Armenia do exactly that, on your tenant, with the solutions and source code yours by contract. If the matrix lands you on HubSpot, that is a fine outcome and there is no call to book.

What does Solzet deliver on a Dynamics 365 Customer Service project?

If Dynamics 365 Customer Service is the right call, here is what the work looks like. Every point below maps to how we deliver Dynamics 365 Customer Engagement and Power Platform work today.

Customer Service implementation on your tenant

We configure Dynamics 365 Customer Service against your existing Microsoft 365 tenant: queues, routing, SLAs, entitlements, and the knowledge base, wired into Entra ID, Teams, and SharePoint from the start rather than retrofitted later.

Automation with Power Automate

We build the case routing, approvals, and notification flows in Power Automate, reusing the connectors and identities your tenant already has, so the automation is maintainable by your team and not locked behind a third-party console.

Custom PCF controls where the standard UI falls short

When agents need something the out-of-the-box form does not give them, we build custom PowerApps Component Framework controls in TypeScript and React that run natively on the case form, shipped as a managed solution with source.

Project rescue if a rollout has stalled

If a Dynamics 365 Customer Service or Power Platform rollout has stalled or drifted from the plan, we take it over, stabilize it, and get it back to a supportable state, on a direct or white-label basis for Microsoft partners.

Explore our Dynamics 365 consulting and Power Platform consulting services, or read how we fix Customer Service SLA timers.

So which should a Microsoft 365 shop choose?

If customer service is a standalone function and you want a proven help desk live quickly, Zendesk is a reasonable choice and a genuinely good product. It stands on its own, and for a team that does not need cases wired into the rest of the business, that simplicity is a feature.

If you are already fully on Microsoft 365, the calculus changes. Dynamics 365 Customer Service runs on the same identity, collaboration, content, and automation you already own, which lowers admin overhead, keeps agents in the tools they already use, and reduces long-term total cost of ownership. Solzet implements it on your tenant, wires it into Entra ID, Teams, SharePoint, and Power Automate, and builds the custom pieces where the standard product falls short.

And if neither fits, because your service process is specific to your business but per agent Microsoft licensing does not pay back, there is a third route. We recommend the right solution, whether that is Dynamics 365, the Power Platform, or a custom-built CRM and help desk on a stack you own with no per user licences.

What do Microsoft 365 shops ask about Dynamics 365 Customer Service vs. Zendesk?

Is Dynamics 365 Customer Service better than Zendesk for a company already on Microsoft 365?

For a company already fully on Microsoft 365, Dynamics 365 Customer Service has a real structural advantage: it runs on the same Microsoft Entra ID, Teams, SharePoint, and Power Automate you already own. That means single sign-on and one governance model, agent collaboration in the tool the company already uses, and automation and reporting that reuse the Microsoft stack instead of a second platform. Zendesk is an excellent standalone help desk, but for a Microsoft 365 shop the integration benefits usually tip the decision toward Dynamics 365 Customer Service.

Freshdesk or Dynamics 365 Customer Service for a team of 15 agents?

For 15 agents the honest split is this. Choose Freshdesk if support is a standalone function, you need a working desk in days rather than weeks, and nobody needs cases tied to accounts, pipeline, or the rest of your Microsoft 365 data. Choose Dynamics 365 Customer Service if you already pay for Microsoft 365 and want support on the same Entra ID, Teams, and SharePoint you already govern, or if cases have to connect to the wider business. On price the two are closer than they look at this size: 15 agents on a mid tier Freshdesk plan is in the region of 9,000 USD a year at list, and 15 Customer Service Professional seats land in a similar place, while a realistic mix of full, attach, and Team Members licenses under the base plus attach model can come in around 12,350 USD a year even with nine Enterprise seats. The Freshdesk line is entirely new spend on top of Microsoft 365; the Dynamics line reuses identity, collaboration, and automation you have already bought. Verify all list prices against your own agreements before you budget.

We need a help desk this week and cannot decide yet. What can we run on Microsoft 365 E3 in the meantime?

You can stand up a temporary ticketing system inside your existing tenant with no new licenses. Use a SharePoint list as the ticket table, a Power Automate flow on the shared mailbox trigger to turn inbound email into list items and send an acknowledgement, list views surfaced as a tab in the support Teams channel for agents, a scheduled flow that posts unanswered and ageing tickets to that channel, and optionally a small Power Apps canvas app over the same list for triage. Microsoft 365 E3 includes SharePoint, Teams, and the standard connector tier of Power Apps and Power Automate, so a build that stays on standard connectors and SharePoint Lists, with no Dataverse and no premium connectors, sits inside licensing you already pay for. Confirm the current use rights in the Microsoft Product Terms for your own agreement. Know the ceiling: no entitlements, no real SLA engine, no customer portal, and SharePoint list performance degrades past the 5,000 item view threshold without indexed columns. Treat it as a bridge of weeks or months with a decision date written down, not as an architecture.

Does Microsoft 365 E3 include Dynamics 365 Customer Service?

No. Microsoft 365 E3 and Dynamics 365 Customer Service are separately licensed, so an E3 seat count is not a Dynamics 365 seat count. What E3 does give you is the platform underneath: Microsoft Entra ID for identity, Teams, SharePoint, and the standard connector tier of Power Apps and Power Automate. That is why adding Dynamics 365 Customer Service to a Microsoft 365 shop is an incremental purchase rather than a new stack, and why a temporary ticketing system built on SharePoint and standard connectors can carry a team of 15 for a while at no additional license cost.

Can we run support on Microsoft 365 tools like Planner, Lists, SharePoint, and Teams instead of Dynamics 365 Customer Service?

Yes, up to a point, and plenty of teams should. A SharePoint list as the ticket table, a Power Automate flow turning shared mailbox email into items, documents in SharePoint, and a Teams channel for the conversation will carry a small desk for a long time. What those tools do not have is a customer record, entitlements or contracts, an SLA clock that pauses while you wait on the customer, routing by capacity or skill, knowledge articles tied to the request that used them, and a customer facing portal. Dynamics 365 Customer Service is a case management application on Dataverse, so all of that is product behaviour rather than something you build in flows. The practical rule is that Microsoft 365 tools are the right answer while support is low volume, single channel, internal, and unpromised in any contract, and the wrong answer once any of those four stop being true.

What is the difference between Power Automate and Dynamics 365 Customer Service automation?

Power Automate is the automation engine in both options, so this is not a choice between two engines. The difference is what you are forced to build. On Microsoft 365 tools, your flows carry the state of the ticket: one acknowledges, one assigns, one escalates, one closes. They run asynchronously, they fail independently, and the state of a ticket is whatever the last successful run wrote, so a flow that dies halfway leaves a ticket assigned but never acknowledged with nothing treating that as an error. In Dynamics 365 Customer Service the case state, routing rules, and SLA actions are product behaviour, business rules run on the form, and logic that must not half apply runs server side in Dataverse on save, leaving Power Automate for what it is best at: Teams notifications, document generation, and calls to other systems. A quick test: count how many of your flows exist only to make a ticket behave like a ticket. If it is more than about a third, you have already built a case management product and are maintaining it in someone’s time.

How do we send Dynamics 365 Customer Service case notifications to a Microsoft Teams channel with Power Automate?

Build it in a Dataverse solution, not in My flows. Trigger on When a row is added, modified or deleted with change type Added or Modified, table Cases, and scope Organization, and set Select columns to only the fields the message needs so the flow does not fire every time other logic touches the record. Add a trigger condition excluding the service account the flow runs as, otherwise your own write back retriggers it. Resolve the audience with Get a row by ID on the owner and Office 365 Users Get user profile (V2) on their primary email so an @mention actually notifies somebody. Compose an adaptive card with a fact set rather than a paragraph: case number, customer, priority, created time, SLA due, first line of the description. Build the record deep link from environment variables holding the environment URL and the model driven app id, plus pagetype entityrecord, etn incident, and the case GUID. Post it with Post adaptive card in a chat or channel, taking the team and channel from environment variables rather than the design time dropdown, and convert timestamps out of UTC before they reach the card. Finally, wrap the calls in scopes with configure run after so a failure posts to an admin channel instead of disappearing.

Why does our Dataverse triggered flow post the same case to Teams two or three times?

Because the Dataverse trigger fires on modification, and a new case is modified several times in its first seconds. Routing rules, SLA actions, business rules, and any server side logic all write to the record, and if your flow updates the case as well then its own write counts as another modification event. Three fixes together solve it. Set Select columns on the trigger so it only reacts to changes on the fields you actually read. Add a trigger condition that compares the modified by lookup against the GUID of the service account the flow runs as, so the flow ignores its own writes. Where the message must fire exactly once for a case, add a small flag column, check it in the trigger condition, and set it in the same run. The reason this is worth getting right rather than living with is that duplicated cards are how a support team learns to stop reading them.

Can agents act on a Dynamics 365 case from a Microsoft Teams adaptive card?

Yes. Replace Post adaptive card in a chat or channel with Post adaptive card and wait for a response, and give the card an Action.Submit with a small choice set such as acknowledge, assign to me, or needs escalation. The action returns both the card inputs and the identity of the person who responded, so you can run Update a row against the case setting only the columns that action owns, and record who claimed it. Two limits shape the design. The action captures only the first response and then completes, while the card stays visible, so update the card to read as claimed and name the claimer, or the second person to press it gets nothing. And it holds the run open until a response arrives or the timeout expires, so set that timeout deliberately. Where the button is a real authorisation rather than a status change, use the Approvals action instead, because it records the decision, the comment, and the timestamp somewhere that outlives the flow run history.

Do we need a premium Power Automate licence to integrate Dynamics 365 Customer Service with Teams?

The connector matters more than the scenario. The Microsoft Teams and Office 365 Users connectors are standard, so a flow that only touches those sits inside the standard connector tier included with a plan such as Microsoft 365 E3. The Microsoft Dataverse connector is premium, and every case notification flow starts with a Dataverse trigger, so it is not covered by that standard tier on its own. Dynamics 365 licences carry Power Automate use rights within the context of the licensed application, and a Power Automate premium licence covers flows outside that context, so which of the two applies depends on what the flow does and who runs it. Confirm it against the current Microsoft licensing documentation and your own agreement before you design, rather than discovering it at go live. Note also that the embedded Teams chat on the case form and the Dynamics 365 app inside Teams need no flow at all, which is another reason to turn those on before building anything.

Power BI over a SharePoint list or Dynamics 365 Customer Service dashboards: what is the real reporting difference?

Both end in Power BI, so it is not about which tool draws better charts. It is about what the numbers are made of. Over a SharePoint list every metric comes from a column something remembered to stamp. Backlog age is reliable because it derives from the created date. First response time only exists if every path wrote it, including the reply an agent sent straight from Outlook, which is exactly where the number becomes quietly wrong. Reopen rate needs a status history most list based desks never keep. In Dynamics 365 Customer Service, case creation, first response through the SLA KPI, resolution, reactivation, and ownership changes are part of the model, so the built-in Customer Service dashboards and historical analytics answer the standard questions immediately and Power BI on the same Dataverse tables covers anything specific to you. The deciding criterion is whether a number you would put in front of a customer can be defended. If it depends on a flow having run, it cannot.

When should we upgrade from Microsoft 365 tools to Dynamics 365 Customer Service?

Count the signals rather than arguing about features. The ten we see most often are: the ticket list has passed roughly 5,000 items or already needs indexed columns and archive views; the team has grown past roughly eight to ten agents; more than one intake channel is real; assignment takes a person every morning; you need the SLA clock to pause while waiting on the customer; someone has asked what you promised a specific customer and the answer sits in a contract document; a reporting question takes more than an hour to answer; customers email asking for status because there is no portal; agents need account, order, entitlement, or previous case context the list cannot hold; and flow maintenance has exactly one name attached to it. Zero to two of those means stay where you are. Three to five means plan the move over the next two quarters. Six or more means you have been running a support platform by hand and another year of it costs more than the move. Moving up keeps Teams, SharePoint, your flows, and your Entra ID identity in place, and the tickets migrate in as an ordinary data load.

Does Zendesk integrate with Microsoft 365, Teams, and Entra ID?

Yes. Zendesk supports single sign-on with Microsoft Entra ID (formerly Azure AD) and offers apps and connectors for Teams, and it can reach Microsoft 365 through Power Automate or custom middleware. The difference is that these are integration surfaces you configure and maintain, whereas Dynamics 365 Customer Service uses the same identity, collaboration, and content services natively. Both can be made to work; the question is how much integration and administration overhead you want to carry.

How does the total cost of ownership compare between Dynamics 365 Customer Service and Zendesk?

Look past the per-agent sticker price to the whole picture. With Dynamics 365 Customer Service on an existing Microsoft 365 tenant, you avoid a second vendor contract, a separate identity to administer, extra integration connectors, and a separate reporting and document stack. Those are the costs that accumulate over years. Zendesk can still be cheaper for a small, standalone support team, but for a Microsoft 365 shop that would otherwise bridge Zendesk back into Teams, SharePoint, and Power Automate, the long-term total cost of ownership often favors Dynamics because the platform work is already paid for.

Can Dynamics 365 Customer Service use the same single sign-on and security as the rest of Microsoft 365?

Yes. Dynamics 365 Customer Service authenticates against Microsoft Entra ID, the same identity provider as Microsoft 365, so single sign-on, conditional access, multi-factor authentication, and group-based licensing apply without a separate directory. Joiners and leavers are handled by the process that already governs your tenant, which removes a whole class of provisioning and access-review work that a separate platform requires.

Dynamics 365 or HubSpot for a business in Armenia?

It depends on what creates your pipeline, and we are not a neutral party, so judge the reasoning rather than the conclusion. Choose HubSpot when growth is marketing led, the sales process behind it is short and self contained, and you need something working in weeks without a configuration project. Choose Dynamics 365 when your company already runs Microsoft 365 for mail, documents, and Teams, when selling is complex with several stakeholders, negotiated pricing, quotes, and approvals, or when a second currency, a second legal entity, or a second country is on the plan for the next two years. And consider a custom-built CRM when the process is specific to your business but per seat licensing billed in USD is hard to carry on a dram budget: Solzet also builds CRM on React, Node.js, PostgreSQL, and .NET that you own outright, with no subscription per user. Three Armenia specific factors usually settle it in practice. Both vendors price in USD, so the dram cost of an annual commitment moves across the term and only Dynamics 365 can be bought through a Microsoft reseller in the region that may invoice locally. Local delivery differs: Dynamics 365 Customer Engagement work is available from a consultancy registered and staffed in Yerevan, while the HubSpot Solutions Partner directory at the time of writing points an Armenian buyer to Türkiye, Poland, or the Gulf. And the interface language matters, because Dynamics 365 ships a Russian interface and HubSpot does not at the time of writing. Verify all three yourself before shortlisting.

How does HubSpot pricing compare with Dynamics 365 for an Armenian company, and what about the dram?

On list prices at the time of writing, HubSpot Sales Hub Professional is in the region of 100 USD per seat per month and HubSpot Marketing Hub Professional starts from roughly 800 USD per month for a bundle with a marketing contact allowance, while Dynamics 365 Sales Professional is about 65 USD per user per month and Sales Enterprise about 105 USD, with Team Members at about 8 USD and attach licences at about 20 USD for users who already hold a full base licence in another Dynamics 365 app. Verify every one of those against your own quote. Three things matter more than the comparison itself for a company in Armenia. First, both vendors bill in USD, so a twelve month commitment carries AMD to USD movement across the term and the number approved in January is not the number paid in December. Second, the two products scale on different axes: Dynamics 365 scales with people who need a seat, HubSpot Marketing scales with contacts in the database, so model both curves over three years against your own growth. Third, Dynamics 365 can be bought through a Microsoft Cloud Solution Provider, and a reseller in the region can put it on a local invoice, so ask directly whether they bill in AMD and how VAT at 20 percent is presented. Finally, add implementation, which no price page shows: a senior certified engineer from a Yerevan consultancy sits in a very different rate band from a Western European one, and since HubSpot delivery here is normally sourced from outside the region, the cheaper licence is not automatically the cheaper project.

Is there local partner support for HubSpot and Dynamics 365 in Armenia?

For Dynamics 365 Customer Engagement and the Power Platform, yes. Microsoft has a partner ecosystem in the region and the work can be bought from a company registered and staffed in Yerevan, with Armenian, Russian, and English on the delivery team, GMT+4 working hours, and Microsoft certifications you can verify by name such as PL-200, PL-400, PL-600, MB-210, and MB-230. Solzet is one such consultancy. For HubSpot, the Solutions Partner directory at the time of writing does not point an Armenian buyer to a partner inside Armenia, so implementation, customization, and rescue are normally sourced remotely from Türkiye, Poland, the Gulf, or further west, at those rate bands and with less daily overlap. Check the current directory for your own location rather than relying on this page, because partner coverage changes. The practical consequence is not the licence price but who is available during a go live week and who can sit in a room with your sales director when the process needs rethinking.

Does HubSpot integrate with Microsoft 365 as deeply as Dynamics 365 does?

HubSpot does integrate with Microsoft 365. It supports single sign on with Microsoft Entra ID on its higher tiers, it has an Outlook add-in and a Teams application, and it is reachable from Power Automate. The difference is architectural rather than a matter of whether a connection exists. Dynamics 365 authenticates against the same Entra ID you already govern, so conditional access, multi factor policies, and your leaver process cover the CRM with nothing extra to remember. The record can be worked inside Teams rather than notified into it. Documents can sit in SharePoint under the retention and permissions model you already run instead of in a separate file manager. Power Automate drives the automation with connectors your tenant already owns, and Power BI reads Dataverse directly so CRM numbers sit next to the rest of your data with no export layer. With HubSpot each of those is an integration surface you configure, own, and maintain. Both can be made to work. The question is how much integration and administration overhead you want to carry, and for a company already fully on Microsoft 365 that overhead is the whole argument.

What do the HubSpot premium connectors actually cost a company already on Microsoft 365?

More than the phrase "it integrates with Microsoft" suggests, and the lines are checkable. Single sign on against Microsoft Entra ID sits in the higher HubSpot tiers at the time of writing, so identity integration is a tier upgrade multiplied by every seat. Two way data sync and programmable automation live in Operations Hub, priced from roughly 800 USD per month at list on the Professional tier. The HubSpot connector inside Power Automate is a premium connector, so each user running a flow that touches it needs Power Automate Premium at about 15 USD per user per month, or a per flow plan at about 100 USD per flow per month. Custom objects arrive on the top tier. None of that makes HubSpot expensive in the abstract; it makes the integration a purchase rather than a property. On the Microsoft side, Dynamics 365 Customer Engagement authenticates against the Entra ID you already govern, stores records in Dataverse that Power BI reads directly, and automates through standard connectors covered by licences you already hold. Verify every figure against your own quote before you build a budget on it, then compare the totals rather than the seat prices.

When does a business process outgrow HubSpot workflows?

At five recognisable points, and most companies never reach any of them. First, approvals with more than one stage: a chain that goes to a regional manager, then to finance only above a discount threshold, then to legal only on non standard terms, with delegation during leave and a deal that cannot advance until each stage returns. Second, service level rules that count working hours only, pause while you are waiting on the customer, restart on their reply, warn before breach, and run to a different target for customers who negotiated one. Third, rules that must not be routed around, meaning logic that applies whether the record came from a form, an import, an integration, or the API rather than a required field a seller can edit around. Fourth, failure handling, meaning retry policies, an explicit failure path, and an alert to the team that owns the process rather than an error list somebody checks. Fifth, change control, meaning somewhere to author and test a process change that is not the live production portal. Dynamics 365 Customer Engagement answers those with Power Automate approvals writing back to Dataverse, entitlements and SLA KPI instances with pause conditions, server side logic in the Dataverse event pipeline, run history with configurable retry, and managed solutions promoted through development, test, and production. If none of the five describe your process, HubSpot workflows are enough and the ceiling is theoretical.

Is committing to the Power Platform just a different kind of lock in than HubSpot?

It is a commitment, yes, and it is worth stating both bills rather than one. Choosing the Power Platform commits you to Dataverse capacity, to premium licence tiers the moment a flow leaves the standard connectors, to an environment strategy somebody has to own, and to testing two Microsoft release waves a year. What you get in exchange is that automation, identity, documents, and reporting are the same platform as the CRM instead of four agreements, and that the people who build it are automating the rest of your tenant with the same skills. HubSpot is API first, its webhooks work, and coded actions exist on the higher tiers, but that automation is a separate layer: the code runs at HubSpot or in hosting you provide, with credentials to rotate, logs to watch, and an owner. On exit, a Dynamics 365 build is managed solutions and data in a tenant you already own with source code yours by contract, and HubSpot exports its data too. The right move is to ask both vendors the same exit question in the same words and treat a vague answer as the answer.

Can Solzet implement Dynamics 365 Customer Service for us?

Yes. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy. We implement Dynamics 365 Customer Service on your tenant, including queues, routing, SLAs, and knowledge, wire it into Entra ID, Teams, SharePoint, and Power Automate, build custom PCF controls where the standard UI falls short, and take over stalled rollouts as project rescue. We work directly or on a white-label basis for Microsoft partners across Europe and the US from our hub in Yerevan, Armenia. Where Microsoft licensing is the obstacle rather than the answer, we also build custom CRM and service desk systems on React, Node.js, PostgreSQL, and .NET.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

Already on Microsoft 365 and unsure whether Dynamics 365 Customer Service fits?

Tell us how your support team works today and what it already runs on inside Microsoft 365, and we will tell you honestly whether Dynamics 365 Customer Service is worth the move or whether your current desk is fine. You get a clear recommendation, not a sales pitch.