CRM

Dataverse already knows the customer. Your website just has not been introduced

A lead fills in a contact form. It becomes an email, gets forwarded, and somebody eventually opens Dynamics and types it in as a Lead — assuming they have the right security role to create one, which is its own small adventure in a Microsoft ecosystem where permissions live in three different places.

Dataverse, underneath Dynamics, is a genuinely capable database with a real API. The gap is almost never technical. It is that nobody built the bridge between the form and the record, so a human is the integration.

  • Web API (OData v4), Azure AD app registration
  • Leads, Accounts, Opportunities, orders
  • From €1,700 plus service fees
The tool

What Dynamics 365 is, and how Dataverse fits under it

Dynamics 365 is Microsoft's business applications suite — Sales, Customer Service, Field Service, Business Central for finance, and more — all sitting on Dataverse, the shared data platform formerly known as the Common Data Service. Standard entities like accounts, contacts, leads and opportunities live there, alongside whatever custom tables an organisation has added through the Power Platform.

A connection talks to Dataverse through the Web API, an OData v4 REST interface, authenticated with an Azure AD app registration rather than a personal login. That app registration needs an administrator to grant it the right application permissions, and in larger organisations that administrator is often IT rather than whoever owns Dynamics day to day — worth flagging early, because getting that approval can take longer than building the connection itself.

Microsoft also offers Power Automate as a low-code alternative to a custom API integration. It is genuinely fine for simple, low-volume flows — a form submission creating a Lead, say — and gets fragile fast once you need real error handling, retries, or anything with meaningful volume. We are honest about which side of that line a given request falls on before recommending custom work.

What goes wrong

Three things that go wrong between a website and Dynamics 365

Two of these are specific to how Microsoft's permission model works, which is exactly why they surprise teams who assumed "it is all Microsoft" would make things simpler.

The Azure AD permission got revoked, and nobody told the website

A tenant-wide security review or an app registration renewal quietly revokes or expires a client secret, and a connection that relied on it fails without a visible error on the Dynamics side — because as far as Dynamics is concerned, nothing happened, an outside application simply stopped being allowed in.

What you see instead

A scheduled heartbeat call proves the connection is alive, and a failed authentication raises an alert naming exactly which credential stopped working, so IT can renew it before a week of leads is lost rather than after.

A custom field exists in Dynamics that the connection does not know about

Somebody in the organisation added a required custom field to the Lead entity through the Power Platform, months after a connection went live. New leads from the website start silently failing validation, because Dataverse now requires something the integration never sends.

What you see instead

Failed records are queued with the specific validation error attached, so the fix is a five-minute field mapping update rather than a mystery that takes a week to diagnose.

The account exists twice, once in Dynamics and once in Business Central

Organisations running both Dynamics 365 Sales and Business Central for finance often end up with the same customer as an Account in one and a Customer record in the other, created independently, updated independently, and reconciled by nobody.

What you see instead

One system is named the owner of the customer master record, and the connection keeps the other level with it — usually finance owns the record and sales reads from it, since that is where invoicing accuracy actually matters most.

The bill for doing it by hand

What manual entry into Dynamics costs you

At 150 web leads a month and three to four minutes each to check the right security role, find or create the Account, and fill in the Lead correctly, that is 8 to 10 hours a month of a job that exists purely because nothing automated the handoff.

The larger risk in a Microsoft environment specifically is the silent permission failure described above: because a broken Azure AD connection produces no error inside Dynamics itself, the realistic cost is not "hours spent typing" but "weeks of missing leads before someone in sales asks why the pipeline looks thin".

What we build

We build the thing on the other end too

With Dynamics the practical bottleneck is usually not the API but getting the Azure AD app registration approved by whoever owns your tenant, so we start that request in parallel with the technical build rather than after it.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between Dynamics 365 and your website

Built against the Dataverse Web API through an Azure AD app registration, so your tenant administrator controls and can revoke exactly what is granted.

  • Web forms as Leads

    Matched against existing Contacts and Accounts on email or company domain before a new Lead is created, respecting whichever custom fields your Dataverse configuration requires.

  • Accounts and Contacts

    Kept level between the website's own login system and Dataverse, with one system named as owner per field, especially where Business Central is also in the picture.

  • Opportunity or case status into a customer portal

    A logged-in customer or prospect reading their own quote or support ticket status straight from Dataverse, instead of a status page nobody updates.

  • Webshop or portal orders as Opportunities or Orders

    A completed transaction creating or advancing the matching Dataverse record, so sales reporting reflects what a customer actually did on the site.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For Dynamics specifically, budget extra time upfront for the Azure AD app registration and permissions approval — it is an organisational step more than a technical one, and it moves the timeline more than the connection's complexity does.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Microsoft Dynamics

Whichever fits the volume and reliability you actually need, and we say which upfront. Power Automate is a fine, cheap answer for a low-volume flow like a single form feeding Leads, and we would rather quote that than talk you into custom work you do not need.

Once you need real retry logic, an idempotency guarantee, or any meaningful volume, a custom connection against the Web API is the more reliable route, because Power Automate's error handling was not built for that.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan