こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

皆さん、いかがお過ごしでしょうか？

私は3月から今日まで怒涛のような日々を送ってきて、ちょっと疲労が溜まっていたのですが、やっと少し落ち着いてきました。

このDX365LIFEを日々追いかけてくださっている方々は、この期間の私の動きを把握していると思います。

いやぁ、結構痺れました（笑）

これは、全て「Agentic Engineering」のせいです。

去年くらいから、今までやってきたプロジェクトのタスクは、徐々にAIに食われるだろうとは思って取り組みをしてきましたが、

Microsoftが2026年に入って打ち出した「エージェント型の動作層（Agentic Operating Layer）」という壮大なパラダイムシフトに対し、

「現場のエンジニアやSIパートナーは、具体的にどう生き残るべきか？」

と悩み、実践的な『設計図』と『思想』を言語化する必要性を感じていました。

Dynamics 365は、何処に行くのか？

過去数年間は、このタイトルで、waveのアップデートを追いかけてきました。

【Dynamics 365は、Agentic Foundationという位置付け】

Vice Preseidentロールに昇進されたMike氏から、Directions ASIA初日のキーノートで説明があり、

「ついに、来たか」「そうか、来てしまったか」と。

Directions ASIAでも、これを見据えたビジネス向けセッションを担当しましたが、

導入・開発・保守といったDynamics 365の実装に日々向き合うチームが、変化の速いAI時代の中で迷わず前に進めるように。

そのためには、個々の機能紹介ではなく、「なぜそう設計すべきか」を腹落ちできるコンテンツが必要だと感じました。その想いから、一昨日・昨日と連載ブログとして一気に言語化したものです。

この内容をさらに深めていけば、単にエンジニアリングにとどまらず、マーケティングや営業にとっても「何をどう伝え、価値として届けるのか」が見えるようになり、全体の視界が自然と開けてくるはずです。

『Agentic Engineering × Dynamics 365』｜全8連載の総括

📌プロローグ：企業ソフトウェアが「考えて動く」時代へ

【パラダイムシフト】：「人間の指示を待つAI」から「自律して動くAI」へ 人間がプロンプトを入れて都度応答させる「チャット型（Copilot）」の時代が終わり、ゴールを与えればAI自らが手順を考えて実行する「エージェント型」へ主役が変わるという前提の転換。

📌 第1回：Agentic Engineeringとは何か—「作る対象」から「統率する存在」へ

【パラダイムシフト】：「コードを書く構築」から「複数AIのマネジメント」へ エンジニアの仕事が、手足となってシステムを「作る（Make）」ことから、自律的に働く複数のエージェントを適材適所に配置して「統率する（Orchestrate）」ことへシフトする開発概念の転換。

📌 第2回：どこに人間を置くか―Human-in-the-Loopの設計原則

【パラダイムシフト】：「AIに丸投げする自動化」から「人間を組み込む防衛設計」へ 何でも自動化すれば良いという思想を捨て、1円のミスも許されない基幹業務だからこそ、あえてプロセスのどこに人間を介在させてリスクをコントロールするかという安全思想の転換。

📌 第3回：エージェントはデータをどう使うか—CRMとERPのデータモデル

【パラダイムシフト】：「バッチ処理の過去データ」から「リアルタイムなデータモデル」へ エージェントが正しい経営判断を下すために、夜間バッチで集計された古いデータではなく、ERP/CRMの生きたリアルタイムデータ（DataverseやFabric等）を正として参照させるデータ基盤の転換。

📌 第4回：エージェントを組み立てる—Copilot Studioで何ができて何ができないか

【パラダイムシフト】：「ツールの理想論」から「現実の制約を見据えた実装」へ 「Copilot Studioで何でもできる」というベンダーの甘い言葉（理想）を排し、現時点で「何ができて、どこからが限界なのか」という技術の境界線を見極める実装アプローチの転換。

📌 第5回：エージェントを信頼できるか—ログ・監査・コンプライアンスの設計

【パラダイムシフト】：「人間の行動ログ」から「AIの思考・行動ログ」へ 誰がシステムを操作したかを記録する従来のセキュリティから、自律型AIが「なぜその業務判断を下したか」の思考プロセスまで追跡し、会計監査に耐えうるガバナンスを敷くという信頼性担保の転換。

📌 第6回：CRMとERPをまたぐエージェント—統合設計の全体像

【パラダイムシフト】：「分断された業務システム」から「エージェントによる一気通貫の融合」へ 「顧客（CRM）」と「モノ・カネ（ERP）」でシステムが分断されていた常識を覆し、AIエージェントがその間を自由に行き来してビジネスプロセスを最速化するアーキテクチャの転換。

📌 最終回：これからのDynamics 365エンジニアに何が求められるか

【パラダイムシフト】：「仕様通りの機能実装者」から「ビジネスプロセスの設計者」へ AIに仕事が奪われると恐れるエンジニアの受動的なマインドを破壊し、これからはAIを部下として使いこなし、企業の経営戦略をシステムに落とし込む「エージェント時代の指揮官」へ生まれ変わるというキャリアの転換。

🖌　エピローグ（あとがき）

『Agentic Engineering × Dynamics 365』｜エピローグ

最後にハンドルを握るあなたへ

プロローグから始まり、本エピローグを含む全9回の連載に、最後までお付き合いいただき、本当にありがとうございました。

2026年5月、ベトナム・ホーチミンの地で世界中のDynamicsトッププロたちと交わした議論、そして肌で感じた「AIエージェント時代」の地殻変動。あの時の興奮と、同時に襲ってきた「日本はこのままでいいのか」という強い危機感が、私にこの連載を一気に書き上げる原動力を与えてくれました。

途中でコラム的にお伝えした通り、Microsoft MVPやRegional Directorという重たいアワードを背負いながら、私は常に「自分はこれにふさわしいのだろうか」と自問自答を続けています。毎年アップデートされるWave Releaseを追いかけ、変化の激流に身を置き続けることは、決して楽なことではありません。

しかし、ベトナムの会場で私に「最高だった！この考え方をチームで使わせてもらうよ！」と、笑顔で握手を求めてくれた海外のエンジニア・コンサルタントたちの熱い眼差しや、日本からベトナムまで出向き、私のセッションに参加して、「自分もバリューを出していきます」と言ってくれる日本の仲間の声が、いつも私を突き動かしてくれます。現状に満足し、ふさわしいと思った瞬間に、きっと私たちの成長は止まってしまうから。この連載を全力で書き切ることも、私なりの「問い」への一つの誠実な答えでした。ほんと、Directions ASIAに来てくれた全員が最高でした。みんな、ありがとね！

今回の連載で提示した『Agentic Engineering（エージェント工学）』の本質は、AIに仕事を丸投げすることではありません。どのプロセスに人間を介在させるか（Human-in-the-Loop）を冷徹に設計し、会計監査ログを厳格に敷き、AIという優秀な部下たちを正しく「統率する」ことです。

時代がどれだけ進み、ソフトウェアが勝手に「考えて動く」ようになろうとも、私たちが愛する音楽がいつの時代も生身のアーティストの魂（パッション）によって私たちの心を揺さぶり続けるように、ビジネスの現場において最後にハンドルを握り、決断し、責任を引き受けるのは、どこまでいっても「人間」です。

テクノロジーに怯える時代は終わりました。これからは、私たちが指揮官として、AIエージェントと共に新しいビジネスの絵を描く時代です。

この全9回の設計図が、変化の激流に立ち向かうあなたのサバイバルガイド（生存戦略）となり、一歩を踏み出す勇気となれば、これ以上の喜びはありません。

最後に。ありがたいことに、最近は海外からこのDX365LIFEブログに足を運んでくれる仲間も目に見えて増えてきました。世界中のどこにいても、同じ「変化の時代」を生きるエンジニアであり、戦友です。そこで、彼らへの感謝を込めて、今回の一連の設計図を英語のメッセージとしてもこの場所（以下）に残しておきます。時代に合わせて、「英語翻訳」と「HTML化」は、AIの力をお借りします。

時代が変わるその最前線で、また世界中の皆さんと熱く議論できる日を楽しみにしています。

最後にハンドルを握る、親愛なるすべてのDynamicsコンサルタント、開発者、そしてDynamicsビジネスを牽引するリーダーへ、愛を込めて。

以上、室長でした。

Originally published in Japanese on DX 365 Life · May 2026  |  Author: Ryohei Yoshijima · Microsoft MVP for Business Applications · Microsoft Regional Director

Prologue — When Enterprise Software Thinks and Acts

May 2026  ·  Prologue  ·  Dynamics 365  ·  Agentic AI  ·  Copilot Studio

→ Read the original Japanese post

Most enterprise software records what happened — accurately. But what to do next has always been left to us, humans. Sales reps review reports, service staff scan history to make calls, inventory managers cross-check multiple systems to find the best decision. The information is there. Yet the work doesn’t automate itself. That gap — the judgment left to humans — is exactly what is changing right now.

