Power Platform Tidbit #5 – What events are available in model-driven apps

Model-driven Power Apps can notify your code when certain events happen in the following parts of your apps.

  • Form
    • OnLoad – when form loads.
    • OnSave – when data is saved.
  • Tab
    • TabStateChange – when a tab expands or collapses.
  • Column
    • OnChange – when data changes in the column and its control loses focus.
  • IFrame –
    • OnReadyStateComplete – when the content of IFrame is fully loaded.

Hints!

  • TabStateChange is the best event to set the src property of an IFrame in a tab. If you otherwise do it in OnLoad event for a an IFrame that is in a collapsed tab, it will be overwritten when the tab expands!
  • OnChange happens immediately for Yes/No buttons that are formatted to use checkbox or radio buttons.
  • OnChange happens also when the data is changed on the server and the form refreshed (e.g. after a record is saved).
  • You can also trigger OnChange by calling attribute.fireOnChange.
  • Make sure to read the official docs about OnChange events. They can be tricky.
  • Try to always stick with these main events, but you can find all events that are available to you in JavaScript in here.

Reference: Configure model-driven app form event handlers

Power Platform Tidbit #4 – Workflows in Business process flows

Business process flows guide people in a stage by stage and step by step flow to get the work done consistently. The process – like anything in Power Platform – can be tailored to security roles of the users. Very often you would need to trigger workflows as users start or complete these flows or when they transition between different stages.

The two types of triggers

Workflows can be either global within the business process flow or they can be called as stage transitions.

  • Stage transition workflows can be triggered by:
    • Stage Entry
    • Stage Exit
  • Global workflows can be triggered by:
    • Process applied (*) – When business flow starts.
    • Process abandoned – When user abandons the flow and it is archived.
    • Process reactivated – When user starts and abandoned flow.
    • Process completed (*) – When user clicks to finish the last stage of the flow.

You should keep in mind that Stage Entry an Stage Exit will not be triggered for the first and last stage respectively. If you need to trigger a workflow for those situations you should rely of global workflows that are triggered by Process applied and Process completed events.

References:

Power Platforms Tidbits #3 – Power Automate flow types

There are five types of flows in Power Automate depending that you can build. Three of them are considered cloud flows.

  • Cloud flows
    • Automated flows
    • Instant flows
    • Scheduled flows
  • Desktop flows
  • Business process flows

Cloud flows

Cloud flows can be either of the following.

  • Automated flows – that are triggered when an event happens. For example when an account is updated.
  • Instant flows – that are triggered manually by a user or even a Virtual Agent.
  • Scheduled flows

Desktop flows

Desktop flows are run using Power Automate for desktop, which is replacing the two legacy options which we had before for Windows and web applications. Namely Windows recorder (V1) and Selenium IDE.

Business process flows

  • Business process flows guide users, step by step to make sure everyone on the team is following the same steps and entering data consistently.
  • You can have up to 10 concurrent business process flows per table that user can switch between and continue at any time.
  • As a bonus you can even run workflows when a user enters or leaves a workflow.

Useful tips!

  • There is an interesting tool called Process Advisor “that quickly captures detailed steps for each process in your organization to help you better understand places to streamline workflows. You can do this on your own or invite colleagues to contribute and collaborate”. Read more here: Overview of process advisor
  • Keep in mind that Power Virtual Agents can call your Instant flows. It means you can have Virtual Agents that not only reply to and guide users but take initiatives!
  • Try as much to standardize business processes in organizations as Business process flows. This approach will reduce human errors and makes it easier for every one to learn and work with the system.

References:

Power Platform Tidbits #2 – What is possible with business rules in Model-Driven Apps vs Canvas Apps

Business rules can be used by Canvas Apps or Model-driven Apps to do the following:

  • Set column values.
  • Clear column values.
  • Validate data and show error messages.

But keep in mind that they can do the following only in model-driven apps:

  • Show or hide columns.
  • Enable or disable columns.
  • Create business recommendations based on business intelligence

Reference: Define and create business rules in Dataverse

Power Platform Tidbits #1 – Business Rules vs Client-side scripts in model-driven apps

Model-driven App Designer image

When deciding between business rules and client-side scripts in Model-driven Power Apps, the best practice is to use business rules are much as possible and only resort to writing code when necessary. The following table lists some of the most important reasons you might choose one over the other.

Business RulesClient-side scripts
Run business logic on loadRun business logic on save
Set field values in formInstantly update fields in form
Show / hide fields in formFetch related data