This article explains about MS Dynamics 365 Business Central Apps Life Cycle. When you build an app or extension to Business Central and get that published to AppSource, it becomes an app like so many others, the app itself can be updated and the platform that it sits on, the Business Central service itself, will also get updated.
When your app has passed all of the validations and has gone live to App Source, customers can install your extension and utilize it for their business. The following sections describe the different Dynamics 365 Business Central Apps Life Cycle upgrade scenarios as D365 Business Central is updated:
MS Dynamics 365 Business Central Apps Life Cycle Scenarios
Scenario 1: Business Central Service Update
You do not need to make any bug fixes, feature adds, or app changes to your app. It continues to work fine without any interaction on your part.
The monthly service upgrades to Business Central do not impact your app. Your app just gets moved along and no upgrade code from your app needs to get used. Business Central itself gets upgraded on your tenant, and once complete, the customer sees no difference with your Dynamics 365 Business Central Apps Life Cycle.
Scenario 2: App Update
You add some features to your app and also some minor bug fixes. The app is submitted for validation. The app passes validation and gets checked into the service. This is now the active app for any new tenants and also for existing tenants that have never had your app installed before
Customers can either do an uninstall and then reinstall on their own, or they can ask their partner do it on their behalf from the Extension Management window within Business Central.
Scenario 3: Reported Bugs in your App
You (the partner) has various customers report some bugs that are impacting their usage of the app. The bugs aren’t critical but they are important. The partner makes the fixes in the app and resubmits for validation.
The app passes validation and gets checked into the service. This is now the active app for any new tenants and also for existing tenants that have never had your app installed before
The upgrade of this app to the latest version will not be forced on all of the tenants. Some tenants may not be using the functionality that includes this bug and continue to work fine on the current version of the app.
Therefore, you should work directly with all of the impacted customer tenants to uninstall and reinstall to get the latest app version that contains fixes for the bug.
Scenario 4: Critical Bug in your App
Critical bug within the app is found in tenants. These tenants cannot do their day to day work due to this bug. This fits into the hotfix scenario as it is critical. A support ticket is related to this case. The partner immediately provides a fixed app for validation.
The validation team makes this top priority and does validation ASAP. Fixed app passes validation and gets checked into the service. All tenants with the app are refreshed automatically by the Microsoft team to this fixed version.
Scenario 5: Microsoft Feature Breaks your App
Microsoft has to break your app file for a needed Business Central core change. Some reasons for breaking could be security, bugs in the underlying code, high priority feature adds, and so on.
Here is the process when this takes place:
- First of all, Microsoft will not make a breaking change in the production environment at any point. Therefore, existing tenants are not expected to see this breaking change occur.
- When making a breaking change, it is done in a build branch that is for a future release (monthly service minor or major release)
- Notification is sent to the partner in advance and provide the partner ample time to fix their app, get it validated and have it ready
- The fixed app will already be in service and slotted as required for when your tenant is to be moved to the Business Central release that has the app breaking change
You are responsible for your app. You own the process of updating the app and providing upgrade code if the schema changes between versions of the app.
If a customer uninstalls your app and then installs it again later, then when they install the app the second time, they get the latest version from AppSource.
How Microsoft Handles your App?
When Microsoft upgrades a tenant with a service update, your app is tested against the new service version. If the app breaks, Microsoft rolls back to the previous healthy state of the app. Your customer never learns that anything was about to break.
When a tenant uninstalls and reinstalls an extension via the Extension Management page or AppSource, there is platform logic that determines whether an Install or an Upgrade must take place. The detection is done for which version of the extension the tenant previously had installed and perform the appropriate action. Therefore, the result of manually uninstalling/installing the extension is the exact same as an automated upgrade.
Additionally, there will not be any data loss during uninstall, install or upgrade actions. Data for extensions is stored in its own tables in the tenant database. Before an extension gets installed, it first get synchronized on the tenant database.
This Dynamics 365 Business Central Apps Life Cycle step is implicit and happens automatically when a tenant installs an extension. This synchronization process creates the database tables for the extension. Once the extension is installed and the tenant is using it, extension-specific data will get stored in these tables.
When an extensions gets uninstalled, these tables do not get removed. Therefore, when the extension gets reinstalled (or upgraded), the data is still available. You do not need to worry about data loss for choosing the uninstall/install route.
However, do keep in mind that if any actions are being performed on the tenant while the extension is uninstalled, the extensions events and such will not be firing and your app may miss the creation of new data.