Microsoft’s 2026 Wave 1 effectively elevated Copilot from a UI-layer assistant into an Agentic Operating Layer embedded in both ERP and CRM. This is not a feature update to Dynamics 365. It is a structural change in how enterprise systems execute work. This series unpacks that change from both the implementer’s and the decision-maker’s perspective.

Why Agents, Why Now?

AI has been “useful” for a few years. Copilot drafted emails, summarised meetings, and completed code. Convenient — but at its core it was still “sophisticated search and generation.” The human remained the subject of the work.

The inflection point came when AI became capable of acting autonomously toward a goal. An agentic AI is not a system that responds to a single prompt. It plans, executes, observes, and corrects across multiple steps — autonomously. You don’t tell it what to do; you tell it what to achieve, and it figures out the steps.

Three Things Dynamics 365 2026 Wave 1 Changed

Wave 1 (April 2026) fundamentally redefined Copilot’s role — from a UI-layer assistant to an operational layer that executes business work. Three technical shifts converged:

1. Agents can directly read and write Dynamics 365 data and actions. Standard integration now allows Copilot Studio agents to read and write Dynamics 365 entities (leads, opportunities, orders, inventory, customers), call Power Automate flows, and invoke custom APIs. Agents are not outside the system — they are inside it.
2. Multi-agent coordination reached practical usability. Wave 1 made it possible to design coordinated architectures where specialised agents divide roles and collaborate — a CRM front-end agent can request an inventory lookup from an ERP back-end agent and receive the result to complete a quote, all within Copilot Studio.
3. Governance and audit tooling was built in. Agent decision logs, action histories, and approval flow records are now integrated with Dynamics 365’s audit infrastructure — balancing autonomy with accountability.

What Changes in CRM?

In Dynamics 365 CRM (Sales, Customer Service, Contact Center, Customer Insights), agents change the nature of customer interactions. Traditional CRM was a system of record — reps entered deal status, CS logged interaction history. Data accumulated, but humans decided next steps. Agentic CRM is a system of action.

Sales — autonomous deal management: Sales Copilot analyses CRM opportunity data together with Microsoft 365 activity (email, Teams, calendar) and executes next actions autonomously. These are not suggestions — if configured conditions are met, the agent sends the follow-up without asking.

Customer Service / Contact Center — uniform quality at scale: Agents handle first-response, freeing humans for complex cases. Combined with Customer Insights, agents can access behavioural data, purchase history, and segment information in real time, enabling personalised responses.

What Changes in ERP?

ERP agent deployment carries different challenges from CRM. Inventory, cost, and accounting demand financial and legal precision — mistakes surface directly in the financials. “How autonomous should we make this?” is the central design question.

Licence structure evolution — a quick primer: The former Dynamics 365 Finance & Operations (F&O) was split into Dynamics 365 Supply Chain Management (SCM) and Dynamics 365 Finance — both sharing the same F&O technical platform. Business Central is a separate product: an all-in-one ERP for mid-market companies on its own platform.

Supply Chain Management: Agents monitor inventory levels continuously and execute purchase orders autonomously when configured thresholds are crossed — something humans previously did by checking periodic reports.

Finance: The “agent drafts, human approves” model is the realistic design. Final journal approval, accounting policy changes, and auditor-facing reports remain with humans.

Business Central: Because all business functions share a single data model, agents can move across process boundaries without system fragmentation — the key structural advantage for mid-market deployments.

The Virtual Table Bridge

For agents to act autonomously across CRM and ERP, they need real-time access to data in both systems. Virtual Tables serve that role in Dynamics 365 — exposing ERP data as virtual tables on Dataverse without copying it. The data stays in its ERP source of truth; the CRM agent reads and writes it in real time through the virtual layer.

F&O (SCM/Finance) and Business Central have different integration architectures. F&O Virtual Tables have been available since around 2020. BC’s core runs on its own proprietary platform, but its Dataverse connectivity is continuously being strengthened. Integration Table Mapping has evolved from a simple data synchronisation mechanism into a foundation for sharing data across applications. The design principle — “BC’s core stays on its own platform, but Dataverse serves as the integration gateway” — is becoming the standard. This represents a shift toward an architecture that assumes CRM integration as a baseline.

In either case, the principle remains unchanged: cost is referenced from ERP as the source of truth, and returned to CRM. When a CRM agent generates a quote, it retrieves actual cost, inventory availability, and lead time from ERP at that moment. Not stale data synced by a batch process — real-time ERP ledger data is the basis for the judgment. This directly determines the quality of the agent’s decisions.

What Implementers and Decision-Makers Each Need

The shift to agentic systems poses different questions to those who build (implementers) and those who use (decision-makers).

What implementers need: Rather than writing code, design “which business processes to delegate to agents.” Define agents’ behavioural conditions, guardrails, and escalation flows in Copilot Studio — then monitor decision logs and continuously tune thresholds.

What decision-makers need: Ask “where should human judgment remain?” rather than “what can we automate?” The scope of agent autonomy is not a technology question — it is a management question. Draw the boundary of autonomy based on accountability, risk tolerance, and compliance requirements.

Series Structure

“What to automate?” matters less than “where to keep humans?” — and facing that question is where Agentic Engineering begins. In the inventory ordering example, decision-makers need to decide: should the agent automatically create purchase orders, or should it stop at generating the data for a human to decide? Implementers then configure the agent based on that policy. Next, we define the agent’s definition and autonomy levels. Throughout this series, I hope to think through Dynamics 365 implementation, configuration, and development together with you.

Chapter 1 — What Is Agentic Engineering?

May 2026  ·  Chapter 1  ·  Dynamics 365  ·  Agentic AI  ·  Copilot Studio

→ Read the original Japanese post

In traditional system development, humans designed the process, humans executed it, and the system recorded the result. “Humans think; humans act” was the premise. Agentic Engineering changes that premise. Humans design the whole and define the criteria for decisions. Agents carry out the execution and much of the judgment. From “building” to “governing” — that is the essence of this shift.

What Is an “Agent,” Really?

The word “agent” has existed in software for decades. But today’s agentic AI is fundamentally different from traditional automation.

Traditional automation (RPA, Power Automate flows) executes pre-defined steps mechanically. Branching logic exists, but the range of judgment is constrained to what was programmed. Agentic AI receives a goal and figures out the steps itself. Even without a pre-defined process, it can plan a course of action based on the situation, call tools, observe results, and decide the next move.

This difference is not a matter of degree of convenience — it is a difference in who designs the process. Traditional automation: the implementer designs the process and encodes it. Agentic AI: the implementer designs the goal and the guardrails. The agent assembles the process itself.

Autonomy Has Levels — Microsoft’s L1–L4 Framework

“Leaving it to the agent” covers a wide range. Microsoft structures the evolution of Copilot into four stages. Implementers need to understand this spectrum and deliberately choose how autonomous to make each process.

Important: “Higher autonomy” is not always better. The right level depends on business risk, compliance requirements, and organisational maturity. Agentic Engineering means choosing the appropriate level for each process — not defaulting to the highest level available.

CRM in Practice — Deal Follow-Up (L1 → L4)

Scenario: a deal opportunity has not been updated for a certain number of days.

• L1: “Write a follow-up email for this opportunity” — Copilot drafts; rep reviews, edits, and sends manually.
• L2: Agent detects 7-day stale opportunities, generates a draft, asks the rep for approval before sending.
• L3: Standard deals auto-send after 7 days. Deals over ¥5M or VIP customers require rep confirmation. This is the Wave 1 mainstream design.
• L4: Agent handles all follow-ups, proposals, and scheduling autonomously. Requires careful judgment given relationship risk.

The common design principle across both CRM and ERP: delegate routine tasks with clear decision criteria to agents; place humans at the points where emotion, complexity, or financial risk is high. Where exactly to draw that boundary is where implementation skill is concentrated.

From “Building” to “Governing” — The Engineer’s Role Shifts

As seen in the scenarios above, the introduction of agentic AI is not about “using new features.” The definition of the implementer’s job itself changes.

What does the human role concretely look like in the Dynamics 365 context?

This is not about “no longer needing to write code.” Rather, it demands people who deeply understand the essence of business processes and can judge what to entrust to AI and what not to. Business design capability over technical capability; AI governance capability over implementation capability — that is the era we have entered.

Three Questions to Ask Before Starting Implementation

Chapter 1 Summary

• Agentic AI is fundamentally different from traditional automation in that it receives a goal and figures out the steps itself
• Autonomy has levels — “higher autonomy is always better” is wrong. Choosing the appropriate level for each business process based on risk and compliance requirements is the core of design
• CRM: deal follow-up and case management; ERP: demand-driven auto-ordering, Bank Reconciliation, Sales Order Agent, Payable Agent, Expense Agent — practical-level scenarios are already in motion
• The implementer’s work is shifting from “building processes” to “governing agents.” Business design capability over technical capability; AI governance capability over implementation capability
• Introducing agents requires rebuilding the company’s business processes — that is the essence

