This blog will discuss a potential upcoming feature that is related to the “OnLoad” event of the forms for a model driven app. The goal is to look at the process of turning this event from synchronous to asynchronous using the “app settings” component. Also, some benefits of implementing an asynchronous logic on the “OnLoad” event will be illustrated.

Please note that, at the time of writing, the documentation points out that the “OnLoad” event is only synchronous. So, not all the following is supported yet. Hopefully this new feature will be documented and available to everyone soon.

---

Microsoft Docs (OnLoad Event):

The form OnLoad events are synchronous. However, you should not make synchronous network requests in an OnLoad event handler. This can cause a slow save experience and an unresponsive app. Instead, you should asynchronous network requests. Using asynchronous requests will dramatically improve the performance of form loads compared to using synchronous requests.

---

Enable Async OnLoad using app setting

Async OnLoad feature can be enabled for a specific model-driven app using a platform component named “app setting”. Indeed, this component allows us to override the settings of a Model-driven app.

• Note that all the settings applied to all apps can be found by using the following request: /api/data/v9.2/appsettings

• For now, this appsettings record can be created by using the web api, OrganizationService of the SDK or by manipulating the XML of the Solution that contains the app to be parameterized.

Enable Async OnLoad using Flow:

Even though I am a developer, I love using Power Automate Cloud Flows to automate my processes. This will be used to automate the switch from sync to async mode when a model-driven app description is modified.

Please note that the flow below is not complete. It demonstrates that it is possible to activate this setting, and it can be greatly improved to handle all possible use-cases.

Flow overview

Flow details

• When a model driven app description is updated

  Dataverse trigger “When a row is added, modified or deleted” is used to start the flow. in this use case, the flow will start if a model driven app description is updated and contains ‘Async Onload Enabled’

  

• Get AsyncOnLoad setting definition id

  Before applying the async onload setting. The setting definition must be retrieved first. For this purpose, the “List Rows” Dataverse action will be used.

  

• Enable AsyncOnLoad

  Dataverse “Add a new row” action will be used to apply AsyncOnLoad.

  

After successful execution of the flow. A check should be made to see if a new app setting record has been created by using the following request: /api/data/v9.2/appsettings(appsettingid)

---

Sync OnLoad Event VS Async OnLoad Event

Let’s demonstrate the difference between the two modes of loading the form by implementing the following scenario.

“Navigate to a form according to the result of an asynchronous operation.”

	if (typeof (MEA) == "undefined") { MEA = {} };
	if (typeof (MEA.Account) == "undefined") { MEA.Account = {} };
	if (typeof (MEA.Account.AccountForm) == "undefined") { MEA.Account.AccountForm = {} };
	MEA.Account.AccountForm = {
	onLoad: function (executionContext) {
	var formContext = executionContext.getFormContext();
	return new Promise((resolve, reject) => {
	setTimeout(() => {
	var formItem = formContext.ui.formSelector.items.get(1);
	console.log(formItem);
	formItem.navigate();
	resolve("ok")
	}, 2000)
	});
	}
	}

view raw AccountForm.js hosted with ❤ by GitHub

1- Sync OnLoad Event

The Customer Service Hub app is used for this form loading mode:

• The first form is loaded
• When the promise is resolved, the second form is displayed

2- Async OnLoad Event

The Sales Hub App is used for this form loading mode:

• The form will be loaded once the promise is resolved
• The correct form is displayed instantly