Dynamics 365 Dual-write - Simply Explained

A salesperson updates a customer address in Dynamics 365 Sales. Later, someone in finance opens the same customer and still sees the old address. Which one is correct? When sales, service, finance, and operations work in different applications, shared business data can quickly become duplicated or inconsistent. In this episode of M365 FM, Mirko Peters explains how Dynamics 365 Dual-write connects Finance and Operations apps with Microsoft Dataverse so supported records such as customers, addresses, contacts, products, and orders can remain synchronized as teams work.

WHAT IS DYNAMICS 365 DUAL-WRITE?
Dual-write is Microsoft's built-in connection between Dynamics 365 Finance and Operations apps and Microsoft Dataverse. Think of an organization as having a front office and a back office. The front office includes salespeople, service agents, field workers, and other customer-facing teams. The back office handles finance, inventory, purchasing, orders, fulfillment, and other operational processes. Both sides work with many of the same customers and products, but they need different applications for their jobs. Dual-write creates a controlled connection between those environments so selected shared records can remain synchronized without employees manually copying information between applications.

THE BUSINESS PROBLEM DUAL-WRITE SOLVES
Without integration, one customer can quietly become two different records. Sales might have Northwind Bikes with the customer's new address. Finance might have Northwind Bicycle Company with the previous address. Both records can look correct when viewed independently, but they no longer describe exactly the same business relationship. Employees then become the integration layer. They export spreadsheets, send emails, compare records, re-enter information, and investigate which version is correct. Dual-write is designed to reduce that manual handoff.

FRONT OFFICE AND BACK OFFICE
Dynamics 365 applications support different types of work. Dynamics 365 Sales focuses on leads, opportunities, customer relationships, and sales conversations. Customer Service manages customer questions and cases. Field Service supports technicians and work performed at customer locations. Finance and Supply Chain Management handle areas such as accounting, inventory, products, purchasing, orders, and fulfillment. The objective isn't to force every employee into one giant application. Instead, employees continue using the application appropriate for their role while selected business information remains connected behind the scenes.

MICROSOFT DATAVERSE
Dataverse is the shared data foundation behind many Microsoft business applications. Dynamics 365 Sales, Customer Service, Field Service, parts of Project Operations, Power Apps, and Power Automate can work with Dataverse. For understanding Dual-write, think of Dataverse as the common data area on the customer-application side. Finance and Operations remains the operational foundation on the other side. Dual-write connects selected records between these environments.

THINK OF DUAL-WRITE AS AN INTERNAL DOOR
Imagine an office building with customer-facing teams on one side and finance and operations on the other. Without integration, somebody has to carry information between them. They might send an email, move a spreadsheet, or manually enter the information again. Dual-write acts like a staffed internal door. When a supported record changes on one side, Dual-write can pass the related change through that door according to predefined rules. Each team keeps its own workspace while shared information remains connected.

WHAT ARE TABLE MAPS?
Dual-write doesn't blindly synchronize every piece of information. It works through defined connections called table maps. A table stores a particular type of record. A customer table contains customer records. A product table contains products. An a

A salesperson updates a customer address.

Later, finance opens the same record

and still sees the old one.

So which address is correct?

For years fixing that means someone exporting data,

editing a spreadsheet, emailing it

and typing the same update twice into a second app.

Dynamics 365 dual-ride changes that.

It connects finance and operations apps

with database-based customer apps

so shared records like customers and orders

stay in sync automatically.

The autumn M, Mirko Peters from N365FM,

and this knowledge nugget explains dual-ride in plain English.

We'll cover what moves, how it moves,

where dual-ride fits and where it does no tempt.

First, let out and start with the business problem

that created the need for it.

The problem dual-ride solves.

Imagine a business where two groups work on the same customer

but use completely different apps day to day.

Finance and operations apps handle the back office work.

That's money, stock products, orders, purchasing,

and the supply chain.

This is where a company tracks what it sells,

what it can deliver, what it owes,

and what a customer needs to pay.

Customer apps focus on work closer to the customer.

Sales teams follow leads and build opportunities.

Customer service handles questions in cases.

Field service plans, jobs, and sends people to sites.

Project teams track work promised to a customer.

Different work needs different screens.