ERP in Practice — Supply Chain, Finance, Business Central

Supply Chain Management — demand-driven auto-ordering: L3 design is the practical target: standard items below a monetary threshold auto-order; high-value orders, new suppliers, or first-time items escalate to a purchasing approval flow. Full L4 (demand forecast → order → goods receipt → cost posting, all autonomous) is recommended only for standard, low-risk items in a phased rollout.

Finance — Bank Reconciliation: L3 is again the realistic design: high-confidence matches auto-reconcile; discrepancies, high-value transactions, and first-time counterparties route to a human. Even in L4 scenarios, final approval of correcting journal entries must remain with a human to satisfy audit requirements.

Business Central — Sales Order Agent, Payable Agent, Expense Agent: All three Wave 1 BC agents follow L3 patterns — autonomous for standard cases, escalation for exceptions. BC’s single integrated data model means agents can cross business process boundaries without hitting system fragmentation, which is its key structural advantage.

Chapter 2 — Where to Place Humans? Human-in-the-Loop Design

May 2026  ·  Chapter 2  ·  Dynamics 365  ·  Agentic AI  ·  Human-in-the-Loop

→ Read the original Japanese post

Chapter 1 defined agentic AI and structured its autonomy levels. The question it raised was: “how autonomous should we make this?” That question is more precisely stated as: “where should we place humans?” — this is the Human-in-the-Loop (HITL) design principle. The more autonomously agents act, the more the placement of human intervention points governs the system’s quality, risk, and accountability.

Three HITL Patterns

CRM: Quote Approval — Two Underlying Flow Patterns

A quote is presented directly to the customer. Its amount, terms, and timing can determine whether a deal is won or lost — “over-delegating to the agent” is not acceptable here.

There are two fundamental flow patterns for quote-to-order:

Pattern A: CRM-Origin Model — The quote is created in Dynamics 365 Sales; after deal confirmation, it flows to ERP as a sales order. Preferred by companies that want to centralise customer-facing management in CRM and have complex multi-step approval chains in the sales process.

Customer → CRM (quote create/approve) → CRM (order) → ERP (sales order) → ERP (ship/invoice)

Pattern B: ERP-Origin Model — The quote and order are both processed entirely in ERP (SCM or Business Central). Preferred by manufacturers and wholesalers where inventory, cost, and delivery precision is central to the sales conversation.

Customer → ERP (quote create/approve) → ERP (sales order) → ERP (ship/invoice)

HITL Touchpoints Common to Both Patterns

① Quote amount thresholds:

• Under ¥1M: agent auto-generates and sends (post-supervision)
• ¥1M–¥5M: rep reviews and approves before sending (pre-approval)
• Over ¥5M: two-level approval — rep + manager (pre-approval)

② Customer segment branching:

• Existing customers, standard products: agent auto-generates and sends
• New customers: rep confirmation mandatory
• VIP / strategic accounts: rep + sales manager confirmation mandatory
• Customers with complaint history: human review always required before sending

③ Custom conditions and non-standard discounts: Any discount exceeding a set percentage above the standard price, or any non-standard contract terms, should automatically enter an approval flow. Agents are good at detecting anomalies — but whether to accept the anomaly is a human call.

Credit Management — Recommended Pattern

Dynamics 365 Finance, SCM, and Business Central all include credit management functionality. The recommended design is to keep credit master data in ERP, and have CRM agents access it in real time via Virtual Tables:

• Credit limit, balance, and over-limit status: owned by ERP (source of truth)
• Sales reps and CRM agents access it: via Virtual Table in real time
• Over-limit detection and approval flow trigger: automated by the agent

This ensures that the CRM agent automatically checks credit status when generating a quote — and escalates to an approval flow if there is a problem — preventing the real-world error of sending a quote to a customer whose credit cannot be approved.

ERP: Purchase Order Threshold Design — Three Axes

When designing HITL for purchasing, a single monetary threshold is not enough. At minimum, three axes must be considered and combined:

In practice, these three axes are combined: “even for an existing supplier ordering a standard item, if the amount exceeds ¥1M, escalate to an approval flow.” The agent auto-evaluates these conditions and instantly routes between autonomous execution and escalation.

SCM: Use Purchasing Policy combined with Approval Workflow to set thresholds. Finance: Expenditure management policy with automated approver determination by amount, account, and cost centre. Business Central: Approval Workflow with configurable thresholds, approvers, and escalation targets.

Three Common HITL Design Pitfalls

Chapter 2 Summary

• HITL is not “placing humans because we don’t trust AI.” It is the proactive design philosophy of placing AI and humans where each creates the most value
• The three intervention patterns — Pre-Approval, Post-Supervision, and Exception Intervention — are used based on the balance of business risk and speed
• For CRM quote approval, there are CRM-origin and ERP-origin patterns; credit management is most rational with ERP as master, referenced by CRM via Virtual Table
• For ERP purchase order threshold design, combine the three axes of amount, supplier, and item. Thresholds are not set once and forgotten — they must be continuously tuned based on decision logs
• The three design pitfalls are: approval flow rubber-stamping, threshold staleness, and ambiguous accountability. These are not technology problems — they are operational and organisational design problems

Chapter 3 — How Do Agents Use Data? CRM & ERP Data Models

May 2026  ·  Chapter 3  ·  Dynamics 365  ·  Data Model  ·  Microsoft Fabric  ·  Azure

→ Read the original Japanese post

Chapters 1 and 2 covered agent definitions and HITL design. But both chapters rest on a hidden assumption: “the agent can make correct decisions.” An agent that can deliver the no-look pass can do so because it knows where its teammates are, their speed, and what comes next. Similarly, an agent can act autonomously and correctly only if it has access to the right data, at the right time, with accuracy. This chapter examines the CRM and ERP data models: what data agents use, where they access it, and how to design for better decision quality.

Three Data Quality Requirements

CRM Data Model — Three Layers

Layer 1 — Master data (who we’re transacting with): Account, Contact, Lead. Customer attributes, industry, size, credit class, and segment. The basis for agent judgments like “Is this customer a VIP?”, “New or existing?”, “Is there credit risk?”

Layer 2 — Activity data (what is happening): Email, Phone Call, Meeting, Task, Appointment. Communication history, last contact date, deal progress. Sales Copilot’s automatic enrichment of this layer from Microsoft 365 (Teams, Outlook) is one of the major Wave 1 changes.

Layer 3 — Transaction data (what moved): Opportunity, Quote, Order, Invoice. Deal amount, stage, probability, quote content, order status. The basis for judgments like “What is the close probability?”, “Has the quote been sent?”, “Is an approval flow needed?”

CRM data weakness: CRM excels at managing customer relationships, but deep transactional detail — inventory, cost, financials — lives in ERP. An agent relying only on CRM data produces quotes without accurate cost, and confirms orders without checking inventory. This is why CRM–ERP data integration matters.

ERP Data Model — Three Layers

Layer 1 — Master data (what and with whom): Items, Vendors, Customers, Warehouses, Chart of Accounts. Item standard cost, lead time, minimum order quantity; vendor credit class, payment terms, transaction history. The basis for agent judgments like “Which supplier to procure from?”, “What is the standard cost?”, “How many days is the lead time?”

Layer 2 — Inventory and cost data (what is the current state): On-hand inventory, reserved inventory, open purchase orders, cost calculation results. The most real-time-sensitive data — critical when an agent generates a quote or makes a purchase decision. Month-end batch entry fundamentally degrades agent decision quality. Virtual Table access for CRM agents to read this layer in real time is one of the Wave 1 core capabilities.

Layer 3 — Transaction data (what moved): Purchase Orders, Sales Orders, Invoices, Journal Entries, Bank Transactions — plus, in manufacturing, Production Orders, and in service/dealer businesses, Service Orders.

Service Orders record which customer’s asset (vehicle, equipment) received what repair, using what parts. In automotive dealer TAS architectures, Service Order completion triggers a CRM after-service agent — “auto-send next inspection reminder when repair is complete”, “predict next parts replacement from wear history.” These scenarios are built on Service Order data.

Manufacturing Outsourcing and Supplied Materials

In manufacturing agent design, a critically important but often overlooked data model area is outsourced manufacturing and supplied materials.

When manufacturing is outsourced to a partner factory, it is managed in Dynamics 365 as a Subcontracting Purchase Order. The agent monitors this order’s status — has instruction been sent, what is the progress, when is the expected receipt — and alerts the responsible person if delays are detected.

There are two types of supplied materials:

