Freight allocation in a multi-ISV, monthly-update landscape

Overlayering is not a supported customization model for Finance and Operations in the cloud; the ISV claim should be verified (it is probably a Chain of Command class, which composes cleanly with other extensions, whereas an overlay would be a deployment blocker).

Decision path:

• Additive logic (logging, validation, defaults) -> pre/post event handlers on the table and on the relevant form data sources. Handlers cannot suppress the base behaviour, so they survive base-code refactoring better.
• Logic that must wrap or conditionally skip base logic -> Chain of Command via [ExtensionOf(tableStr(SalesTable))] on a class whose update() calls next update() exactly once and never changes the signature. Multiple CoC extensions chain, so ISV coexistence is preserved.
• Do not depend on protected/internal base methods or hard-coded field lists; subscribe to SalesTable events where available.

With monthly updates, the recurring cost is regression, not code: keep an ATL/RSAT regression suite covering order confirm, invoice and the ISV processes, run it in the Tier-2 sandbox after each update, and treat Best Practice warnings and deprecation notices in the build as defects.

Model and package are different things: a model is the design-time container of objects and dependencies, a package is the deployable module produced from one or more models. Removal is a package-level operation, so the feature must not be reachable from anything else.

• Put all feature objects in a dedicated model in its own package, referencing Fabrikam Core and the ISVs, with no inbound references. Any shared contract types go into a small Contracts model that both sides reference.
• The 'everything in Core' pattern is the real risk: once another model references the feature, it cannot be dropped without editing and redeploying that model too.
• Removal also drops the column added by the table extension and its data; plan a data export first if the values matter.

For the switch, use two mechanisms, not one:

• A configuration key to exclude the UI elements (menu items, form controls, report design) from a deployment - it is build/deployment scoped.
• A parameter table keyed by dataAreaId (unique index, a find method, cached) so the business can turn the behaviour on per legal entity at runtime. Company-scoped tables filter on dataAreaId automatically, so the pilot in one entity is data isolation, not code branching.

Settle the decisions that are expensive to reverse:

1. Extensibility contract - confirm in writing that both ISVs are extension-based and support the current platform version; a single overlay blocks go-live.
2. Model/package topology - number of models, dependency direction, naming prefixes, and which model owns each new object. Changing this later means moving objects between models, which is a non-trivial refactor.
3. Environment and release flow - Dev VMs -> build pipeline -> Tier-2 sandbox -> production, with all code flowing through source control. A ten-week plan with no pipeline usually becomes a manual-deployment project.
4. Data migration ownership for any legacy freight table, because the data entity and staging design constrain the feature schema.

Defer deliberately: micro-optimizations, additional languages/localizations, and any request to expose the feature through the mobile app or Power Platform. Also defer fine-grained per-role security beyond the standard duty/privilege design - those are additive and can be layered after the pilot without schema changes.