ExamFinch.com My Study

Study guide

3.2 Extension Deployment & Schema Synchronization Modes

Practice this exam

Microsoft Dynamics 365 Business Central Developer MB-820

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Business Central Architecture & Platform Foundation

1.1 Business Central Architecture & Extensions Model 1.2 Customization Lifecycle: Cloud (SaaS) vs. On-Premises 1.3 Base Application, System Application & AppSource

2 Chapter 2: Development Environment & Configuration

2.1: Development Environment Setup: VS Code, AL: Go! Projects & Sandboxes 2.2: AL Configuration Files: app.json & launch.json Parameters 2.3: Multi-Root Workspaces & Project Dependencies

3 Chapter 3: Extension Lifecycle: Debugging, Deployment, Multilanguage & Maintenance

3.1 Debugging & Snapshot Debugging in Visual Studio Code 3.2 Extension Deployment & Schema Synchronization Modes 3.3 Multilanguage Development with XLIFF & Translation Files 3.4 Extension Maintenance, Deprecation & Breaking Changes

4 Chapter 4: Tables, Table Extensions & Data Modeling

4.1: Building Tables, Fields, Keys & Data Types 4.2: Table Extensions & Table Modifications 4.3: FlowFields, FlowFilters & Table Relations 4.4: Enums, Enum Extensions & Extensible Types

5 Chapter 5: Pages, Page Extensions & Role Centers

5.1: Page Types, Anatomy & Control Structure 5.2: Building Card, List & Document Pages 5.3: Page Extensions & Page Customizations 5.4: Role Centers, Headlines & Cue Data Modeling

6 Chapter 6: Reports & Document Generation

6.1 Report Architecture, DataItems & Dataset Design 6.2 Report Layouts: RDLC, Word, Excel & Multilanguage 6.3 Document Reports & Request Page Programming 6.4 Processing-Only Reports & Report Substitutions

7 Chapter 7: XMLports & Data Exchange

7.1 XMLport Architecture, Formats & Properties 7.2 XMLport Node Hierarchy, Triggers & Stream Manipulation

8 Chapter 8: Codeunits, Events, Triggers & Interfaces

8.1 Codeunit Types, Execution & SingleInstance Codeunits 8.2 Events, Publishers, Subscribers & Event Isolation 8.3 Interfaces, Polymorphism & Dynamic Codeunit Invocation 8.4 Installation & Upgrade Codeunits, Data Transfer & Archive

9 Chapter 9: Entitlements, Permissions & Queries

9.1 Permission Sets & Permission Set Extensions 9.2 Inherent Permissions, Inherent Entitlements & Security Scoping 9.3 Query Objects: Joins, Aggregation & Query as Report Data Source

10 Chapter 10: UI Customization, User Assistance & Onboarding

10.1 Profile Objects & Custom Page Views in AL 10.2 User Assistance: ToolTips, Teaching Tips & In-App Tours 10.3 Assisted Setup, Guided Experience & Onboarding Checklists

11 Chapter 11: Business Central Design Patterns & Data Process Model

11.1 Functional Table Types: Master Data, Supplemental & Setup Patterns 11.2 Document Standards: Header, Line, History & Journal Architectures 11.3 Data Process Model & Posting Routine Architecture

12 Chapter 12: AL Language Fundamentals, Data Types & Variables

12.1 AL Syntax, Variable Scope, Primitive & Complex Data Types 12.2 Expressions, Control Flow Statements & Built-in Functions 12.3 Access Modifiers (Public, Internal, Local) & Code Scoping

13 Chapter 13: Data Manipulation, Streams & Error Handling

13.1 Record Operations: Get, FindSet, ModifyAll & Filter Functions 13.2 Streams, File Management & TempBlob 13.3 Error Handling: ErrorInfo, TryFunctions & Collectible Errors

14 Chapter 14: Testing, Test Toolkit & Automation

14.1 Testing Architecture & the Test Toolkit 14.2 Authoring Test Codeunits & UI Handler Functions

15 Chapter 15: Telemetry, Performance Optimization & Analyzers

15.1 Telemetry Configuration & Azure Application Insights 15.2 Custom Telemetry Signals with Session.LogMessage & KQL 15.3 Performance Profiler, SetLoadFields & Query Optimization 15.4 AL Analyzers: CodeCop, AppSourceCop, UICop & PTECop

