Different ways to trigger the flow from the model-driven app

Model-driven applications may seem painfully limited if you’ve learned Power Platform by making Canvas applications.

And they are. That’s the whole idea and beauty of them. Model-driven apps are based on a data model. Tuning the UI is difficult or impossible. On the other hand, model-driven apps are reliable. When working with them, you don’t have to wonder and test whether saving the form works. It just works.

Sometimes, however, there is a need to enrich the functionalities of these wonderful model-driven apps. This time we will get to know one such need.

That is, how do you implement the trigger function in the model-driven app form?

Example – Solution Cards

Let’s consider a simple application that maintains information about the applications used by the organization.

Once the application information is entered, it is sent to system x. When will the data be ready to be sent? It is decided by the user.

The user must therefore be offered a way to initiate data transmission.

There are several implementation options.

Starting Flow from the form

Let’s start with the simplest way. A flow is created and it is triggered from the form (When a record is selected). Flow forwards to the system x the information of the selected solution card.

Now the user can forward the solution information from the Flow menu.

Easy, but the user experience is not very special. And you can’t control that.

The user also does not receive any feedback as to whether the data transmission was successful. Of course, Flow can send a team message to the user, for example, if the transmission goes wrong. But it’s a little bit workaround I think.

Toggle

The traditional way to solve this type of problem is to add a yes/no column to the solution card. The value of the field indicates whether the information in the form is ready to be forwarded.

Let’s add a field to the form and change it to a toggle.

The user uses the toggle to mark the information in the form to be ready for forwarding.

Data is sent with a flow that starts when the value of the toggle (tp_readyforsending) changes.

Strictly speaking, flow starts only when the toggle changes to true.

Trigger Conditions: @equals(triggerOutputs()?['body/tp_readyforsending'], true)

After the information has been forwarded, we return the toggle to its original state.

Works! But could this be done differently?

Marking the form as complete from the command bar

What if the toggle introduced above was used from the command bar? Let’s edit the command bar of the solution card.

We want to edit the main form menu.

A PowerFx (2) button is added to the (1) menu.

Let’s name the button (1), change its icon (2) to a more appropriate one and define the button to execute the PowerFx command (3).

After this, the work is familiar from the canvas Power Apps world. When the button is pressed (OnSelect), the Ready for Sending column in the line is updated to true (4).

OnSelect: Patch('Solution Cards', Self.Selected.Item, {'Ready for sending':true})

When the user presses the button (1), the solution card is marked as ready for sending (2) and saved. If the user has unsaved changes on the form, they will be saved at the same time.

The toggle can be removed from the form.

Embedding the Canvas application on a form

We would like to tell the user immediately after pressing the button whether the transmission was successful or not. This can be done by using the embedded canvas app.

Let’s add a simple canvas app to the form, with which the sending is done. Adding is easiest from the old user interface (classic).

A field (1, e.g. Name) is added to the form and the properties of that field are modified (2, Change Properties).

Let’s go to the Controls tab (1), add a control and select Canvas app (2).

Let’s change the control to use the canvas application (1) and open it (2, Customize ).

Then we build a responsive canvas app that forwards the form information. We can immediately show the user feedback on the success of the transmission.

This way we have a button embedded on a form in a model-driven app.

Note that the button is not visible when creating a new card. The canvas app embedded in the form is only visible when data is being edited (when it knows which Dataverse row it is related to).

Opening a dialog from the command bar

We can open our own dialog from the command bar (custom Dialog). The dialog is practically a Power Apps (Custom page).

Let’s create one.

Our simple dialog looks like this. This Power Apps performs the actual transmission and tells the user if it was successful.

Let’s extract the name of the created dialog, we need it in the JavaScript that opens the dialog.

Then we create a javascript file.

function openCustomPageDialog(primaryControl, firstSelectedItemId, selectedEntityTypeName)
{
    // Centered Dialog
    var pageInput = {
        pageType: "custom",
        name: "tp_dialogforsend_5d2c3",
        entityName: selectedEntityTypeName,
        recordId: firstSelectedItemId
    };
    var navigationOptions = {
        target: 2,
        position: 1,
        height: {
            value: 350,
            unit: "px"
        },
        width: {
            value: 350,
            unit: "px"
        },
	title: "Send Data to system X"
    };
    Xrm.Navigation.navigateTo(pageInput, navigationOptions).then(
        function () {
            // Refresh the main form when the dialog is closed
            primaryControl.data.refresh();
        }
    ).catch (
        function (error) {
            // Handle error
        }
    );
}

Let’s add JavaScript to the solution package as its own resource (web resource).

And go back to editing the command bar of the solution card. Let’s change the action to Execute JavaScript (1). The web resource we just created is used as a library (2). The function (3) to be called is openCustomPageDialog found in JavaScript.

PrimaryControl, FirstSelectedItemId and SelectedEntityTypeName are passed as parameters (4) .

Now, when you press the button on the command bar, the dialog we built opens on the screen.

When the user presses “Send”, we forward the information and at the same time tell the user whether the transmission was successful.

Please note that custom pages do not work in my experience if mcas (Microsoft Defender for Cloud Apps) is in use in the organization.

Summary

This was again a perfect example of how the same problem can be solved in numerous different ways. All have their own pros and cons.

And PCF controls were completely ignored (e.g. https://github.com/MscrmTools/PCF-Controls#action-button).