• Mushoshikyu (Free Issue): Own materials provided to the outsourcer at no charge; ownership stays with your company, managed as consignment inventory. Agents can monitor consignment stock levels and trigger automatic replenishment. Note: Mushoshikyu materials remain on your balance sheet, so the ERP inventory and accounting modules must be correctly integrated as a prerequisite.
• Yushoshikyu (Paid Issue): Materials sold to the outsourcer who then manufactures the product and sells it back — a double transaction (sell then buy back). Final accounting treatment for Yushoshikyu transactions should retain a human review step.

The Virtual Table Bridge

The Virtual Table architecture enables CRM agents to read ERP data in real time without copying it. This is the key structural enabler for cross-system agent coordination in Wave 1.

What Changes When Customer Insights Is Added?

CRM captures relationship data; ERP captures financial and physical movement. Neither captures what the customer did — what pages they visited, which emails they opened, how they responded to campaigns.

Customer Insights – Data (CDP): Integrates multiple data sources to create a “unified profile of one customer.” CRM customer data, ERP transaction data, website behaviour, email open history, and POS data are consolidated into one profile: “who is this customer, what have they bought, and what are they interested in right now?”

Customer Insights – Journeys: Automatically optimises communication — email, SMS, push notifications, ads — triggered by customer behaviour and events. Combined with agents: “react to each customer’s behaviour in real time and deliver the optimal message at the optimal moment.”

Example scenario: Customer views a product page multiple times (behaviour data) → CI-Data updates the customer’s unified profile → CI-Journeys agent sends an alert to the CRM sales rep → Sales agent auto-generates a follow-up proposal combining CRM opportunity data → Rep confirms and approves. This flow works only when CRM, ERP, and Customer Insights are all connected as data.

Structured and Unstructured Data — Microsoft Fabric and Copilot IQ

All the CRM, ERP, and Customer Insights data discussed so far is structured data. But real business environments contain enormous amounts of unstructured data: past deal email exchanges, repair site damage photos, manufacturing line camera footage, customer support call recordings, CAD drawings, PDF contracts and specifications.

Microsoft Fabric is a data platform that collects, integrates, and analyses all data — structured and unstructured — in one place. SharePoint documents, Teams conversations, Azure Blob Storage images, video, and audio can all be unified in a single data lake (OneLake). Microsoft Copilot IQ allows agents to search, reference, and use this Fabric-integrated data in natural language.

Practical scenarios: when a new lead arrives, the agent searches Fabric for past similar case email history and win/loss reasons, and presents the closest historical success story to the rep. When generating a quote, the agent references past quote documents and special discount approval history from Fabric. For Service Order intake, the agent surfaces past repair history and damage photos. For manufacturing, when a quality anomaly is detected, the agent auto-searches records for the last occurrence, root cause, and resolution.

Azure Services Supporting the Architecture

Azure Functions: Solves the 2-minute plugin execution timeout that every D365 CRM developer encounters. Heavy processing, external API calls, and large-volume data operations are offloaded to Azure Functions. When agents trigger long-running processes, calling Azure Functions from Copilot Studio is the practical design.

Azure Logic Apps: Enterprise-grade integration flows with rich connectors for Dynamics 365, SAP, Salesforce, Shopify, and SaaS platforms.

Azure Data Factory: Large-volume batch processing and ETL — periodic transfer of ERP accounting data to data warehouses, importing e-commerce data into Dynamics 365.

Azure Data Lake Storage (ADLS): Aggregates ERP transaction data, repair photos, manufacturing footage, and log data — integrated with Fabric’s OneLake.

Azure Key Vault: Securely centralises API keys, connection strings, and certificates for agent external service calls.

Azure API Management (APIM): Hosts custom APIs connecting Dynamics 365 with e-commerce platforms, with centralised security, rate limiting, and monitoring.

Azure AI Foundry: Custom AI models — vehicle damage estimation from repair photos, close probability prediction from deal history, quality anomaly detection from manufacturing footage — callable as APIs from Dynamics 365 agents.

Microsoft Entra ID: Manages agent identity as service principals or managed identities. Fine-grained RBAC permissions, conditional access, MFA, PIM for high-privilege operations, and SSO across CRM, ERP, and Azure Portal. Using managed identities for Key Vault access means connection strings never appear in code.

Audit Trail Data

In a world where agents act autonomously, “who changed what, when, and why” audit trail data takes on new importance in the data model. Dynamics 365 CRM’s standard audit log records every agent action at entity and field level: status changes on opportunities, auto-generated quotes, triggered approval flows — all with the agent’s service principal as the recorded operator. The same applies to ERP. Finance requires a complete audit chain for every journal: who entered it, who approved it, who corrected it. Agent-auto-generated journal entries must be traceable in exactly the same way.

Finer-grained telemetry — execution frequency, processing time, error locations — is collected via Azure Application Insights. Combined with Power BI visualisation, this becomes the agent operations dashboard consumable at different levels of granularity by implementers, operators, and executives. This is the concrete toolchain for the continuous threshold-tuning loop from Chapter 2.

Chapter 3 Summary

• Agent decision quality is determined by data quality — Accuracy, Freshness (real-time), and Context are the three requirements. “Month-end batch entry” operations are fundamentally incompatible with agentic systems
• CRM data model: Master data (who), Activity data (what is happening), Transaction data (what moved) — three layers. CRM’s weakness is that deep transactional data lives in ERP
• ERP data model: three layers including Production Orders (manufacturing) and Service Orders (service/dealer). Mushoshikyu and Yushoshikyu are important but often-overlooked data model areas in manufacturing
• Virtual Tables: “move access, not data.” ERP remains the source of truth; CRM agents access in real time via Dataverse virtual layer
• Customer Insights + Fabric + Copilot IQ add the “what the customer did” layer and unstructured data — both critical for agent decision quality
• Azure Functions, Logic Apps, Data Factory, ADLS, Key Vault, APIM, AI Foundry, Entra ID: the infrastructure layer supporting the entire architecture

Chapter 4 — Building Agents: What Copilot Studio Can and Cannot Do

May 2026  ·  Chapter 4  ·  Dynamics 365  ·  Copilot Studio  ·  Record Deduplication  ·  Azure

→ Read the original Japanese post

Chapters 1–3 established what kind of agent to build, where to place humans, and which data to use. The next question is: how do you actually build it? The primary tool for assembling Dynamics 365 agents is Copilot Studio. But Copilot Studio is not “a tool that can do anything.” Failing to understand precisely what it can and cannot do leads to post-build surprises and production failures.

Three Design Layers in Copilot Studio

Copilot Studio has evolved from “a tool for building chatbots” into an orchestration platform for assembling multi-agent architectures. Think of it as the quarterback or fly-half — directing specialists, reading the whole field, and making the system function as a unit.

✅ What Copilot Studio Can Do

① Direct Dynamics 365 integration — concrete CRM and ERP data examples:

CRM examples:

• Reference opportunity close probability to determine next action: detect opportunities with “7 days no update AND amount ≥ ¥5M” and autonomously execute follow-up
• Reference customer complaint history to change handling: auto-trigger a manager review request when generating a quote for a customer with a complaint in the last 6 months
• Reference Customer Insights segments to personalise messages: retrieve segment tags and web behaviour scores from CI-Data; auto-generate differentiated proposals for customers who have repeatedly browsed competitor product pages

ERP examples (via Virtual Table):

• Reference real-time inventory for quotes: retrieve on-hand, reserved, and open-order quantities from SCM via Virtual Table in real time; auto-reflect “in stock — deliverable in X weeks” in CRM-generated quotes
• Reference actual cost to auto-validate discount limits: retrieve standard and actual costs from Finance/SCM via Virtual Table; agent auto-checks that quote discount rates don’t go below cost
• Reference credit balance to determine order acceptance: real-time credit limit, current AR balance, and over-limit status from Finance; agent auto-holds orders and notifies finance staff when over-limit
• Monitor Service Order completion to trigger after-service follow-up: watch Service Order completion flag via Virtual Table; on completion, CRM agent auto-sends customer completion notice, next inspection reminder, and satisfaction survey
• Return BC Payable Agent results to CRM: when BC Payable Agent completes invoice matching and approval, auto-reflect payment-complete status on the related CRM opportunity and customer record

⚠️ The Hidden Critical Topic: Record Deduplication (Name Matching)

Before the agent can “get data from CRM and ERP,” there is a prerequisite question: is the data it’s getting correct? Even the most sophisticated agent judgment logic will fail if deduplication is sloppy — “the same customer is split across three records and the agent treats them as three separate customers.” In rugby terms: an accurate pass to the wrong place.

Record deduplication means consolidating duplicate and similar records scattered across the system to reach a state of “one record per real-world entity.” In enterprise engagements, it is one of the most critical success factors.

Phase 1 — Pre-implementation deduplication:

