Business Central Admin Center Adds PTE Deployment API and Scheduling Ahead of 2027 Upload Retirement

For Business Central administrators, DevOps engineers, and Microsoft partners, this change is far more than a cosmetic UI consolidation. It establishes a unified control plane for uploading .app packages, scheduling deployments across update cadences, wiring continuous integration and continuous delivery (CI/CD) pipelines into a single multipart API call, and exposing those same endpoints as tools through the Admin Center API Model Context Protocol (MCP) server for AI-assisted workflows in editors like Visual Studio Code. At the same time, it starts the countdown clock on legacy deployment habits: in-client PTE uploads on the Extension Management page are scheduled for removal in 2027 release wave 1.

Here is a full breakdown of how the new admin center PTE lifecycle works, the exact API mechanics introduced in version 2.29, and the operational gotchas administrators need to navigate during the transition.

Consolidating the PTE Lifecycle: What Changed?​

Historically, the Business Central admin center allowed administrators to view installed extensions and uninstall them, while the actual act of uploading a custom .app package—or staging it for an upcoming release—required logging into the Business Central web client and opening the Extension Management page, or scripting a multi-step sequence against the Automation API.

Under the new governance and administration capability, the Business Central admin center and its API now handle the full lifecycle of per-tenant extensions:

• Direct Package Uploads: Administrators can upload .app packages directly from the Manage Apps page or an extension's App Details view in the admin center, as well as through a single REST endpoint.
• Flexible Deployment Scheduling: Uploads can be installed immediately or scheduled for the environment's next update window, next minor update, or next major update (subject to specific rules for net-new extensions versus upgrades).
• Pending Version Visibility and Cancellation: Administrators can inspect upcoming scheduled PTE versions and cancel pending installations before they execute.
• Direct CI/CD and MCP Tooling: The Admin Center API accepts direct binary package uploads without the complex setup constraints of the legacy Automation API, and exposes all new endpoints through the Admin Center API MCP server so developers can trigger and inspect deployments from VS Code and AI-assisted workflows.

Inside the Admin Center UI Workflow​

For administrators managing environments manually through the browser, the workflow now lives alongside Global Apps and DEV Extensions on the environment's Manage Apps page.

Step-by-Step Upload and Scheduling​

1. Navigate to the Business Central administration center, select Environments, choose the target environment, and select the Manage Apps icon.
2. Filter or switch the dropdown view to Per-tenant Extensions, or open a specific extension's App Details page.
3. Select Install Extension and browse to select the .app package (up to 50 MB). Business Central automatically inspects the package metadata to determine whether the file represents a brand-new PTE for that environment or an upgrade to an already-installed extension.
4. Choose the Deployment schedule:
   • For a new PTE: You may only select Immediate or Next update window. Business Central does not allow staging a brand-new, never-before-installed PTE for a future minor or major environment update.
   • For an update to an existing PTE: You can choose Immediate, Next update window, Next minor update, or Next major update.
5. Select the Sync Mode (Add or ForceSync) to govern how schema changes synchronize with extension data.
6. Review and accept the end-user license agreement and terms, then confirm the upload.

Once submitted, Business Central validates the .app file and queues the job. Administrators can monitor active progress from the Operations page in the admin center, or view and cancel pending scheduled deployments from the extension's App Details page.

Scheduling Rules and Cadence Nuances​

Microsoft's documentation in Microsoft Learn outlines several strict scheduling behaviors that administrators should keep in mind when staging multiple releases:

• Multiple schedules across different windows are allowed: You can stage different versions of the same PTE simultaneously if they target different deployment schedules—for instance, scheduling version 2.1.0.0 for the Next update window while simultaneously staging version 3.0.0.0 for the Next major update.
• One version per schedule slot: You cannot schedule multiple versions of the same PTE for the exact same deployment schedule, nor can you assign the exact same PTE version to multiple deployment schedules at once. If you need to move a staged package from the next minor update to the next update window, you must cancel the scheduled installation, re-upload the .app package, and select the new schedule.
• Apps Update Cadence does not apply to PTEs: The environment-level Apps Update Cadence setting (Default, With major updates, or With minor and major updates) governs when global Marketplace apps update automatically. It has no effect on per-tenant extensions, which always follow the explicit schedule chosen at upload time.

