Courseiva
Demonstrate the capabilities of Power AppshardMultiple SelectObjective-mapped

How to Enforce Business Rules When Updates Come from Power Automate

A company deploys a model-driven app that uses a custom table 'Project' with a status choice column. The app includes a business rule that shows a warning message when the status is set to 'Completed' but the 'End Date' is blank. The business rule works on the main form but not when records are updated via a Power Automate flow. Which THREE actions should the administrator take to enforce the rule regardless of update method?

Quick Answer

The answer is to create a synchronous plug-in on the Update message of the Project table. This is correct because client-side business rules only fire within the model-driven app form, but Power Automate flows bypass the form entirely and update the data directly in the database. A synchronous plug-in runs immediately within the same database transaction, so it enforces the business rule—checking that End Date is not blank when Status is ‘Completed’—no matter how the update arrives. On the PL-900 exam, this question tests your understanding of the difference between client-side logic (business rules, JavaScript) and server-side logic (plug-ins, real-time workflows). A common trap is thinking a business rule will apply everywhere, but remember: forms are just windows into the data, not the data itself. Memory tip: “Forms are for faces, plug-ins are for places”—client logic works where you see it, server logic works wherever the data lives.

⚠ Common exam trap

Many exam-takers assume business rules apply to all update methods, but they are client-side only and do not execute during server-side operations like Power Automate flows or API calls.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Use a synchronous plug-in that runs on the Update message of the Project table.

A synchronous plug-in runs on the Update message of the Project table, executing immediately within the database transaction. This ensures the validation logic (checking that End Date is not blank when Status is 'Completed') is enforced regardless of the update method, including Power Automate flows, which bypass client-side business rules.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Use a synchronous plug-in that runs on the Update message of the Project table.

    Why this is correct

    Synchronous plug-ins run on the server and can enforce validation.

  • Add a custom API step in the Power Automate flow to validate the End Date before updating.

    Why this is correct

    A custom step can enforce validation in the flow.

  • Configure an asynchronous workflow that runs after the update.

    Why it's wrong here

    Async workflows may not run immediately and cannot prevent the update.

  • Create a real-time workflow on the Project table to validate on update.

    Why this is correct

    Real-time workflows run on the server and apply to all updates.

  • Modify the business rule to run on all forms.

    Why it's wrong here

    Business rules only run on forms, not on server-side updates.

About these practice questions

Courseiva writes every PL-900 question from scratch — 904 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on PL-900

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. A company has a model-driven app with a custom table 'Issue' that has a choice column 'Status' with values: New, In Progress, Resolved, Closed. The app uses a business rule to set 'Resolved By' (lookup to User) when status changes to Resolved. Users report that the 'Resolved By' field is not being populated. What is the most likely cause?

medium
  • A.The 'Resolved By' lookup column is not added to the form.
  • B.The 'Resolved By' column is required and users don't fill it.
  • C.The business rule is scoped to the form but the status change happens via a quick create form.
  • D.The business rule is deactivated.

Why C: Business rules in model-driven apps can be scoped to either the entity (all forms) or a specific form. If the rule is scoped to a particular form (e.g., the main form) but the status change occurs via a quick create form, the rule will not trigger. This is the most likely cause because users report the field is not populated, indicating the rule is not firing in the context where the status is being changed.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This PL-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-900 exam.