A salesperson shouldn't have to dig through a finance screen

just to update a contact after a call.

But a finance user needs customer and order details

that match what sales sees, oh,

because invoices and deliveries depend on that information.

Without a connection, one customer quietly becomes two records.

Sales might list our Northwind Bikes,

A.O. Finance might list our Northwind Bicycle Company.

O. One record has the new street address.

The other still sends invoices to the old office.

Both records look reasonable on their own,

but they no longer describe the same business relationship.

Small problems pop up first.

Someone can't find a customer

because the name is different in another app.

A sales rep promises a price or checks stock,

but the information doesn't match the operational side.

Finance needs to process an order

but the customer details require a check,

an email, and another manual update.

Then those small problems pile up.

Someone exports customer data into a spreadsheet.

Another person fixes a few rows and imports it somewhere else.

Somebody else enters a new customer in both apps

because nobody knows which record will appear first.

Soon there are duplicates, different addresses,

and more time spent checking data than using it.

None of this happens because people are careless.

It happens because the systems ask people to become the connection.

People copy data.

People remember which app comes first.

People spot mistakes after they've already reached another team.

That approach worked when business systems stayed separate

and teams accepted delays.

But when sales, service, finance, and operations

all need the same customer information during the day,

a spreadsheet becomes a poor handoff tool.

Think about a simple order conversation.

A customer calls sales and asks,

"How can you deliver next week and what will it cost?"

AO, the sales team needs product, price, and stock details to answer.

Once the customer agrees,

finance and operations need the right customer

and order information to process the sale.

Both sides need the same facts.

Sales needs those facts in the app where sales people work.

Finance and operations need them

in the app where they manage orders, money, and delivery.

The goal is now to empty to force every team into one giant screen.

The goal is for shared records to follow a clear agreed route.

That outermost where dual-right enters the picture.

What dual-right actually is so?

What exactly is dual-right?

Here's the simplest definition.

Dual-right is Microsoft's built-in connection

that keeps selected data in sync between Dynamics 365

Finance and Operations Apps and Dataverse.

Dataverse is the shared data foundation

behind many Microsoft Business Apps.

Dynamics 365 Sales, Customer Service, Field Service,

and parts of project operations all use it.

Power Apps and Power Automate can use it too.

You don't need to know how Dataverse stores every single record

to understand dual-right.

Just think of it as the common data area

on the customer app side of Dynamics 365.

Imagine an office building with a front office and a back office.

The front office handles conversations with customers.

Sales people, service agents, field workers.

They all need screens that help them talk to people,

track requests, and manage work.

The back office handles the work that keeps the company

running our financial records, stock, orders, purchasing, delivery.

Both offices work for the same company,

but without a proper connection between them,

someone has to walk information from one side to the other.

They carry a printed form, send an email,

or copy data into another system.

The work still gets done, but it takes longer

and details can change along the way.

Dual-right is like a staffed internal door

between those two offices.

When a supported record changes on one side,

dual-right passes the related change

through that door to the other side.

It doesn't combine every app into one giant app.

Sales can still work in sales.

Finance can still work in finance.

Each team keeps the screens built for its work,

while selected shared information stays connected

behind the scenes.

That word supported matters.

Dual-right doesn't blindly copy every piece of data in both systems.

It works through defined connections

between records that belong together.

Microsoft calls these connections table maps.

A table is simply a place where an app

keeps one type of record.

A customer table keeps customer records.

A product table keeps product records

and address table keeps address details.

A table map tells dual-right which table

on the finance and operations side

connects to which table in data verse.

Think of a table map as an agreed translation sheet.

One column identifies a record on one side.

Another column identifies its matching record on the other side.

The rest of the sheet explains which fields belong together.

Our name, phone number, address line.

That agreement gives the connection rules.

Without it, two apps might use different labels

or store the same detail in different places.

A map tells dual-right how those details relate.

So the apps don't need a person to interpret them every time.

Now, people often hear the name dual-right

and assume it means every change always moves both ways.

Sometimes it does.

For a supported two-way map,

a change in data verse can update

the related record in finance and operations.

A supported change in finance and operations

can also update the related record in data verse.

Both sides can take part in the same shared record.

That's the dual part.

The update happens in near real time.