Under the Hood: Admin Center API v2.29 for CI/CD Pipelines​

For DevOps teams and partners automating releases through Azure DevOps, GitHub Actions, Azure Logic Apps, or Power Automate, Microsoft Learn's Admin Center API documentation details three new endpoints introduced in API version 2.29.

1. Upload and Schedule a PTE (pteInstall)​

Instead of initializing an upload record and streaming bytes in separate steps via the old Automation API, version 2.29 accepts a single multipart/form-data request:

POST /admin/v2.29/applications/{applicationFamily}/environments/{environmentName}/apps/pteInstall
Content-Type: multipart/form-data

In this route, {applicationFamily} is typically BusinessCentral and {environmentName} targets the specific sandbox or production environment. The form payload supports the following parameters:

A 200 OK response returns an operation tracking payload containing the operation id, appId, targetAppVersion, scheduleKind, timestamps (createdOn, startedOn, completedOn), and status (scheduled, running, succeeded, failed, canceled, or skipped). Immediate deployments return a status of running, whereas deferred deployments return scheduled.

2. List Scheduled PTE Operations (scheduledPteOperations)​

To audit what is currently staged in an environment's pipeline, tools can query:

GET /admin/v2.29/applications/{applicationFamily}/environments/{environmentName}/apps/scheduledPteOperations

This endpoint returns all entries with "status": "scheduled", including the scheduleKind and a parameters snapshot showing the name, publisher, syncMode, languageId, countryCode, and targetRelease (for example, showing "29.0.0.0" when a tenant on 28.x stages an app for NextMajorUpdate).

3. Cancel a Scheduled PTE Version (removeScheduledPteVersion)​

If a staged build fails QA or needs to be pulled before the maintenance window hits, pipelines or administrators can cancel it via:

POST /admin/v2.29/applications/{applicationFamily}/environments/{environmentName}/apps/{appId}/removeScheduledPteVersion
Content-Type: application/json

{
  "targetVersion": "2.0.0.0",
  "scheduleKind": "NextMajorUpdate"
}

Here, scheduleKind must be UpdateWindow, NextMinorUpdate, or NextMajorUpdate. Canceling a scheduled deployment changes its status to canceled and permanently deletes the uploaded .app binary for that version from storage.

Critical Operational Traps and Governance Considerations​

While unifying PTE management in the admin center simplifies day-to-day administration, Microsoft Learn's technical documentation highlights four areas where careless automation or mixed workflows can trip up teams.

1. The Split-Brain Visibility Trap Before 2027 Wave 1​

Right now, Business Central is in a transitional period. Until Microsoft removes PTE upload capabilities from the in-client Extension Management page in 2027 release wave 1, both the legacy in-client page and the Admin Center exist side by side.

However, scheduled installations do not sync across the two interfaces while pending:

• A PTE version scheduled from the in-client Extension Management page is invisible in the Admin Center until after the installation finishes.
• Conversely, a PTE version scheduled via the Admin Center (or Admin Center API) does not appear on the in-client Extension Management page until the installation completes.

If an internal admin schedules a hotfix via the web client while an external partner triggers a pipeline via the Admin Center API, neither side will see the other's pending deployment in their respective UI. Organizations should immediately standardize on the Admin Center and its v2.29 API as their single source of truth for each environment.

2. Uninstalling via API vs. Admin Center UI​

Pay close attention to how uninstalls interact with scheduled future versions. While the Admin Center UI documentation notes that uninstalling a PTE cancels scheduled updates in the portal workflow, the Admin Center API documentation carries an explicit warning for programmatic uninstalls (POST.../apps/{appId}/uninstall):

