Two systems, one source of truth: deciding where data lives when you integrate Business Central and Project Operations

A water treatment company we're working with ran into a question last week that comes up on almost every integration project: when you've got two connected systems, which one is allowed to change the data? They're standing up Business Central alongside Dynamics 365 Project Operations, and the whole conversation kept circling back to that one point.

It sounds like a technical detail. It's really a business decision, and getting it right early saves you from a mess of mismatched records later.

The problem: the same record living in two places

Here's the setup. Their field and project teams work in Project Operations, where they build projects, generate purchase orders, and price the work. The finance side (a very small group of owners and one bookkeeper) works in Business Central for receiving, invoicing, and the general ledger.

The trap is assuming both systems should always match. If a purchase order exists in both, and someone can edit it in either place, you now have two versions of the truth and no clean way to know which is correct. That's how you end up with data that quietly drifts apart.

How they sorted it out

The team walked through the actual workflow and made a few calls that kept things simple. A useful pattern for anyone doing this:

1. Decide who creates the record. Here, purchase orders get keyed in Project Operations, so that becomes the origin point.
2. Decide where downstream work happens. Once a PO syncs to Business Central, receiving, invoicing, and any line adjustments happen there, and only there.
3. Make the sync one direction. Because nothing needs to flow back to Project Operations, they agreed the sync should be one-way. Fewer moving parts, less to reconcile.
4. Pick a single source of truth per data type. Vendor pricing lives in Project Operations since that's where POs originate, so there's no reason to duplicate and maintain it in Business Central too.

The real-world wrinkle: quantities never match exactly

This is where it got specific, and where the design earns its keep. When they order a full truckload of chemical (say 45,000 pounds), the vendor rarely delivers exactly that. The invoice might come in at 44,800 pounds. If the purchase order still says 45,000, the system treats the difference as a backorder, which they don't want.

So on chemical orders, someone adjusts the received quantity almost daily to match what showed up. Sometimes a freight or surcharge line gets added at invoice time too, because some vendors don't send those charges until the order ships.

The clean answer: all of those adjustments happen in Business Central, and they do not sync back to Project Operations. Finance handles the reality of what was delivered and billed, and the project side isn't dragged into every small correction.

You just have one focal point that carries over, so you don't have to balance two areas that have to mirror each other.

A small usability note that matters more than it sounds

One owner mentioned juggling two separate logins and a pile of browser tabs all day. The ask was simple: a way to jump from Business Central over to Project Operations without hunting for it. Options here range from an embedded link inside the app to a browser bookmark, plus color-coding environments (for example, a bright banner) so you always know which system you're in. Little things, but they add up when three people are doing the work of a larger team.

The takeaway

Before you connect two systems, map out each type of record (customers, vendors, prices, POs, invoices) and answer two questions for each: who creates it, and who's allowed to change it after that. Once those answers are clear, the sync direction and the ownership rules mostly write themselves.

If you're weighing a Business Central and Project Operations setup and trying to figure out where each piece of data should live, we're happy to talk it through and sketch out what makes sense for how you work.