It moves quickly as people work

instead of waiting for a scheduled job that runs overnight.

A user updates a supported record

and the connection sends that update across,

while the work is still current.

Near real time doesn't mean magic or zero delay.

It means the connection is built for live business work,

not a once a day file exchange.

If someone changes a detail,

the related team doesn't need to wait until tomorrow morning

to see it and that changes how teams can work.

The front office can use data that comes from the back office.

The back office can receive supported updates

from customer facing apps.

Data verse becomes the data foundation on one side.

Finance and operations remains the operational foundation

on the other and dual right keeps the approved shared records connected.

Still, a live internal door needs rules.

Before you let a record travel in both directions,

you need to know where that record should begin,

who can change it and which side should lead

when the two apps disagree.

What data can move and which system owns it?

So which records can dual right keep connected?

The common examples start with the records

many departments share every day.

Customer records addresses, contacts, products, vendors,

company details and reference information used for finance and tax.

Think about a customer record for a moment.

Sales needs the customer's name, main contact, phone number,

and delivery address.

Finance needs the legal customer record,

billing details and information needed for orders and invoices.

If each department keeps its own separate customer list,

the company spends time comparing records instead of serving the customer.

With the right dual right maps in place,

those teams can work from connected customer details.

That doesn't mean sales users suddenly need to learn the finance app.

It means they can work with customer information in Dynamics 365 sales,

while finance users work with the related customer information in finance.

The customer stays recognizable as the same customer across both places.

Addresses matter too.

A customer may have a billing address, a delivery address,

and perhaps a site where a service worker needs to visit.

These details can't just be treated as plain text copied into one box

because each address has a different job.

Dual right supports the shared record structure needed for that relationship.

Contacts follow the same pattern.

One customer company may have a buyer, an accounts payable contact,

and a service manager.

Sales needs to know who makes decisions.

Finance needs to know where billing questions go.

Service needs to know who is waiting at the site.

Connected records help each team see the people connected to the customer

without rebuilding that information in every app.

Products are another common example.

A sales rep needs to know what the company sells,

what the product costs, and where the stock is available.

Those answers usually come from the operational side of the business

because that's where products, stock, purchasing, and fulfillment are managed.

This is why product information often begins in finance and operations.

An operations team creates and prepares a product there.

Once that product is ready for customer facing work,

dual right can send the related product details into data verse.

Sales users can then select and discuss the product in their own app

without someone entering the product list a second time.

That helps sales conversations stay grounded in what the business can actually provide.

Pricing and inventory details can reach sales through the connected apps as well.

Instead of guessing whether an item exists, whether the price change, or whether stock can support a promise,

the sales team can work from information tied to the operational side.

That doesn't remove the need for good sales judgment.

It removes one avoidable reason for a sales rep to phone the warehouse

just to confirm basic details.

Vendor information can also connect where a business process needs it.

Company details, organizational structures, finance, reference data,

and tax reference data can matter across the customer side and the operation side.

The exact records depend on the apps and processes a company uses.

But the pattern stays the same.

Share the records that need to mean the same thing in both places.

Now don't assume every record should travel in both directions.

Some maps support two way updates.

A change can begin in data verse and move to finance and operations,

or begin in finance and operations and move to data verse.

That approach fits records where both sides have a proper business reason to update approved details.

Other maps run one way.

Products give us a useful example.

In many businesses, finance and operations owns product creation

because operations controls the product master, stock, units,

and other details needed to sell and deliver it.

The product then flows out to data verse where sales and service teams can use it.

That's a clear rule.

The product doesn't need two teams creating competing versions.

One side creates and governs the product.

The other side receives and uses it as part of its work.

Every shared record needs that kind of decision.

Where does this record begin?

Who can edit it?

If a name, address, price, or classification looks wrong, which team fixes it?

Those questions sound simple, but they prevent a lot of confusion later.

A connection can move a change very quickly.

If nobody agreed who owns that change, it can move a mistake just as quickly.

Choose an owner for the record and, when needed, for individual details within that record.

For example, sales might own a customer's relationship details and primary contact information.

Finance might own payment related details, operations might own product and stock details.

Your exact split depends on how your business works,

but it needs to be written down and understood by the people using the apps.