When you uninstall a PTE by using this API endpoint, it doesn't remove scheduled versions. To remove these versions, use the Cancel Scheduled Per-Tenant Extension (PTE) Install or Update endpoint. This removal ensures a new version of the uninstalled PTE doesn't install later.

Click to expand...

If your automation scripts tear down an extension via the uninstall endpoint without checking scheduledPteOperations and calling removeScheduledPteVersion, a previously staged update can resurrect the extension during the next update window. Also keep in mind that if you pass "deleteData": true during an uninstall, extension tables and fields are purged; recovering that data beyond Business Central's 28-day point-in-time restore window requires exporting an environment database backup beforehand.

3. The Legal Weight of acceptIsvEula​

In an interactive Marketplace or portal installation, an administrator sees a prompt detailing end-user license agreements, privacy policies, and terms of use. Because an API call has no user interface, setting "acceptIsvEula": true in a CI/CD script or an AI-assisted MCP tool call legally binds the tenant to those terms—including granting Microsoft permission to share account, usage, and transactional information with the extension provider for support and billing. DevOps engineers should treat acceptIsvEula as a deliberate governance sign-off rather than just another boolean needed to make a build script turn green.

4. MCP Server and Entra ID Permissions​

Exposing the Admin Center API through a Model Context Protocol (MCP) server allows developers in VS Code to ask an AI assistant to check environment statuses, inspect failed operation IDs, or push an extension build to a sandbox. However, the MCP server is an interface layer, not a permission bypass.

Accessing the Admin Center or its API requires internal, delegated, or application administrator permissions (such as the Dynamics 365 Business Central Administrator or Dynamics 365 Administrator roles in Microsoft Entra ID). Furthermore, setting up service-to-service (S2S) authentication for automated pipelines requires registering a Microsoft Entra application, assigning the AdminCenter.ReadWrite.All application permission, and registering the client ID on Business Central's Authorized Microsoft Entra apps page. Note that while a Dynamics 365 Administrator can manage Business Central environments, granting tenant-wide admin consent to an Entra application registration requires an appropriate Entra role (such as Global Administrator, Privileged Role Administrator, or Cloud Application Administrator).

Practical Migration Checklist for Admins and DevOps Teams​

To take advantage of the new capabilities and avoid disruption ahead of the 2027 wave 1 deprecation deadline, Business Central teams should take the following steps:

1. Audit Active Deployment Paths: Identify every person, partner, PowerShell script, GitHub Action, or Azure DevOps pipeline currently deploying .app files via the in-client Extension Management page or the legacy Automation API (extensionUpload).
2. Stop Mixing Interfaces: Pick a cutoff date to move each environment exclusively to the Business Central Admin Center and Admin Center API v2.29 so pending schedules remain visible in one place.
3. Enforce Strict Version Increments in CI/CD: Business Central checks deployment uniqueness across package ID, app ID + version, and name + publisher + version. Recompiling an .app file without incrementing its version number—even when retrying a failed deployment—can trigger upload conflicts. Ensure build pipelines automatically increment the build or revision number on every artifact.
4. Update Uninstall Scripts: Whenever an automated workflow calls the uninstall endpoint for a PTE, add a pre-check against scheduledPteOperations and invoke removeScheduledPteVersion for any queued updates.

Summary​

By bringing full PTE upload, scheduling, and cancellation capabilities into the Business Central Admin Center and API v2.29—and surfacing those controls to modern developer workflows via the Admin Center API MCP server—Microsoft has closed a long-standing gap in Business Central governance. Administrators get a single pane of glass for every app type in their tenant, and release engineers get a cleaner, single-request REST endpoint that fits naturally into modern CI/CD pipelines. Just be sure to retire your in-client upload habits and update your Automation API scripts well before the 2027 wave 1 cutoff arrives.