16 Chapter 16: REST Web Services & JSON in AL

16.1 HttpClient, HttpRequestMessage & REST API Consumption 16.2 JSON Processing: JsonObject, JsonArray, JsonValue & JsonToken

17 Chapter 17: API Pages, OData, Read Scale-Out & OAuth

17.1 API Pages (PageType=API), OData Web Services & REST Endpoints 17.2 Bound and Unbound OData Actions with [ServiceEnabled] 17.3 Read Scale-Out Architecture & DataAccessIntent Configuration 17.4 Microsoft Entra ID App Registrations & OAuth 2.0 Integration

3.2 Extension Deployment & Schema Synchronization Modes

Key Takeaways Explain This Topic AI

Business Central extensions are deployed through four core channels: VS Code direct publishing (F5/Ctrl+F5) for sandboxes, Web Client Extension Management upload for Per-Tenant Extensions (PTE), Business Central Admin Center for AppSource apps, and PowerShell cmdlets for on-premises/Docker automation.

Schema synchronization reconciles AL table definitions and field modifications with physical SQL database structures, managing companion extension tables ($ext) transparently.

The Synchronize (Add) schema update mode validates that all database schema alterations are strictly additive and non-destructive, protecting existing business data across sandbox and production deployments.

The Recreate mode drops and rebuilds all database tables defined by the extension, completely wiping existing table data, and is strictly restricted to development sandbox environments.

The ForceSync mode forces destructive schema changes (dropping columns, shrinking field lengths, changing primary keys) into the SQL schema, permanently destroying affected column data, and is prohibited in cloud production.

Last updated: August 2026

3.2 Extension Deployment & Schema Synchronization Modes

Deploying extensions to Microsoft Dynamics 365 Business Central requires aligning compiled AL packages ( .app files) with the target environment's application server and underlying relational database schema. Because Business Central applications manage mission-critical enterprise data, the AL platform enforces strict schema synchronization rules to prevent data corruption and unintentional data loss.

1. Extension Deployment Channels & Deployment Architecture

There are four distinct deployment channels for Business Central extensions, each designed for specific environments and operational tiers:

Deployment Channel Target Environments Mechanism Package Scope

VS Code Direct Publishing ( F5 / Ctrl+F5 / Alt+F5 ) Development Sandboxes & Docker Containers Uses Developer Endpoint ( /dev/apps ) to compile, publish, sync, and install Per-Tenant Development

Extension Management Page ( Upload Extension ) Production & Sandbox Cloud Tenants Web Client upload ( .app file) deploying via asynchronous server background task Per-Tenant Extension (PTE)

Business Central Admin Center Cloud Production & Sandbox Environments Admin Center App Management for AppSource Apps and tenant-wide updates AppSource & Global PTE

PowerShell Cmdlets On-Premises & Local Docker Containers Administrative PowerShell scripts managing server-tier publishing and tenant sync Global, AppSource & PTE

The PowerShell Deployment Pipeline (On-Premises & Docker)

For on-premises installations and automated CI/CD container environments, extension deployment follows a mandatory three-step PowerShell lifecycle: # Step 1: Publish the extension package to the server instance

Publish-NAVApp -ServerInstance BC240 -Path "C:\Apps\ContosoCustomization_1.0.0.0.app" -SkipVerification

# Step 2: Synchronize the extension schema with the tenant database

Sync-NAVApp -ServerInstance BC240 -Tenant default -Name "Contoso Customization" -Version 1.0.0.0 -Mode Synchronize

  • # Step 3: Install the extension on the target tenant
  • Install-NAVApp -ServerInstance BC240 -Tenant default -Name "Contoso Customization" -Version 1.0.0.0

Publish-NAVApp : Uploads the compiled .app binary into the Business Central Server's application metadata store. The extension becomes known to the server but is not yet active on any tenant.

Sync-NAVApp : Reconciles table definitions in the extension with the physical SQL Server database schema for the specified tenant.

Install-NAVApp : Activates the extension for users on the specified tenant, running install codeunits ( Subtype = Install ) and binding event subscribers.

2. Schema Synchronization Modes in Detail