There are also two terms you may see after dual-ride expands dataverse, party, and company.

A party is Microsoft's way of handling a person or organization in a consistent way.

It helps connect people, organizations, contacts, and addresses

without treating every relationship as a separate, unrelated record.

A company helps dataverse understand the business company context

used by finance and operations.

You don't need to become an expert in either term one day one.

Just know they exist because finance and operations handles business structures

that customer apps need to recognize when records cross between the two sides.

Once records can travel in both directions,

the process around those records matters just as much as the data itself.

How a change travels between the apps.

Let's follow one change through the system and see what actually happens.

A sales rep is on a call with a customer who just moved to a new office.

During that conversation, the rep opens the customer record in Dynamics 365 sales

and updates the street address, simple enough, right?

Then they save the record.

That's where the interesting part begins.

Sales stores that change in Dataverse O.

That's the data side for customer facing apps.

Then dual-write checks the map that connects customer and address info

between this side and finance and operations.

It sends the matching change across automatically.

No export file sitting in a shared folder waiting for somebody to pick it up.

Nobody has to email finance with a note saying,

"Hey, please update this address to us."

The map already knows which fields are linked

and it sends the supported change straight to the related customer record

in finance and operations.

So a finance user can open that customer record later,

see the updated address and process an order or prepare an invoice without missing a beat.

That's the practical result, plain and simple.

Two people keep working in different apps,

but neither has to retype the same customer detail.

The sales rep works in a screen designed for customer conversations.

The finance user works in a screen built for financial work.

Each person sees the customer information they actually need,

right where they need it.

And the trip works in the other direction too.

Imagine finance updates,

supported customer info in finance and operations O.

Say a finance user corrects a detail that belongs on the operational customer record.

Dual-right uses the matching map in reverse

and sends that related update to dataverse.

Then sales, customer service, field service,

or any other dataverse-based app can pick it up.

This connection is synchronous for normal day-to-day work.

Synchronous means the apps try to complete the related update

as part of the same working moment

instead of dropping it into a background job that might run 20 minutes later.

If the connection can't complete the update,

that issue needs attention immediately,

not quietly hiding until someone notices a mismatch.

That behavior makes sense for shared business records.

You don't want to custom address product detail

or other shared information drifting apart for hours

because a batch job hasn't fired yet.

People make decisions based on what they see on their screen right now,

so the connection keeps both sides close together while work is happening.

Still, live work sometimes needs a controlled pause.

Dual-right includes play, pause, and catch-up options.

Play means the map is running and supported changes travel normally.

Pause temporarily stops the map when a team needs to do planned work,

investigate a problem, or manage a change safely.

But pause isn't a permanent parking space.

While the map is paused, changes can queue up for a limited time in space.

When the map resumes, catch-up processes, those waiting changes

that helps teams recover after a planned interruption out.

But somebody needs to own that pause

and know when the map should start running again.

Before any of this starts in daily work, there's another step.

Initial sync.

Initial sync brings existing records from both sides

to a shared starting point.

Think about a company that already has customers

in finance and operations and customer records in Dataverse.

The connection can't just switch on

and assume every existing record already matches perfectly.

It needs a starting line.

Initial sync helps bring approved existing data across

before people rely on live updates.

That work needs care.

Because duplicate records, incomplete addresses,

and old test data don't magically clean themselves up

just because the sync starts.

They can actually create problems faster

if the records don't follow the agreed rules.

Once the maps are running,

the people who manage dual-right need a clear place to check its health.

Dual-right provides combined activity and error logs

so administrators can see what the connection processed

and where it ran into trouble.

They can also set alerts and thresholds,

"U", which means the right people hear about problems

before users discover them through a missing or failed update.

That support view matters because every error has a cause.

Maybe a required field is missing.

Maybe a related record hasn't arrived yet.

Maybe someone changed data in a way that doesn't fit the map.

Retrying a failed record without fixing the cause

usually just creates the same failure again.

A well-run dual-right setup watches the connection,

fixes the reason behind errors,

and keeps the maps focused on records

that truly need to stay connected.

Tee, where dual-right fits best.

Dual-right fits best when your business uses Dynamics 365 Finance

or Supply Chain Management alongside customer-facing apps

