ERP App Readiness: SuiteApp & Business Central

What it would actually take for SuiteCentral to run inside the ERP — as a NetSuite SuiteApp and as a Business Central AL extension — separating what already exists from the net-new engineering, and where Squire’s own expertise changes the calculus.

What this page is

A pair of partner-facing readiness briefs, captured as wiki concepts. Together they answer “could this be a real ERP-native app?” honestly — distinguishing the marketing-loose sense of “SuiteApp” from the real engineering project, and naming the three readiness tiers that the earlier evaluations under-stated. Full captures: NetSuite SuiteApp readiness and Dynamics readiness.

The three tiers (both ERPs sit at the same place)

There are three tiers hiding inside “make it an ERP app,” not two:

1. Integrates with (SDN listing / BC ISV integration) — external app, API-connected, listed as verified. Status: close — mostly the production-tier live-credential test (V3 for NetSuite; its analogue for BC) plus partnership paperwork.
2. Embedded host (NetSuite host Suitelet / BC AL page-extension + control add-in) — renders the product inside the ERP UI via a secure, account-agnostic, token-safe bootstrap. Status: built & tested for both ERPs, proof-carded (embedded-platform-adapters). Remaining: a first real install with recorded evidence (overlaps a pilot).
3. Full native app (in-account SuiteScript / full AL on AppSource) — the product’s logic runs in-account. Status: a real project, not started — gated on an architecture split decision (how much runs in-ERP vs. external) plus marketplace technical-standard conformance (Oracle BFN / Microsoft AppSource).

NetSuite ↔ Business Central parity

The platform did the same hard architectural work for both: a production connector and a secure embed host. BusinessCentralConnector is one of the 5 production connectors; the BC AL extension mirrors the NetSuite Suitelet’s hardening (https-only token transport, origin allowlisting against *.dynamics.com, no leaky bodies). This makes the product credibly dual-ERP, not NetSuite-locked.

Broader Dynamics 365 (Finance & Operations / Dataverse) is a different, lower readiness level — demo-only connector, no embed host — and is out of scope until a real opportunity justifies it.

The Squire angle

A full native SuiteApp, if pursued, should be Squire-led: Squire builds SuiteApps already (PaymentCentral et al. live inside NetSuite), so the in-account packaging muscle, SDF tooling, SDN membership, and BFN-review experience are in-house. BC is newer territory for Squire (a NetSuite-centric consultancy), so BC parity is best positioned as a market-size/credibility point rather than the first investment.

Recommendation in one line

Lead the pilot on NetSuite (Squire’s home turf, where SyncCentral lives); the embedded-host work means a pilot needs nothing further on the app-packaging axis beyond the production-tier connector test. Defer the full native apps (both ERPs) until a pilot proves the value — and make the in-ERP-vs-external architecture decision deliberately at that point.

Related: SuiteCentral 2.0 Deployment Options, Production vs Demo: What’s Real.