As a product owner, I certainly wasn’t sleeping on the job when I saw the two examples below happen in real life with two customers, someone broke my ISV app!

We have all been there. A company moves to Microsoft Dynamics 365 Business Central, excited by the promise of cloud-driven agility, seamless AppSource extensions, and automatic updates. Yet, old habits die hard. Instead of adapting processes to fit standard functionality or extending carefully, the instinct to duplicate, rewrite, and build “custom pages” creeps back in.

When organizations treat Business Central like a legacy on-premises system, they fall into a dangerous trap: breaking independent software vendor (ISV) solutions.

AppSource extensions depend on predictable hooks, events, standard table structures, and standard UI pages. When you override core flows with bespoke objects, you don’t just add technical debt, you effectively blindfold your ISV applications.

Here are two real-world operational examples showing how custom AL development backfires on warehouse operations and third-party app integrations.

Example 1: The “New Warehouse Shipment Page” Ghost Town

The Scenario

A business decides that the standard Business Central Warehouse Shipment page (Page 7324) contains too many fields for their floor workers. Rather than using Page Extensions, Profiles (Roles), or native user-interface customization features to hide unused controls, the partner creates an entirely new custom page; let’s call it Custom Warehouse Shipment.

They adjust navigation actions and logic to reroute warehouse staff to this new custom page instead of the standard flow.

How It Breaks the ISV Solution

Suppose you install an AppSource shipping integration (like a parcel carrier app or carrier manifesting tool). These apps integrate by placing actions, FactBoxes, or triggers directly on page extensions of the standard Warehouse Shipment card:

• Page Extensions: The ISV targets pageextension 50000 ISVShippingTool extends "Warehouse Shipment".
• Event Subscribers: The ISV hooks into standard table/page action events to validate addresses, print carrier labels, or generate tracking links.

Because the company now routes warehouse operators to Custom Warehouse Shipment, the ISV actions and FactBoxes are completely missing. The app hasn’t crashed; it simply isn’t rendered. Warehouse workers click around, wonder why no shipping label prints, and log a ticket claiming the “ISV app is broken.”

In reality, the ISV extension is fine; it’s simply listening to a standard UI object that the business abandoned.

Example 2: The “Warehouse Shipment Simple” Permission & Integration Disaster

The Scenario

Seeking a stripped-down experience, a developer creates a bespoke page named Warehouse Shipment Simple. This time, instead of just displaying data differently, they write heavy AL logic behind actions to directly post or update underlying Warehouse Shipment Header and Warehouse Shipment Line records, skipping standard Business Central Codeunits and validation events.

Additionally, because new custom tables or pages were created under custom object ranges without proper permission set architecture, permission handling becomes fragmented.

How It Breaks the ISV Solution

This setup causes direct operational failures:

1. Incorrect Integration & Thrown Errors: ISV solutions rely on Microsoft’s publisher events (e.g., OnAfterPostWhseShipmentLine or OnBeforeReleaseWhseShipment). By bypassing standard posting Codeunits in Warehouse Shipment Simple, the ISV code is either skipped entirely or called out of order with incomplete data structures. The result? Unexpected runtime error exceptions like Nothing to process or database deadlock locks when the user tries to ship.
2. Damaged Permission Sets: When custom objects are created outside the standard extension scope without mapping to standard tenant security roles, existing ISV permission sets break. Users who previously had valid ISV roles (e.g., ISV-SHIP-EXECUTE) start seeing Permission Error dialogs because the custom code unit attempts to invoke ISV routines under non-elevated permissions or mismatched object access rights.

The Hidden Costs of Over-Customization

When customizations bypass standard Business Central architecture, the fallout hits every layer of the business:

Issue Area	Immediate Result	Long-Term Impact
ISV Upgrades	Features fail silently or throw continuous runtime errors.	Higher support costs and friction with app vendors.
BC Major Updates	Customized AL code fails compile-time or runtime checks on major releases (v27, v28, etc.).	Delayed update cycles and constant maintenance bills.
User Experience	UI inconsistency across departments (standard vs. “simple” pages).	Increased onboarding time and operational confusion.

A Better Way: Extend, Don’t Replace

Business Central’s modern AL architecture is explicitly designed around extensibility:

• Need a simpler UI? Use Design Mode or Profiles & Personalization to hide fields without touching code.
• Need additional fields? Use a pageextension or tableextension rather than creating duplicate target objects.
• Need custom logic? Subscribe to published Integration Events so third-party ISV solutions can continue listening alongside your business logic.

Before writing a single line of custom code that replaces a core page or table flow, ask one key question: “How will our AppSource solutions know this exists?”

Respecting the standard flow protects your ISV ecosystem, minimizes update friction, and keeps your cloud environment running smoothly.