like sales, customer service, field service, or project operations.

These apps support different parts of the same business conversation.

One team talks with the customer,

another team plans delivery, manages stock,

tracks costs, or sends the invoice.

When both groups need to work from related records during the day,

dual-right can connect that work without forcing everyone into the same app.

Take a prospect to cash process as an example.

A salesperson works with a potential customer in Dynamics 365 Sales.

They track the contact, discuss products,

build a quote, and move toward an order.

During that conversation, the salesperson needs customer details,

product info, pricing, and order information

that relates to the finance side of the company.

Once the sale becomes real,

finance and supply chain management takes over the work that happens after the promise.

It handles the order for film and stock,

billing, and financial records.

Dual-right helps those two parts stay connected.

Sales people can work in the customer app that fits their job,

while finance and operations manage the transaction in the app built for their work.

The customer doesn't become two separate stories,

are one told by sales, and another told by finance.

Field service gives you another good example.

Imagine a company that sends technicians to install,

repair, or maintain equipment at customer sites.

The field work needs customer details, details about the work,

and information about the customer asset to the item the company installed or supports.

Behind the scenes, the company also needs to track parts,

costs, purchasing, and the money tied to that work.

Field service focuses on planning and completing the visit.

Finance and operations focuses on the operational and financial record around it.

When those records connect properly,

a technician's work doesn't sit apart from the parts used,

the cost of the work, or the customer record connected to it.

Project operations fits the same pattern,

especially for companies that sell work by the project.

A project team might manage customer work,

people's time, plan costs, and project milestones.

Finance needs to see the financial side,

or purchasing, costs, billing, and reporting.

Without a connection, project managers can spend too much time chasing finance for updates,

while finance waits for project teams to confirm what happened.

Connected project records give both groups a clearer view of the work

as it moves from a customer promise into financial activity.

There's also a wider power platform benefit here,

because the customer app side uses dataverse,

approved data in dataverse can support power apps and power automate.

A company might build a small app for an internal team,

or create a flow that responds when a business record reaches a certain point.

That doesn't mean every finance and operations record suddenly belongs in every power app.

It means connected records can become part of a wider set of business tools,

as long as the company chooses that purpose carefully and protects the data properly.

One boundary needs to stay clear.

Dual-right does not support Dynamics 365 Business Central.

Business Central can connect with other Microsoft products through other methods,

but Dual-right is for the finance and operations side of Dynamics 365

and Dataverse-based customer apps.

It also isn't a tool for copying every table you can find.

A record should move, because people need the same operational record in both places,

not because copying data feels safer.

Dual-right also doesn't replace a wider integration plan

when a company needs reporting feeds, links to third-party systems,

or a large data migration.

Treating every data connection as the same job creates trouble quickly.

Limits, preparation, and common mistakes.

Think of Dual-right like a handshake agreement between two systems.

They agree to keep certain shared records and think,

but it's not a magic pipe for every table, report, or external system.

Before you set it up, check what integrations already exist.

If an old connection and Dual-right both update the same customer record,

you can create conflicts fast.

That's a headache you don't want.

So agree on the basics first.

How will you enter names?

Which legal company owns each record?

Who can make changes?

What security roles does each team need?

Clean up duplicates and incomplete records before the first sync.

Start with Microsoft's pre-built maps.

They already connect common records.

Custom tables and fields, those need careful testing,

and check related tables and map dependencies,

because sometimes one record needs another to exist before it can sync.

Plan your first sync based on how much data you have.

Don't treat it like a light switch you flip during lunch.

That'll cause problems.

A paused map still needs an owner and a restart plan.

Cude changes and failed records don't stick around forever.

Watch the activity logs, errors, alerts and thresholds.

When something fails, find the missing field, the bad record,

or the broken rule behind it.

Repeated retries won't fix bad data.

When you see Dual-right as a controlled bridge,

everything clicks into place.

Conclusion, one shared business conversation.

Dual-right keeps supported shared records,

moving between finance and operations

and your data-verspaced customer apps.

That way teams can work from connected business data.

Subscribe on your favorite podcast platform

for more knowledge nuggets with me,

Mirko Peters at M365.

FM, and share this episode with someone

who's still connecting sales,

service and finance through another spreadsheet.