When deploying extensions from Visual Studio Code or running Sync-NAVApp , the schemaUpdateMode property in launch.json dictates how the platform handles differences between the existing SQL database schema and the updated AL table definitions. {

  • "name": "Cloud Sandbox - ForceSync Development",
  • "type": "al",
  • "request": "launch",
  • "environmentType": "Sandbox",
  • "environmentName": "DevSandbox",
  • "schemaUpdateMode": "ForceSync"
  • }
  • The Three Synchronization Modes
  • 1. Synchronize (Default / Additive)

Behavior: Strictly validates that all changes made to tables and table extensions are additive or backward-compatible.

Allowed Modifications: Adding new tables, adding new fields to existing tables/table extensions, adding secondary keys, widening string/code fields (e.g., Text[50] to Text[100] ), and changing field captions.

Prohibited Modifications: Removing fields, decreasing field lengths, changing field data types, deleting tables, or removing primary key fields.

Failure Handling: If any destructive change is detected, synchronization terminates with a runtime schema validation error, and deployment aborts with zero data loss.

Production Availability: Yes . This is the only mode used during routine cloud production deployments.

2. Recreate (Drop and Rebuild — Sandbox Only)

Behavior: Completely drops all physical SQL tables belonging to the extension and recreates fresh, empty tables matching the current AL source code.

Data Impact: Total data destruction for all tables declared in the extension. Base application tables and tables from other extensions remain unaffected.

Use Case: Rapid early-stage development when developers frequently redesign table structures, change primary keys, or refactor data models and do not require existing test data.

Production Availability: Strictly Blocked . The Business Central SaaS platform rejects any deployment attempt with schemaUpdateMode = Recreate targeting production.

3. ForceSync (Destructive Schema Alignment)

Behavior: Compares the new AL table definitions with the current database schema and forces the database to match the new definitions, even if destructive modifications exist.

Data Impact: Deletes columns and permanently wipes data residing in removed fields, truncated fields (shortened strings), or modified data types. Intact fields retain their data.

Use Case: Iterative development where a developer wants to delete or modify specific experimental fields without wiping the entire database table.

Production Availability: Strictly Blocked in SaaS Production . Permitted only in Sandbox environments and on-premises development instances.

Loading diagram... Schema Synchronization Decision Matrix

3. Safe vs. Destructive Schema Modifications

Understanding which modifications are classified as safe versus destructive is essential for passing the MB-820 exam and maintaining operational stability in enterprise environments.

  • Schema Operation Classification Synchronize ForceSync Recreate Production Impact
  • Add new table Safe Allowed Allowed Allowed Table created in SQL
  • Add new field to table/table extension Safe Allowed Allowed Allowed Column added in SQL
  • Increase field length ( Text[30] -> Text[50] ) Safe Allowed Allowed Allowed SQL column altered ( ALTER TABLE )
  • Add secondary key Safe Allowed Allowed Allowed SQL Index created

Decrease field length ( Text[50] -> Text[30] ) Destructive Blocked Allowed Allowed Data truncated / Column modified

Change field data type ( Integer -> Code[20] ) Destructive Blocked Allowed Allowed Column dropped and recreated

  • Delete existing field Destructive Blocked Allowed Allowed SQL column dropped, data destroyed
  • Modify Primary Key fields Destructive Blocked Allowed Allowed SQL Clustered Index rebuilt / dropped
  • Delete entire table Destructive Blocked Allowed Allowed SQL table dropped, all data destroyed
  • 4. Deploying Per-Tenant Extensions (PTE) in Production

When deploying a Per-Tenant Extension ( .app ) to a live production environment via the Extension Management page ( Page 2500 ):

The administrator uploads the compiled .app package.

The administrator selects the deployment target version: Current version (deploys immediately to the active platform release) or Next minor / Next major version (schedules deployment during the next scheduled platform update).

The platform validates the extension using the PTE Analyzer and schema validator. If any breaking schema changes or missing dependencies are detected, the deployment task fails without altering the live tenant database.

An asynchronous background worker executes the installation, runs Install codeunits, and completes the activation without taking the system offline.

Exam Warning: If an extension containing destructive schema changes must be deployed to Production, developers cannot use ForceSync . Instead, they must follow the Deprecation Lifecycle : retain the obsolete fields marked with ObsoleteState = Removed , create new fields, transfer data via an Upgrade codeunit, and delete references gracefully.