Model-Driven Mayhem – 15 Integration Apps, One Layered Solution Strategy (And No Panic… Usually)

So far, we’ve seen Nevermore’s approach to environment strategy, solution management, and canvas apps at scale. But today, we’re stepping into deeper waters—the realm of model-driven apps and integration workloads.

This is the land of Instance 5: 15 model-driven apps, each with its own logic, tables, workflows, and relationships to internal and external systems. This isn’t just low-code; this is enterprise architecture wearing a Power Platform badge.

And yes, things get hairy.

First, Why 15 Apps?

Because Nevermore is smart enough not to build a single, bloated app with 42 forms and 80 tabs. Instead, they’ve broken their business processes into modular apps:

• Each app serves a function (e.g., Supplier Management, Asset Registration, Warranty & Insurance)
• Built on shared tables where possible
• Integrated with other systems via APIs, custom connectors, and Power Automate flows

Some of these apps talk to SAP, some to Azure SQL, and one particularly cheeky one integrates with an IoT device that refuses to follow naming conventions. But we don’t talk about that.

The Solution Strategy: Layered, Segmented, Controlled

At this scale, Nevermore can’t afford sloppy deployments. So their model-driven app strategy relies on:

1. Segmented Solutions

Each functional area has its own solution:

• Integration-Core (shared tables, plugins, business rules)
• App-SupplierMgmt
• App-WarrantyClaims
• App-AssetTracking

This keeps changes modular and helps reduce conflicts during deployments.

[Placeholder for Image: Screenshot of solution explorer with grouped solutions per app]

2. Shared Tables? One Source of Truth

Rather than copy/paste tables between solutions, shared objects live in a core base solution. These are referenced across multiple app-specific solutions.

It takes discipline, but it prevents circular dependencies and accidental overwrites—especially when tables are extended differently by multiple apps.

Managing Integration: It’s Not Just a Flow

Nevermore’s model-driven apps often interact with:

• Azure SQL databases
• External REST APIs
• On-prem systems via Data Gateway
• Other Dynamics 365 apps (via virtual tables or dual-write)

To manage this, they wrap each integration component in its own solution:

• Custom connectors
• Environment variables
• Connection references
• Child flows

This means when they deploy App-WarrantyClaims, they can deploy its connector and config settings along with it, rather than emailing someone a list of “things to set up manually” (which we’ve all done, and hated ourselves for).

Want to do the same? Environment variables & connection references

Plugin Management & Solution Layers: Danger Zone

Nevermore uses plugins for some model-driven apps, but they’ve learned the hard way: solution layering is not to be trifled with.

Install a plugin in Solution A, then try to override it in Solution B, and suddenly you’ve got ghosts of logic past interfering with your current business rules.

Their rule? Plugin logic always lives in the core solution, referenced by others, and only updated through fully versioned managed solutions. Patches and merges? Handled via source control and DevOps builds, not on-the-fly edits in the maker portal.

Application Ownership and Release Cycles

Each of the 15 apps has:

• A business owner (to define what it should do)
• A technical owner (to keep it from catching fire)
• A release plan tied to the central ALM calendar

That way, updates don’t overlap, pipelines aren’t blocked, and regression tests can be automated ahead of production releases.

Nevermore even runs automated smoke tests using EasyRepro and Power Platform CLI test scripts—because with this many moving parts, “it worked on my machine” just isn’t acceptable.

Testing: The Silent Hero

Deployments to Test and Pre-Prod don’t just happen. Each solution passes:

• Schema validation
• Component diff checks
• Flow connection validation
• API availability pings

If something fails? The pipeline halts. Alerts go out. And someone gets a Teams message with a link to the logs and a friendly “explain yerself” tone.

TL;DR – This Is What ALM Was Built For

Model-driven apps, especially those with integration points, require structure:

• Segment solutions by function
• Centralise shared tables and logic
• Wrap all external dependencies in solutions
• Avoid unmanaged changes in live environments
• Version everything and deploy using pipelines

Nevermore’s success with Instance 5 isn’t about avoiding complexity—it’s about managing it head-on, with planning, structure, and just the right amount of healthy paranoia.

Coming Next: Blog 6 – CI/CD at the Heart of the CoE

In Blog 6, we’ll visit Instance 3, the Centre of Excellence. This is where Nevermore runs their ALM pipelines, governance tooling, and platform-wide automation. It’s where everything is stitched together.

Pipelines, secrets, templates, and a touch of YAML? Aye, we’re going full DevOps next time.