• CRM (Sales): Before importing data, use Azure Data Factory or Power Query to identify duplicate candidates, define merge rules, and then import. Fuzzy-match on company name, phone, email, and address; flag records exceeding a match-score threshold as duplicate candidates.
• Business Central: Use BC’s built-in “Find Duplicate Customers” function to detect similar names, same addresses, and same registration numbers. A deduplication pass in Excel before RapidStart migration is strongly recommended.
• F&O (SCM / Finance) — Global Address Book (GAB): The GAB is F&O’s master directory of all parties (customers, vendors, employees, contacts). Define GAB integration rules before go-live — which fields serve as deduplication keys (company registration number, VAT number, DUNS number, etc.) — this is mandatory.

Phase 2 — Post-implementation deduplication:

• CRM (Sales): Configure Duplicate Detection Rules for real-time detection and warnings on record create, update, or import. After a merge, sub-records are deactivated and all related activities, opportunities, and cases consolidate to the master record.
• Business Central: Use the “Merge Duplicate” function. Related records (transactions, contacts) are automatically transferred to the master record before the duplicate is deactivated.
• F&O — GAB: Use the GAB Merge function. Since the GAB is used across Finance, SCM, HR, and Project Operations, a merge has system-wide impact. Do not merge without confirming the scope of impact in advance — and always design a rollback procedure.

Phase 3 — Deduplication When Integrating CRM and ERP

When CRM and ERP are integrated, the deduplication problem escalates from “duplicates within a single system” to “mismatches between systems.” If a CRM Account record and an ERP Customer record refer to the same company but are managed under different IDs, agents will cause inconsistencies.

• CRM + F&O (Dual-write): The Dual-write map linking CRM Account to F&O Customer/Vendor requires both systems to have completed deduplication first. If not, duplicate records are created in the other system during integration setup.
• CRM + Business Central: The standard BC-CRM integration connector maps CRM Account to BC Customer in a 1:1 design. If deduplication is incomplete in either system, records are created twice during integration.

Rollback When Deduplication Fails

• CRM (Sales): After a merge, the sub-record is retained in an “inactive” state. Admin manually reactivates the sub-record and restores changed field values by hand. There is no “unmerge” function — always make agents confirm with a human before executing merges automatically.
• Business Central: Rollback after BC merge is harder than CRM. Merges affect transaction data, so if an erroneous merge is detected, records must be manually recreated and related transactions re-linked.
• F&O (GAB): No standard “unmerge” function. Identifying and correcting affected transactions requires specialist knowledge. Always take a database backup before executing GAB merges.

Deduplication Audit Trails — by Platform

• CRM (Sales): Enabling Audit Log records all record changes including merge operations. When an agent executes a merge, the agent’s service principal ID is recorded as the operator.
• Business Central: Change Log configuration records change history. Merge operations, field value changes, and record deletions are saved in Change Log Entry table with user ID — agents included.
• F&O (SCM/Finance): Database Log and Audit Workbench. API-executed merges by agents are recorded with the service principal as the operator. Combined with Azure Application Insights and Microsoft Sentinel, real-time monitoring for anomalous merge activity (“large volume of merges executed in a short time”) is achievable.

Customer Insights – Data Deduplication — The Unify Process

The most systematically powerful deduplication capability in the Dynamics 365 product family is in Customer Insights – Data (CDP). Using AI-based predictive matching, it consolidates records from multiple data sources into a single master dataset.

• Step 1 — Map: Map multiple data sources to a common data model. “This field is the customer’s name,” “this field is the email address.”
• Step 2 — Match: Define rules for matching customer records across tables. Supports fuzzy matching — detects variations like “K.K.” vs “KK” in company names.
• Step 3 — Merge: Decide which columns from source tables to include, exclude, or merge into the unified profile. A unique CustomerId is assigned on unification.

The fundamental difference from CRM/BC merge: CRM and BC merges consolidate records within a system. Customer Insights – Data Unify creates a new “unified profile” layer that crosses multiple systems — while the original system records remain intact. If a matching rule was wrong, simply correct the rule and re-run Unify to regenerate the unified profiles. This “reversible” design is the key difference. The recommended enterprise approach: first use Customer Insights – Data Unify to identify which records are the same customer, then use those results to guide merge operations in CRM and ERP.

② Power Automate Integration

Power Automate flows can be called as actions from Copilot Studio. Approval flows, email sending, Teams notifications, and external system data integration designed in Power Automate can be triggered by Copilot Studio agents. The Human-in-the-Loop approval flows from Chapter 2 are implemented by combining Power Automate’s Approval connector with Copilot Studio — covering Teams notifications, email notifications, and mobile approval in one unified flow design.

③ Multi-Agent Orchestration

One of the biggest changes in Wave 1. Copilot Studio can now configure multiple agents as “parent agents (orchestrators)” and “child agents (specialists).” For example: a CRM sales agent (parent) detects that inventory availability is needed, calls an ERP inventory agent (child), receives the result, and completes the quote. Like a QB directing a receiver, the parent agent reads the situation and delegates work to the optimal specialist agent.

④ Custom Connectors and HTTP Actions

External systems not covered by standard connectors can be integrated via custom connectors or HTTP actions. E-commerce platform APIs, logistics tracking APIs, and credit check APIs can all be called via HTTP requests from Copilot Studio agents.

⑤ Azure AI Foundry Integration — Custom AI Models in Agent Judgment

Azure AI Foundry is integrated with Copilot Studio, allowing custom AI models to be called as agent actions:

• Repair photo damage assessment: Send vehicle damage photos uploaded by customers to an Azure AI Foundry computer vision model — automatically retrieve damage location, estimated repair hours, and required parts — and have the agent auto-generate a Service Order draft
• High-precision close probability prediction: Train a custom ML model on historical win/loss data, customer attributes, and market data in Azure AI Foundry — give agents more accurate close probability scores as judgment inputs
• Contract and specification auto-analysis: Analyse PDFs from customers using Azure AI Foundry document intelligence — automatically extract delivery dates, quantities, special conditions, and risk clauses

• Complex transaction processing requiring transactional integrity: Copilot Studio triggers actions, but complex transactional processing — creating a journal entry while simultaneously updating inventory and issuing an approval notification as a single atomic transaction — must be handled on the ERP side. Use Azure Functions or custom APIs to ensure transactional integrity on the ERP layer, then call them from Copilot Studio.
• Custom logic specific to each ERP platform: F&O’s X++ business logic, BC’s AL extensions — these cannot be built in Copilot Studio. Build custom logic as Azure Functions or custom APIs, expose them as actions callable from Copilot Studio.
• Large-scale batch processing: Copilot Studio is for real-time, event-driven processing — not bulk processing of tens of thousands of records. For large-volume batch jobs, use Azure Data Factory or Azure Synapse pipelines and have them triggered by agents.
• Persistent long-session state management: Copilot Studio sessions are stateless by default. For complex multi-day workflows that need state across extended periods, use Dataverse or Azure Cosmos DB for state persistence, with agents referencing it.

Chapter 4 Summary

• Copilot Studio has evolved from “a tool for building chatbots” into an orchestration platform — the quarterback directing specialist agents
• Three design layers: Knowledge (what the agent knows), Actions (what it can do), Topics (how it behaves) — HITL intervention points from Chapter 2 are implemented in Topics
• Can do: direct Dynamics 365 CRM/ERP integration, Power Automate integration, multi-agent orchestration, custom connectors/HTTP, Azure AI Foundry integration
• Record deduplication (name matching) is the hidden critical theme — pre-implementation, post-implementation, cross-system integration, and rollback scenarios must all be designed in advance
• Customer Insights – Data Unify is the most powerful deduplication tool: reversible, cross-system, AI-powered — the recommended starting point for enterprise deduplication strategy
• Cannot do: complex transactional integrity operations, platform-specific ERP logic (X++, AL), large-scale batch processing, persistent long-session state — offload these to Azure Functions, Data Factory, or Dataverse

Chapter 5 — Can You Trust Your Agent? Logging, Auditing & Compliance

May 2026  ·  Chapter 5  ·  Dynamics 365  ·  Compliance  ·  Microsoft Purview  ·  Sentinel

→ Read the original Japanese post

Autonomous agent action means “who decided what” becomes harder to see. When a human made the decision, the accountability was clear: Ikeyama-san approved this purchase order; Kawachi-san sent this quote. When an agent acts autonomously, there must be a mechanism to explain “why did this happen,” “who is accountable.” This is a compliance question, a governance question, and ultimately a question of organisational trust. Making agents trustworthy requires three things: keeping records of what they did, detecting anomalies, and designing for accountability.

Why Agent Audit Design Matters

Traditional systems were auditable because human operation itself was the audit trail. ERP/CRM logins were managed via Entra ID; record changes appeared in change logs; approvals were recorded in approval flow history.

In an agentic world, agents run 24/7/365 without human operation. They auto-execute purchase orders, auto-send quotes, auto-generate journal drafts. Without the ability to explain “which data did the agent reference, which rule did it follow, which action did it execute,” the system cannot survive internal audit, external audit, or regulatory review.

The Full Dynamics 365 Product Landscape — Technical Foundation

