Five decisions to write down so your team can change course without consultants

A CFO asks for a new service line by next quarter. The admin’s honest answer depends on choices made years earlier: which system owns the customer, how the field talks to finance, who can see what. If those choices live only in a consultant’s head, the answer is a call to the partner and a wait.

This guide is for the CIO or IT lead who will inherit the system, and for the COO and CFO who will ask it to change. For each decision, it says what to write down and why it matters when the business moves.

Microsoft’s Success by Design↗ framework, the method FastTrack↗ uses, reviews the same ground.

Its implementation reviews cover the data model, security, integration, application lifecycle management, and testing. The review checks each decision. Your team has to keep the record of it.

1. Every kind of record needs one owner, written down

Decide which application owns each kind of record, and keep it in one table. Customer, asset, item, price, work order, and invoice each get one owner, a list of the apps that read it, and the role allowed to change it.

Microsoft’s integration guidance makes the case. A one-way sync sets a clear record keeper and keeps conflicts simple. A two-way sync makes conflicts tricky to resolve and copies the data into every system.

Some of these choices come with the product, and your team should know which ones. When the Field Service integration with the finance and operations apps is on, Supply Chain Management becomes the system of record for inventory. Field Service then hides its own inventory screens.

For the CFO, this is the decision behind a clean close. Finance and the field agree on the numbers because both read the same record.

2. Decide how fast each connection must be, then how it fails

For every flow between systems, write down the trigger, the direction, how fresh the data must be, the pattern, and who gets the alert when it breaks.

Freshness is the decision teams skip. Microsoft’s guidance warns that real-time and near-real-time patterns are often confused.

A real-time stock lookup waits for an answer and stops when the other system is down. An update every few minutes lets work carry on through an outage. Microsoft notes that most of its recommended patterns are asynchronous.

Then write down the failure path. Microsoft’s Field Service to finance integration retries a failed transaction several times, then keeps the error for someone to fix and resend. Somebody on your team owns that queue. Name them.

Connections also have end dates. That integration won’t be available after February 28, 2027; Microsoft is moving the capability to the Field Service and Project Operations↗ integration. With a written integration map, your team can see in an afternoon which processes the change touches.

3. Access is easy to widen and hard to take back

Write down how your security model mirrors the business: the business units, the role for each job, and who approves a new role.

In Dataverse↗, the data platform under the Dynamics 365 customer engagement apps, privileges add up and the widest access wins. Microsoft’s own example: grant organization-wide read access to contacts, and you can’t hide a single contact afterward. A table’s ownership type is also set when the table is created and can’t be changed later.

So record the reasoning.

Note why dispatchers see every territory or only their own, and why technicians can’t see prices. List the columns that hold personal data and who can read them.

When you add a region or buy a company, your admin extends a pattern instead of guessing.

Agents belong in the same record. Success by Design asks teams to review the data each agent can reach and to grant the least access that works. We also give every agent a named owner on the client’s side.

4. Know where changes are built, tested, and released

Write down which environments exist, what each is for, who may change what where, and how a change reaches production.

Microsoft says to settle the environment strategy before the build starts, because changing it later can be hard and expensive. Its lifecycle guidance is specific. Build in a development environment with unmanaged solutions, keep them in source control, and deploy managed solutions to test and production.

A quick test: ask your admin to explain how a new field on the work order gets from an idea to production, and who signs off. If the answer is “the consultant does that”, the release path still belongs to the consultant.

Put the update calendar here too. Microsoft now ships changes to Dynamics 365 continuously, and someone on your side decides when they reach your people.

5. Every custom build needs a reason and an exit

For every extension, write down the requirement, why the standard feature didn’t fit, what the extension touches, and what to retest after each update.

Microsoft’s guidance is plain about the cost. It warns against rebuilding the old system inside the new one, because heavy departures from standard features add technical debt and maintenance cost.

It also warns that relying on another provider to maintain your extensions can keep you from adopting new features. Success by Design recommends recording each requirement and its resolution in a functional design document.

Add one more line: the exit. If Microsoft later ships the feature as standard, the extension should come out. A written reason makes that an easy call.

Small teams need a short record; regulated ones need more

One app, a few dozen users, and no custom code need a short record. The five decisions still apply; the answers are brief.

Regulated manufacturers need more. With Microsoft publishing changes continuously, they need a standing regression and validation cadence, budgeted as a running cost.

Equipment dealers often keep a dealer business system as the owner of some records, and those systems usually connect in batches. For dealers, decision 2 carries the most weight.

A decision log works when the admin who will use it helped write it. One that nobody has read is shelfware.

The record comes from doing the work together

We write each design decision down with its reason while the project runs, and client admins build alongside our consultants. A 2,000-person mechanical, electrical, and plumbing contractor in the US South finished its project with a blueprint that records every design decision. The phased roadmap is the contractor’s to run in-house, with us, or with another partner.

What leaders should do before the consultants leave

Make the five decisions a deliverable. Put them in the contract, each with its reason.

Have your admin write them with the architect. The person who will change the system should own the record.

Test the record with a real change. Before launch, ask your team to add a branch or a role using only the record. Every question they have to ask is a gap to close.

Update it when the business changes. A new region, an acquisition, or a Microsoft retirement notice should each trigger a review of the record.

How we know this

This guide comes from Ludia’s Dynamics 365 delivery. Microsoft sources, all on Microsoft Learn: Introduction to the Success by Design framework (Aug 2026); Choose the right pattern for your integration strategy; Field Service integration with finance and operations applications (Sept 2026), for the inventory system of record, retries, and the February 28, 2027 end date; Security concepts in Microsoft Dataverse (Sept 2026); Plan your environment strategy for Dynamics 365; Solution concepts with Power Platform; Extend Dynamics 365 apps without compromising performance; Stay current with Dynamics 365 service updates (July 2026). Continuous publishing and regulated manufacturers: ERP Today (Aug 26, 2026). The contractor example is a published Ludia client result; the client is not named.