Source: BUSINESSCENTRAL_DYNAMICS_READINESS.md

The BC equivalent of “SuiteApp” — what exists vs. net-new · BC vs. broader Dynamics 365 · snapshot 0dc4059

What this source is

A capture of docs/strategic/BUSINESSCENTRAL_DYNAMICS_READINESS.md (converted from BusinessCentral-Dynamics-Readiness.docx, snapshot 0dc4059). Companion to the NetSuite SuiteApp readiness brief. Headline: Business Central is at near-parity with NetSuite — a production connector and a tested embedded-host extension already exist — while broader Dynamics 365 is not.

The key distinction up front: Business Central (BC), the SMB ERP, is at parity with NetSuite. Broader Dynamics 365 (Finance & Operations / the Dataverse-centered apps) is NOT — the Dynamics connector is demo-only and there is no embed host. Treat “Business Central” and “Dynamics 365” as two different readiness levels.

Verify current program terms before budgeting — Microsoft’s AppSource publishing requirements and the BC technical-validation checklist evolve. Confirm current AppSource / “Microsoft 365 Certified” requirements against Microsoft’s present partner documentation before committing engineering time.

The Business Central equivalent of “SuiteApp”

NetSuite’s in-account app is a SuiteApp (SDF + SuiteScript). BC’s equivalent is an AL extension — written in AL, packaged as an .app, published to Microsoft AppSource. The same three-tier framing applies:

Target	NetSuite term	Business Central term	Status
Integrates with	SDN listing	Connector / ISV integration	BC connector is production
Embedded host	Host Suitelet (SDF)	AL page extension + control add-in	Built & tested
Full native app	Native SuiteApp (in-account SuiteScript)	Full AL extension on AppSource	Real project, not started

What already exists for Business Central (parity with NetSuite)

• A production BC connector — BusinessCentralConnector carries production status, one of the platform’s 5 production connectors.
• A tested, security-hardened AL embed extension — platform/business-central-extension/ has a proper app.json (publisher, platform/runtime 24.0/13.0, object ID range 70050100–70050199), a PageExt adding a SuiteCentral FactBox to the Customer Card, a ControlAddIn hosting the iframe, and the JS resource. Same server-to-server bootstrap as NetSuite — the browser never receives the raw service token.
• BC-specific security discipline — the AL host requires SuiteCentralBaseUrl to be https://, forwards the parent-window origin as expectedHostOrigin (server validates against ^https://[^/]+\.dynamics\.com$), hard-fails non-JSON responses, surfaces only HTTP status, and validates the returned embedSrc.
• Covered by the same conformance tooling — the adapter-conformance test exercises businessCentralExtensionAdapter alongside the NetSuite adapter; embedded-platform-adapters proof card covers both.
• Dual-ERP reconciliation — the shipped reconciler is NetSuiteBusinessCentralInvoiceReconciler; BC is a first-class citizen in the reconciliation engine.

A BC pilot is as technically feasible as a NetSuite one.

What is NOT there for Business Central

• A live-credential test (the BC analogue of V3) — production status should be backed by a test against a real BC environment + a first real install into a BC tenant with recorded evidence.
• A full native AL app on AppSource — the embed extension frames the external product; a full native app is the same “real project, not started” as NetSuite’s Target B+.
• AppSource technical validation — AppSourceCop rules, per-tenant data isolation, telemetry, upgrade-code handling, measured by Microsoft’s tooling.

Broader Dynamics 365 — a different, lower readiness level

“Dynamics” is not one product. Beyond BC, Dynamics 365 (Finance & Operations, Sales/CE, Dataverse-centered apps) is a separate platform with a different extensibility model:

• The Dynamics connector is demo-only — DynamicsConnector carries demo_only status. Real Dynamics 365 (F&O / Dataverse) data would require promoting it to production first.
• No Dynamics embed host — no Dataverse/Power Platform equivalent of the BC AL extension; embedding inside model-driven apps is a separate build (PCF control add-ins / Power Platform).

Treat broader Dynamics 365 as out of scope for now.

Honest sizing — Business Central

Target	Status	Effort
Integrate (BC connector)	Production	Live-credential test against a real BC environment. Small.
Embedded-host extension	Built & tested	First real install into a BC tenant + recorded evidence (overlaps a pilot). Small.
Full native AL app on AppSource	Real project, not started	Architecture split + AL business logic + AppSource validation. Same tier as NetSuite’s native SuiteApp.

The Squire angle

Squire is fundamentally a NetSuite consultancy (~40+ NetSuite-centric SyncCentral deployments). So BC is less of a home-court advantage than NetSuite. BC parity is best positioned as “the product isn’t locked to NetSuite” — a credibility and market-size point — rather than the first place to invest. Lead the pilot on NetSuite; hold BC as proof the architecture generalizes.

Recommendation

• For the pilot: nothing needed on the BC axis — lead on NetSuite. BC parity is a talking point (dual-ERP, not NetSuite-locked).
• If a BC opportunity appears: genuinely feasible — production connector + tested embed host already exist. Do the BC live-credential test (analogue of V3), then a BC-tenant install.
• Broader Dynamics 365 (F&O / Dataverse): out of scope for now — promote the connector to production first if a real need emerges.
• Full native AL app on AppSource: defer, same as NetSuite’s native SuiteApp.

Companion brief: NetSuite SuiteApp readiness.