This series has used “CRM and ERP” as a shorthand, but the full Dynamics 365 2026 Wave 1 picture includes many more applications. For accurate audit and compliance design, understanding the technical foundations matters:

F&O (Finance/SCM) has its own audit infrastructure: Database Log, Audit Workbench, and Electronic Reporting — all sharing the same framework across Finance, SCM, and Commerce. Project Operations’ hybrid configuration (Dataverse front-end + F&O back-end) means audit trails must be designed across both layers.

Business Central’s core runs on its own proprietary platform, but its Dataverse connectivity is continuously being strengthened — with Dataverse serving as the integration gateway for CRM-connected deployments. Ensure agent action audit trails are captured on both sides of that boundary.

Governance Toolchain

Entra ID: Copilot Studio agents are registered as service principals or managed identities. Fine-grained permissions — “this agent can read but not write Opportunities in Dynamics 365 CRM” — are managed via RBAC. Privileged Identity Management (PIM) enables just-in-time, time-limited, approval-gated elevation for high-privilege operations like changing agent configuration or modifying thresholds.

Purview vs. Application Insights — how they complement each other: Dynamics 365’s native audit log answers “what changed” — used for compliance, internal control, and external audit. Azure Application Insights answers “why did this happen, and how did it behave” — used for operations monitoring, performance improvement, and incident investigation. The two are complementary, not substitutes.

Audit Design by Platform

CRM (Dataverse-based) audit design: Dataverse-based apps (Sales, Customer Service, Contact Center, Field Service) share Dataverse’s audit log. When an agent operates, the agent’s service principal ID is recorded as the operator — not “Ikeyama-san changed it” but “Sales Agent changed it.” Connected to Microsoft Purview Audit for long-term retention, advanced search, and compliance reporting.

ERP (F&O) audit design: F&O (Finance, SCM, Commerce) has the most comprehensive audit capabilities as accounting-class systems.

• Database Log: Table and field-level change history. Agent API-executed orders, journals, and credit data changes are all recorded with the agent’s service principal as “user.”
• Audit Workbench: Generates audit reports compliant with J-SOX, IFRS, and country-specific accounting regulations. Agent-executed orders, approvals, and journal operations are included.
• Electronic Reporting (ER): Auto-generates regulatory submission reports and tax filings in standard formats. Transactions processed by agents are included in ER report scope.

ERP (Business Central) audit design:

• Change Log: All operations by Sales Order Agent, Payable Agent, and Expense Agent — auto-order registration, invoice auto-matching, expense auto-approval — are recorded in the Change Log Entry table with user ID including agents.
• Financial Auditing: Retains operation history for journal corrections, deletions, and postings. A complete audit trail remains for who approved and posted the journal draft auto-generated by an agent. Since BC integrates with Dataverse via Integration Table Mapping, BC-side change logs can be routed to Microsoft Purview via Dataverse for unified management with CRM-side audit logs.

CDP and marketing audit design: Customer Insights – Data and Journeys use the same Dataverse audit log as CRM. However, personal data processed by CDP requires special attention from a GDPR perspective. Microsoft Purview Information Protection integration — automatically attaching sensitivity labels to personal data and enforcing data retention policies and access controls — is recommended.

Azure Application Insights as Complement

Standard D365 audit logs record “what changed.” But in real implementations, there are always operations that standard audit logs cannot track: the reasoning process behind why an agent made a particular judgment; Azure Functions call count, processing time, error rate; Logic Apps flow execution success/failure/retry details; Virtual Table ERP data access frequency and patterns; time from agent triggering an approval flow to approver response; full processing flow across a multi-agent architecture; and input values and judgment results when an agent evaluates thresholds.

Azure Application Insights collects telemetry from Azure Functions, Logic Apps, and Azure Web Apps in real time, recording each step of the agent’s processing chain. Four key telemetry types:

• Trace: Execution record of each processing step — “retrieved inventory data via Virtual Table,” “triggered approval flow because cost exceeded threshold”
• Custom Event: Implementer-defined business events — “order amount exceeded ¥1M, moved to approval flow,” “credit over-limit detected”
• Dependency: External service call records (D365 API, credit API, AI Foundry models) — call duration, success/failure
• Metrics: Agent processing time, call count, error rate as time series — the basis for threshold continuous tuning from Chapter 2

Power BI Agent Operations Dashboard: Application Insights telemetry visualised in Power BI, at three levels:

• Implementers: Error rate, processing time, call count time series; identification of high-error processes; Virtual Table response time distribution
• Operators: Daily auto-executed orders; escalations to approval flows; average approval time; which agents have high error rates
• Executives: Before/after agent introduction comparison of processing time; automation rate trends; approval flow count and breakdown (auto-approved / human-approved / rejected)

Building IT Compliance Agent — the concept that inspired this series: The Day 2 keynote at Directions ASIA 2026 introduced “Building IT Compliance Agent” as one of the core Agentic Engineering concepts. In a world where agents act autonomously, compliance monitoring, detection, and response can itself be handled by an agent. The Compliance Agent continuously monitors D365 audit logs, Application Insights telemetry, and Microsoft Sentinel security events in real time — detecting “a purchase order executed in violation of purchasing policy,” “a sales order registered skipping the approval flow,” “a large number of merge operations in a short time.” When an anomaly is detected, it automatically investigates root cause across telemetry and audit logs, then via Sentinel’s SOAR integration executes automated responses: suspending the agent, notifying the responsible party, escalating to the incident response team.

Chapter 5 Summary

• When agents act autonomously, “who decided what” becomes invisible — audit design is not optional, it is the foundation of organisational trust
• Three audit requirements: internal audit (policy compliance), external audit/regulatory (J-SOX, IFRS), and incident root cause analysis
• Full D365 product landscape: F&O (Finance/SCM/Commerce) share F&O proprietary platform; Business Central on NAV proprietary but Dataverse as integration gateway; CRM/Field Service/CI natively on Dataverse
• Microsoft security and compliance stack: Entra ID (identity), Defender (threat detection), Purview (governance/compliance), Sentinel (SIEM/SOAR), Application Insights (telemetry), Compliance Manager (posture visibility)
• Standard audit log = “what changed” (compliance use). Application Insights = “why/how” (operations use). The two are complementary
• Building IT Compliance Agent: in the agentic era, compliance monitoring and response can itself be an agent — this was the concept at Directions ASIA 2026 that sparked this series

Chapter 6 — Agents Spanning CRM and ERP: Integrated Design

May 2026  ·  Chapter 6  ·  Dynamics 365  ·  Design Patterns  ·  Power Apps  ·  MCP / APIM

→ Read the original Japanese post

Chapters 1–5 examined the parts. This chapter integrates them into the whole. Dynamics 365 spans CRM, ERP, Field Service, Project Operations, Commerce, Human Resources, and Customer Insights. This chapter first maps the full set of Dynamics 365 design patterns, then examines how agents operate across the integrated whole — and what becomes possible when Power Apps, MCP, and APIM are added to the picture.

Dynamics 365 Design Patterns — Full Map

Note: Customer Insights – Data (CDP) is a cross-cutting platform that can be added to any pattern. It consolidates transaction and behavioural data from CRM, ERP, Commerce, and Field Service to generate unified customer profiles. It is omitted from the pattern table below for brevity but is available as an addition to all patterns.

Field Service and Project Operations dependency (Wave 1): From Wave 1, Field Service Time Entries flow directly into Project Operations. Field technician time entries are immediately reflected in project cost and billing. Designing Field Service without Project Operations is no longer realistic.

Selected Pattern Highlights

P1 — ERP only (BC): Business Central alone handles finance (accounting, fixed assets), inventory, sales, purchasing, warehouse, projects, service, and assembly manufacturing. Typical profile: 50–300 employee manufacturer, wholesaler, or service company. Note: large parent companies often run F&O while deploying BC for domestic or international subsidiaries. Agent examples: Sales Order Agent (order to shipment instruction); Payable Agent (supplier invoice match/approve/pay); Expense Agent (policy check/approve/post); month-end close support (unposted transaction detection + task auto-generation).

P2 — ERP only (F&O): Finance + SCM-centred F&O ERP for large enterprise core business. For globally deployed manufacturers, trading companies, and large retailers needing complex supply chains, multi-currency, consolidated accounting, and regulatory compliance. Agent examples: demand-driven auto-ordering (SCM); Bank Reconciliation autonomous processing (Finance); Mushoshikyu/Yushoshikyu management and inventory auto-replenishment; manufacturing line quality anomaly detection and auto-flag on Production Orders.

P3 — ERP + D365 HR: Add standalone Dynamics 365 Human Resources to Finance + SCM. For enterprises needing full-scale recruitment management, benefits management, performance reviews, and org management beyond what F&O’s internal HR module handles. Agent examples: recruitment process automation (applicant screening, interview scheduling); linking employee skill data to Field Service resource scheduling; automatic processing of attendance data and Finance cost allocation.

