Background
The Organisation
& The Situation
The Organisation
APEX Digital — a UK industrial electronics
manufacturer with a completed D365 F&O go-live in 2022. By
2023, the system held
three years of high-quality operational data —
purchase orders, inventory movements, vendor invoices, customer
balances, and the full general ledger — across three legal
entities.
The Problem
Despite the investment,
operational leaders could not get real-time answers from
D365
without a finance analyst, an IT ticket, or a stale batch export.
A D365 investment of over
£2M was yielding perhaps 40% of its potential value. Simultaneously, staff used AI assistants daily — but those
assistants had zero access to live ERP data.
The Mandate
Bridge the gap between AI assistants and live D365 data — without
building a bespoke integration from scratch
-
Reduce D365 query time from 8–15 minutes to under 5 seconds
-
Enable 14 operational teams to query live ERP data
conversationally
-
Maintain full audit logging, RBAC, and human-in-the-loop on all
write operations
-
Deliver against a £285K Year 1 budget with 18-month payback
target
My Role — What I Personally Owned
Programme Manager · Accountable Owner
-
MCP integration architecture — 5 ADRs before a line of code was
written
-
D365 security model design — 2 service principal,
least-privilege pattern
- Azure infrastructure selection and governance
- Responsible AI controls and write guardrail design
- Vendor evaluation and build sprint management
- Board reporting and benefit realisation tracking
Section 1
The Challenge
Getting a meaningful answer from D365 required one of three paths
— all slow:
a finance analyst building an SSRS report (15–30 min), an IT member running an OData query manually, or a batch export
to Excel that was always a day out of date.
No self-service route existed for the procurement
manager, supply chain director, or CFO — the people who most
needed live data.
Every D365 data request required
raising a helpdesk ticket — creating bottlenecks,
delays, and a 340+ ticket backlog that consumed IT capacity.
Operational leaders were making decisions on stale data
— verbal summaries and day-old batch exports rather than live D365
figures.
A
£2M+ D365 investment was delivering approximately 40% of its
potential value
— the data existed; the access layer did not.
The COO's exact words: "I can tell you what our
inventory position was yesterday. I cannot tell you what it is
right now without calling someone in IT. That is not an enterprise
system — that is a very expensive database."
Staff used
Microsoft Copilot and an internal Claude-based
assistant
daily for drafting, analysis, and research — but these AI tools
had zero access to live D365 data.
No machine-readable interface existed between the AI layer and the
ERP. The AI assistants could not answer
"What are our top 10 open POs?" or
"What is current stock for SKU-4821?"
Anthropic's Model Context Protocol (November
2024) provided the answer: a standards-based interface layer
exposing D365 data as AI-consumable tools — without building a
bespoke integration from scratch.
Chief Operating Officer · APEX Digital
"I can tell you what our inventory position was yesterday. I cannot
tell you what it is right now without calling someone in IT. That is
not an enterprise system — that is a very expensive database."
Section 2
My Approach —
Key Decisions Made
Five Architecture Decision Records were written before a single line
of code. Three governing principles shaped every decision: Security
First, Standards-Based, and Human in the Loop.
| Decision (ADR) |
What I Decided |
Why — The Reasoning |
| AI interface (ADR-MCP-01) |
Model Context Protocol — Anthropic open standard, Nov 2024
|
Standards-based — works with any MCP-compatible AI client. No
vendor lock-in. Microsoft, OpenAI, and Google all adopted MCP
within 12 months of release
|
| Runtime (ADR-MCP-02) |
Node.js 20 / TypeScript on Azure Container Apps |
Native MCP SDK support; persistent process (no cold starts);
Azure Container Apps auto-scales 1–3 replicas; UK South region
for data residency
|
| Authentication (ADR-MCP-03) |
Two service principals — read SP and write SP — separated at
D365 layer
|
Read SP: GET only across 6 tools. Write SP: POST to
PurchaseOrderHeaders only. Even if both credentials were
extracted, an attacker could only create draft POs requiring
human D365 approval
|
| Write governance (ADR-MCP-04) |
Draft-only writes — createDraftPurchaseOrder never submits
automatically
|
Human-in-the-loop is non-negotiable for financial operations. AI
creates drafts; humans approve in D365 workflow. 100% compliance
target from Day 1
|
| Secrets management (ADR-MCP-05) |
Azure Key Vault with KV References — secrets never in code or
config files
|
Security reviewers approved architecture immediately because
credentials were visibly isolated — no debate required. Audit
log captures every tool call with timestamp, success/fail,
duration
|
Responsible AI Controls — Established Before Go-Live
Draft-Only Write Guard
The createDraftPurchaseOrder tool can only POST a Draft-status
PO — it cannot submit, approve, or modify any existing record.
Human approval in D365 workflow is mandatory before any PO
becomes active.
Least-Privilege Service Principals
Two Entra ID service principals with separate Key Vault secrets.
Read SP: GET requests only. Write SP: POST to
PurchaseOrderHeaders only. Zero cross-entity permissions.
Full Audit Logging
Azure Monitor / Log Analytics captures every tool call — tool
name, timestamp, success/fail, duration, and user context.
Available for security review and compliance audit.
Role-Based Access Control
D365 security roles configured to ensure each service principal
can only access the specific OData entities required by its
assigned tools — no broader data access possible.
Section 3
What Was Built
& Deployed
3.1 Architecture
The MCP server sits between the AI client and D365 F&O's OData REST
API. Four layers — AI client, MCP server, OAuth/D365, and audit — each
with clear separation of responsibility.
System Architecture — Four Layers
AI Client
Claude Desktop · Microsoft Copilot · Any MCP-compatible
client
↓ MCP Protocol (stdio / HTTP)
APEX MCP Server
Node.js/TypeScript · Azure Container Apps UK South · Token cache
· Audit logger · Draft-only write guard
↓ OAuth 2.0 — Service Principal (Client Credentials)
D365 F&O v10.0.46
OData REST API · PurchaseOrderHeaders · InventoryOnHandEntries ·
LedgerTrialBalance · VendorInvoiceHeaders ·
CustomerBalanceStats
↓
Azure Monitor
Structured audit log — every tool call logged with timestamp,
tool name, success/fail, duration
3.2 The Seven MCP Tools
| Tool |
What It Does |
Business Value |
Read
getOpenPurchaseOrders
|
Natural-language queries against live D365 PO data — filter by
vendor, item, date range
|
Procurement manager answers "What's due this week?" in 3 seconds
|
Read
getInventoryLevels
|
Real-time stock on hand across sites and warehouses, with
below-threshold flagging
|
Supply chain identifies stockouts before they cause production
stops
|
Read
getFinancialSummary
|
Trial balance snapshot by fiscal year, period, and account
category
|
CFO gets real-time P&L position without analyst intervention
|
Read
getVendorInvoices
|
AP invoice status with overdue detection and exposure
calculation
|
Finance team catches late payment risks before supplier
escalation
|
Read
getCustomerBalances
|
AR outstanding balances, credit utilisation, and overdue
customer list
|
Credit control acts on exceptions immediately rather than from
weekly reports
|
Read
searchVendors |
Vendor master lookup by name, group, currency, or country |
Eliminates manual vendor code lookup before raising POs |
Write · Draft Only
createDraftPurchaseOrder
|
Creates a Draft-status PO in D365 — never submits automatically.
Requires human D365 workflow approval before becoming active
|
Procurement saves 12 minutes per PO while retaining full D365
approval control
|
Section 4
Outcomes &
Business Impact
3sec
Avg query time (vs 8–15 min)
58%
D365 helpdesk ticket reduction
£320K
Annual benefit Year 2 steady state
100%
Draft PO compliance — zero auto-submitted
| Benefit Target |
Target |
Actual |
Status |
| D365 query response time |
Under 5 seconds |
3.1 sec avg |
Exceeded ↑ |
| Finance analyst time saved |
2 hours/day |
2.6 hours/day |
Exceeded ↑ |
| Procurement PO drafting time |
−10 min/PO |
−12 min/PO |
Exceeded ↑ |
| D365 helpdesk tickets (data queries) |
−40% |
−58% |
Exceeded ↑ |
| Write operation compliance (draft-only) |
100% |
100% |
Met ✓ |
| Payback period |
18 months |
14 months |
Exceeded ↑ |
| Year 1 ROI |
Break-even |
£35K net gain |
Exceeded ↑ |
Chief Financial Officer · APEX Digital
"Before this project I needed to ask IT for a D365 report or wait
for the weekly finance pack. Now I ask a question and get the answer
in the same conversation. It has changed how I prepare for board
meetings entirely."
Section 5
Lessons
Learned
What Worked
Strict ADR process — five decisions documented
before a line of code was written. Prevented scope creep and
accelerated every subsequent technical decision.
Two service principal pattern — security
reviewers approved the architecture immediately because write
permission was visibly isolated. No debate needed.
MCP open standard — when Microsoft announced
Copilot Studio MCP support in early 2025, our server was already
compatible. Zero rework required.
Azure Container Apps persistent process — no
cold starts, predictable latency. Azure Functions would have
failed the 5-second SLA.
What I Would Do Differently
OData entity validation earlier —
CustomerBalanceStatistics had a different schema in our D365
environment than standard documentation. A two-day delay that a
Postman validation sprint on Day 1 would have prevented.
User adoption plan from Day 1 — the technology
worked on go-live day but only 3 of 14 teams were using it in
Week 1. A structured rollout with team champions would have
accelerated adoption significantly.
Token caching tested under load earlier — D365
token expiry under concurrent requests caused two brief UAT
outages. The fix was simple once identified; it should have been
in the test plan from the start.
Section 6
Supporting
Artefacts
The following documents and source code are available as part of this
portfolio.
APEX-BC-MCP-001
Business Case — MCP D365 Integration
Board-ready submission: £285K investment, £320K annual benefit,
14-month payback analysis, risk register, and financial model.
Available on request
APEX-ADR-MCP-001–005
Architecture Decision Record (5 ADRs)
Covering: AI interface choice (MCP), runtime selection,
authentication pattern, hosting platform, and write governance
policy.
Available on request
APEX-Phase2-Workbook
Hands-On Configuration Workbook
5-module technical workbook: Entra ID setup, local MCP server
build, D365 OData validation, Azure Container Apps deployment,
and Claude Desktop integration.
Available on request
mcp-server-src/
MCP Server Source Code
Complete TypeScript MCP server — 7 tools, D365 OAuth client,
Dockerfile, and environment configuration. Deployable against
any D365 F&O environment with role reconfiguration.
Available on request
Note on Confidentiality: Company name, financial
figures, and personal details have been anonymised for portfolio use.
The architectural approach and delivery model reflect proven practices
from real programme experience. The financial figures have been scaled
to be directionally representative rather than exact client data.