Drag and Drop Question You create a Power Apps app to display customer feedback. You need to submit and display customer feedback for each sales order. In which order should you perform the actions?…

Question

Exhibit

Answer Area

Explanation

Embedding a Power Apps Canvas App in a Dynamics 365 Sales Order Form

This question tests your knowledge of how to embed a Power Apps canvas app inside a Dynamics 365 model-driven form (the Sales Order form). Here is why each step occupies its position.

Step-by-Step Breakdown

1. Navigate to the Sales order form

You must physically be on the Sales Order form in Dynamics 365 before you can do anything else. The entire goal is to embed the Power App into this specific form, so it is the natural starting point. You cannot personalize or configure a form you haven't opened.

2. Personalize the page

Once on the Sales Order form, you use D365's personalization (or form editor) to insert a Power Apps component control onto the form. This reserves a space/slot on the form where the embedded canvas app will live. You must create that slot before you can configure what app goes in it.

Common mistake: Skipping this step and assuming a published Power App automatically appears on a D365 form. It does not - the form must explicitly host a Power Apps control.

3. Configure and publish the app

With the Power Apps control now on the form, you configure it - selecting which app to display, mapping D365 parameters (like the current record's entity name and ID) that will be passed into the app. Then you publish the form customization so the changes take effect in the environment. Publishing must happen before you can interact with the live app-in-form context.

Common mistake: Publishing before adding/personalizing the control, or trying to modify OnStart before the app is wired up to D365.

4. Modify the OnStart function of the app

Now that the app is embedded and receiving D365 context parameters, you edit the canvas app's OnStart function to consume those parameters (via Param("EntityId"), Param("EntityName"), etc.). This lets the app know which sales order it is embedded in, so it can load and display the correct customer feedback. This step logically follows publishing because you need the D365 ↔ app connection to exist before writing logic that depends on it.

Common mistake: Modifying OnStart first, before the app has been connected to the D365 form, so there are no parameters to read.

5. Refresh the browser

After all configuration and code changes are saved, a browser refresh loads the updated form with the embedded, fully-configured Power App. This is always last - it is the verification/activation step, not a configuration step.

Common mistake: Refreshing mid-process and expecting changes to appear before publishing is complete.

Summary Mental Model

Find the form → Add the control → Wire up & publish → Code the logic → See the result

Each step creates a prerequisite for the next. The D365 form must exist and host the control before the app can be configured; the app must be published before its runtime parameters are meaningful; the browser refresh is always the final "reveal."

No community discussion yet for this question.