P4 — CRM + BC: Combine Dynamics 365 Sales/Customer Service with Business Central — integrating front-end sales/customer management with back-end ERP. BC’s core runs on its own proprietary platform, but Dataverse serves as the integration gateway, and that connectivity continues to be strengthened. Integration Table Mapping enables field mapping between Dataverse (CRM) and BC tables directly from the UI, making bi-directional data sync between CRM and BC achievable. Agent examples: confirmed CRM opportunities auto-transfer to BC sales orders; BC credit balance accessed in real time by CRM agents via Virtual Table; BC inventory and cost referenced in real time from CRM side to verify actual gross margin before auto-generating a quote.

P5 — CRM + F&O: Combine Dynamics 365 Sales/Customer Service with Finance + SCM — the standard large-enterprise full CRM+ERP pattern. For large sales organisations with complex supply chains in manufacturing, trading, and large service companies. Agent examples: CRM quote agent references SCM actual cost and inventory availability via Dual-write in real time; credit management owned by F&O, referenced by CRM via Virtual Table; order-to-shipment-invoice-accounting end-to-end autonomous execution.

P6 — CS + Contact Center: Combine Customer Service and Contact Center with CI-Journeys — contact centre/customer support specialisation. For large call centres in telecoms, financial services, insurance, distribution, and EC. Agent examples: Contact Center agent handles first response autonomously, routing only sentiment-threshold-breaching cases to humans; Customer Service agent auto-generates responses from knowledge base; CI-Journeys agent auto-sends satisfaction survey upon case close.

P7 — ERP + Field Service + Project Operations: Combine F&O or BC with Field Service and Project Operations — maintenance, repair, and field service pattern. For manufacturing equipment maintenance service, companies with large field workforces, elevator/HVAC maintenance, and IT field support. Note: F&O and BC both include their own service (repair) modules. Agent examples: IoT sensor anomaly triggers Field Service work order auto-generation; Service Order completion triggers CRM agent to auto-send completion notice and next inspection reminder; technician skills, qualifications, and availability pulled from HR for optimal worker auto-assignment; Field Service hours auto-reflect in Project Operations for immediate cost and billing update.

P8 — ERP + Project Operations: Combine F&O with Project Operations — integrating project sales, resource management, cost, billing, and accounting. For consulting companies, system integrators, construction companies, engineering firms, and make-to-order manufacturers. Agent examples: auto-alert to PM when project budget consumption rate exceeds threshold; resource planning agent references HR data to recommend optimal project assignments; auto-reflect timesheet data into Project Operations; autonomous invoice generation after project completion.

P9 — Commerce + CRM + ERP: Combine Commerce, Sales, BC/F&O, and Customer Insights — retail/EC specialisation. For apparel, food, consumer electronics, and D2C brands with both physical stores and EC sites. Agent examples: EC site purchase behaviour aggregated in Customer Insights – Data, updating unified profiles in real time; inventory agent monitors online and offline inventory cross-sectionally and auto-executes omni-channel orders; CI-Journeys agent detects cart abandonment and auto-sends personalised follow-up email.

P10 — Full Suite: CRM + F&O + Field Service + Project Operations + Customer Insights + D365 HR — for large enterprises with multiple business units, and global companies wanting to manage manufacturing through sales to after-service end-to-end. Agent examples: Sales agent manages CRM opportunities; after deal confirmation, F&O SCM agent autonomously executes manufacturing and procurement; Field Service agent manages installation and maintenance; Project Operations agent processes project cost and billing; HR Agent references D365 HR data to optimise resource assignment; Customer Insights – Data aggregates all transaction data into CDP to provide customer insights to the Sales agent for the next deal. Customer Insights – Data can be added as a cross-cutting layer to any pattern — CDP data integration is one of the most effective investments for improving agent decision quality.

Power Apps — Simplifying Data Entry

Dynamics 365’s standard screens are feature-rich — but “too complex for field staff to use” is a problem that inevitably arises in real implementations. Power Apps solves this: design only “the screen this person uses for this task,” simplified, mobile-ready, and limited to only the necessary information. The backend uses Dynamics 365’s data model as-is; only the input screen is optimised — this is one of Power Apps’ most effective use cases.

More importantly: when input screens become simple, field staff enter data in real time. Chapter 3 established that “month-end batch entry makes agents ineffective.” Power Apps simplification is one of the most practical approaches to improving agent “ball delivery accuracy.”

Quote input screen: D365 Sales Quote entity is very feature-rich, but often a sales rep only needs “customer, item, quantity, price, delivery date.” A “Quick Quote App” in Power Apps — enter 5 fields and a Quote record auto-creates in D365 CRM — dramatically reduces input time. The agent then receives that quote data and autonomously executes cost checking and approval flow triggering.

Timesheet input screen: Time entry in Project Operations or Field Service is one of the most burdensome tasks for field technicians. A Power App where technicians enter just “today’s date, which project, how many hours, task description” from their smartphone — automatically synced to Project Operations — is the practical design. Since Wave 1 routes Field Service Time Entries directly into Project Operations, this Power App functions as the entry point for both.

Manufacturing results input — lot/serial numbers and MES integration: A Power App for line operators to enter completed count, defect count, and work hours against SCM production orders. The critical piece: lot number and serial number selection. In standard D365 SCM/BC screens, selecting lot/serial numbers requires navigating multiple screens — causing “too complex to enter on the line” and data entry being deferred. A dedicated Power App with barcode scanner or camera to read lot/serial numbers and link to the production order in one tap solves this. MES integration: Pattern A (real-time) — MES data via Azure IoT Hub auto-reflected into SCM/BC production orders with lot/serial auto-synced, eliminating manual entry. Pattern B (batch) — Azure Data Factory ETL for periodic import, minimising impact on existing MES.

Repair results input — parts serial/lot management: A Power App for technicians to enter “work content, parts used, work hours, completion photos” from smartphone against Field Service Service Orders. Key: recording which inventory parts were used at serial number level — critical for warranty management, traceability, and inventory accuracy. Scan parts barcodes to auto-input serial numbers; select available inventory lots/serials and auto-allocate from SCM inventory simultaneously with parts usage; send completion photos to Azure AI Foundry computer vision for automatic damage condition recording; on repair completion, CRM agent auto-sends completion notice and next inspection reminder.

MCP and APIM — External Integration Expanding Agent Scenarios

Once Power Apps has simplified data entry and accurate real-time data is flowing into Dynamics 365, the next question emerges: “How do we connect that data to external systems and AI?” — this is where MCP and Azure API Management (APIM) enter.

MCP (Model Context Protocol) — standard protocol connecting agents to external systems: MCP is a protocol proposed by Anthropic that is becoming an industry standard — a standard interface for AI agents to safely call external tools, data sources, and APIs. Copilot Studio agents connecting to MCP servers can reference data outside Dynamics 365 in real time. For example: connecting to an MCP server wrapping an external credit check API allows the agent to auto-check credit and reflect it in the quote at the moment of quote generation. Connecting to logistics company MCP servers enables the agent to reference real-time delivery status. SAP MCP servers allow the agent to reference SAP inventory and cost data cross-system without Dual-write. Even competitor products — Salesforce, ServiceNow — can be referenced via MCP, enabling truly cross-system agent scenarios.

APIM (Azure API Management) — the enterprise gateway: When agents call multiple external APIs and internal services, APIM serves as the enterprise gateway: rate limiting, authentication, logging, versioning, and monitoring for all agent API calls. In regulated industries, APIM’s complete API call logs are part of the agent audit trail. APIM also enables safe API exposure to external partners — making D365 data accessible to partner agents via standardised, governed APIs. For example: providing customers a quote check API via APIM allows partner agents to check Dynamics 365 quote status in real time. A procurement company API exposed via APIM allows the agent to reference supplier pricing data in real time.

Chapter 6 Summary

• A single-system-bound agent has no fundamental value — agent value emerges when it can cross the boundary between CRM, ERP, Field Service, Project Operations, and Customer Insights
• P1–P10 design patterns: from BC-only (P1) to Full Suite (P10) — choose based on company size, industry, business model, and current maturity
• Customer Insights – Data is a cross-cutting CDP that can be added to any pattern — one of the most effective investments for agent decision quality
• Power Apps simplifies data entry for field staff → real-time data entry → improves agent ball delivery accuracy. Especially important for lot/serial number management and MES integration in manufacturing
• MCP enables real-time cross-system data access beyond Dynamics 365 — external credit checks, logistics APIs, SAP, Salesforce
• APIM serves as the enterprise gateway for all agent API calls — managing security, rate limiting, logging, and versioning
• Field Service + Project Operations must be designed as a set from Wave 1 — Field Service Time Entries flow directly into Project Operations

Chapter 7 (Final) — What Will Future Dynamics 365 Engineers Need to Become?

May 2026  ·  Chapter 7 — Final  ·  Dynamics 365  ·  Engineer  ·  Survival Strategy

→ Read the original Japanese post

The question running through every chapter of this series: in a world where agents act autonomously, what should humans do? Agents write code. Agents place purchase orders. Agents answer service cases. Agents detect compliance violations. So — what does the human do?

What matters is not whether your skills increase. What matters is that your role itself changes. “How do we build this?” was at the centre of the engineer’s work. From now on, “how far do we delegate to agents — and who takes responsibility for the results?” is at the centre.

The person who tries to implement everything themselves, and the person who sees the whole as a structure and governs it — that gap will become decisive in the next few years.

The Fundamental Change in the Engineer’s Job

The phrase that has echoed throughout this series: “from building processes to governing agents.”

The traditional Dynamics 365 engineer’s work: build Power Automate flows, write plugins, customise forms, translate requirements into system workflows. All of it was “implement the process a human designed.”

In the agentic era, that structure changes. Processes are assembled by agents. Engineers no longer implement processes — they design the environment in which agents operate correctly: define goals, set guardrails, establish thresholds, design escalation conditions, monitor decision logs, and continuously tune. This is not “you don’t need to code anymore.” It is the opposite. The more capable agents become, the harder the design judgment becomes.

“The difference between someone who tries to implement everything themselves, and someone who sees the whole as a structure and governs it — that gap will become decisive in the next few years.”

This series used sports metaphors throughout: baseball catcher, soccer midfielder, rugby scrum-half and fly-half, American football receiver — all roles that “receive the ball and make judgments.” For another angle on the same question, see the slide deck AI-Era IT Survival Strategy through the Artist Metaphors of MISIA, Oasis, and Bryan Adams — created for a Power BI Weekly News guest appearance, but rooted in the same question: “In the AI era, where does human value come from?”

And one more important point: this is not about “you no longer need to write code.” It is the opposite. The more capable agents become, the harder the design judgments become. Shallow understanding will not suffice. The era demands people who can deeply understand business processes, accurately assess risk, and make decisions that account for organisational culture.

Three Rules — The Engineer’s Updated OS for the AI Era

Three musician archetypes map to three essential postures. Together they form the operating system an organisation needs to master AI rather than be replaced by it.

A Message to Dynamics 365 Engineers

The wave of Agentic Engineering is real. Agents write code, place purchase orders, answer cases, and detect compliance violations. Some of you may be feeling anxious about whether your job will disappear.

I don’t think so.

Dynamics 365 engineers are not just “technologists.” You deeply understand customer business processes, design what each system should achieve, maintain data accuracy, and underpin organisational transformation with technology. That value does not disappear with the arrival of AI. It becomes more visible.

• The more autonomously agents act, the more important the humans who judge what to make autonomous become.
• The more data agents can process, the more important the humans who define what constitutes correct data become.
• The more complex operations agents can execute, the more important the humans who design where to place humans become.

Apply the Oasis Rule to draw standardisation boundaries. Apply the MISIA Rule to design loosely coupled systems that survive change. Apply the Bryan Adams Rule to hold the wheel with the commitment to never let go of judgment. The engineer who combines all three is what the coming era needs most.

No matter how skilled the fly-half, if there is no scrum-half who can deliver accurate ball, the game doesn’t move. No matter how intelligent the AI agents become, without a system that delivers accurate data in real time — and the engineer who can design that system — agents cannot deliver the no-look pass. Your work continues. The form changes; the essence does not.

Action Plan — Making Agentic Engineering Your Own

The Day 2 keynote at Directions ASIA 2026 was structured around “Agentic Engineering in practice.” Three sessions were particularly memorable:

1. “Agentic Engineering” — the full architecture of autonomous business process execution
2. “Building IT Compliance Agent” — the motivation for writing this entire series (see Chapter 5)
3. “Beyond Buildable AI Agents: Let’s Visualise Partner Value in the AI Era” — my own session, examining how the engineer’s value shifts in the agentic era, using four archetypes

For teams who want to turn this series into concrete action, two resources are available:

• Workshop Facilitator Guide — a 90-minute facilitation guide for running an Agentic Engineering workshop with your team (5–30 people)
• Participant Takeaway Pack — worksheets, skill checklists, and action plans for participants

Teams at Directions ASIA 2026 — including a group from India who said “we’re bringing this framework back to run with our team” — have already used this material for internal workshops. The series and the session materials together can serve as a discussion framework for any team thinking through their Agentic Engineering strategy.

Some discussion questions to get started:

• Is our Dynamics 365 implementation in a state where it can deliver accurate ball to agents?
• Which processes should we delegate to agents — and where should we place humans?
• Is our system “over-tightened”? Can it survive the next Wave Release?
• Does our team have the right balance of Mechanic, Therapist, Architect, and Guide archetypes?

What Implementers Need Now

• Business process literacy: Understanding what each step in a business process means — not just technical implementation — is the prerequisite for correctly defining what agents should and should not automate.
• Threshold and guardrail design: Setting the right conditions, value limits, and escalation triggers is where implementation skill is now concentrated. This is the “code” of the agentic era.
• Audit and compliance fluency: Every agent action is a business decision. Understanding what logging and oversight are required by the business context is now a core engineering skill.
• Cross-stack integration thinking: The value of Dynamics 365 in the agentic era comes from the combination — CRM + ERP + Power Platform + Azure + Fabric + Microsoft 365. Narrow single-product specialists will find their scope shrinking.

What Decision-Makers Need Now

• Frame the question as “where do humans remain?” — not “what can we automate?” The scope of agent autonomy is a management decision, not a technology decision.
• Define accountability structures before deployment. “The agent did it” is not an acceptable audit answer. The human who designed the agent’s parameters is accountable for its actions.
• Invest in data quality as a strategic asset. An agent running on stale or inaccurate data will autonomously make wrong decisions at scale. Data quality is the precondition for safe autonomy.
• Plan for organisational change. Framing agent introduction as “agents handle the routine; humans focus on judgment” is more effective and honest than “automation will replace steps.”

Epilogue — To You, Who Will Keep Your Hands on the Wheel

May 2026  ·  Epilogue  ·  Agentic Engineering × Dynamics 365

→ Read the original Japanese post

Thank you — truly — for staying with this series through all eight chapters, from the very first prologue to the very end.

May 2026, Ho Chi Minh City, Vietnam. The discussions I had with top professionals from around the world, and the tectonic shift of the “AI Agent era” I felt with my own skin. The excitement of those days, combined with the sharp, almost alarming question — “Is Japan going to be left behind if we don’t change?” — was what drove me to write this entire series in one sustained burst.

As I mentioned in passing along the way, I carry the titles of Microsoft MVP and Microsoft Regional Director — and yet I never stop asking myself: “Am I truly worthy of these?” Chasing every Wave Release, staying planted in the fast current of change, year after year — it is anything but easy.

And yet. The engineers and consultants I met in that venue in Vietnam — who came up with warm smiles and said “That was incredible — we’re going to bring this way of thinking back to our teams” and reached out to shake my hand. The peers in Japan who write to say “I’m going to go out there and create real value.” The Directions ASIA community was extraordinary. Their words are what keep moving me forward. The moment you feel satisfied with where you are — the moment you decide you’ve earned the title — that is the moment your growth stops. Writing this series with everything I had was my own honest attempt at an answer to that question I keep asking myself.

The Series Summary — Eight Paradigm Shifts

The essence of Agentic Engineering as I have tried to present it in this series is not about handing your work over to AI and walking away.

It is about designing with clear eyes exactly where humans must remain in the loop — building rigorous audit trails, maintaining strict accountability — and governing your brilliant AI workforce with intention and care.

No matter how far the era advances, no matter how thoroughly software comes to “think and act” on its own — just as the music we love will always move our hearts through the passion of living artists, no matter the era — in the arena of business, the one who ultimately keeps hands on the wheel, makes the final decision, and accepts responsibility, is always, irreducibly, a human being.

The era of fearing technology is over. From now on, we step forward as commanders — drawing the new map of business alongside our AI agents.

If these eight chapters of blueprints serve as your survival guide through the rapids of change — and as the courage to take that first step — there is no greater joy I could ask for.

One final note. Gratefully, more and more international readers have been finding their way to this blog. Wherever you are in the world, you are engineers and allies living through the same era of change. I have left these blueprints here in English for you — as a gesture of gratitude.

I look forward to the day when we can debate passionately again, on the frontlines of the changing era, with people all over the world.

With love — to every engineer and business leader who will keep their hands on the wheel.

Ryohei Yoshijima
Microsoft MVP for Business Applications  ·  Microsoft Regional Director
DX 365 Life

This post is a complete English translation of the 7-part Japanese series + Prologue + Epilogue originally published on DX 365 Life in May 2026 by Ryohei Yoshijima (Microsoft MVP for Business Applications · Microsoft Regional Director).