Power Apps Portals | Entity Forms Part A

This blog is part of an evolving series on Power Apps Portals in Dynamics 365, go here to view the Introductory blog with chapters.

Entity Forms are an essential component in Portal development. They are a mainstream method of presenting form data on the Portal so a user can add or edit records that will appear in your Dynamics 365 Sales Dataverse app (formerly known as Common Data Service). This blog is part one of three that will explain and demonstrate some basic elements of Entity Forms.

Part A, this blog, will cover some essential background knowledge of Entity Forms, the General tab of the Entity Form record, and the Web Page.

Part B will cover the Form Options and On Success Settings tab on the Entity Form record.

Part C will cover the Additional Settings, Entity Reference, and Entity Form Metadata tabs on the Entity Form record.

What Are Entity Forms?

A traditional database-driven web design includes a backend, middle, and frontend. Not too long ago, the backend would be a database like SQL Server, Oracle, MySQL, or something similar, residing on a server. The middle would be a software layer, using coding languages like Java, C#, or PHP.  The frontend software would be something like Visual Studio, using coding languages like HTML, CSS, and JavaScript, notwithstanding all the currently available frameworks. With Dynamics 365 Portals, the backend, middle, and frontend are part of and connected via the Power Platform.  Why does this matter?

When developing Dynamics 365 (D365) Portal Entity Forms, you are, essentially, performing frontend development. You are building components that will be displayed on the Portal website. There is one catch though – an Entity Form is a mirror projection of a D365 Sales form. For an Entity Form to exist, it must be associated to a Dynamics 365 Sales form. This means the D365 Sales form must be created before the D365 Portal Entity Form.

Entity-Forms

This is an Entity Form record, and the third field ties the Entity Form to an already-existing D365 Sales form. No D365 Sales form, no Entity Form. Both work together to display the final product on the Portal like below.

Why Use Entity Forms?

There are several reasons to use Entity Forms on the Portal; here are some of the most common:

  • One-page information-capture form
    • One-page contact us form
    • One-page feedback form
    • One-page information form
  • A detail form from a list
    • Insert, update, or read-only form
  • A modal form inside a Web Form

Development Overview

Entity Forms may be simple or complex, but, at a high level, here are the steps to get an Entity Form to display on your Portal:

  1. Create a D365 Sales entity form
  2. Create an Entity Form
  3. Define Entity Form attributes
  4. Define Entity Form Metadata
  5. Create Entity Permissions
  6. Create Web Page

Create a Dynamics 365 Sales Form

Log into make.powerapps.com, find or create the desired solution, and then add the desired entity to the solution. Select the entity, select forms, select Add form, and then select Main form. Add all the tabs, sections, and fields that should be displayed on the Portal. You may need to add some of the required fields now like Name or User, but, if needed, they can be hidden.

Entity-Forms

We now have the core of what will be the Entity Form; this will be tied, or associated, to the Entity Form of which you will create next.

Create Entity Form

Inside Power Apps, click Apps, and then click the Model-driven app named Portal Management. From the left navigation, click Entity Forms. Click + New.

Entity-Forms

General Tab

Entity, Form, and Tab Name

Enter a meaningful Name for the Entity Form record so when you see it in the list, it will make sense.

Select the correct entity of which the D365 Sales form is associated that you created above. Then for Form Name, select the correct D365 Sales form that belongs to the entity.

If you want only one tab to display on the Portal, you may select it for the Tab Name field.

Entity-Forms

Mode

There are three choices for Mode: Insert, Edit, and Read Only. They are self-explanatory in that Insert will only create records, Edit will only modify records, and Read Only will provide a read-only display of the form data.

This is an important consideration when developing Portal and especially if you need to provide an overall estimate for a certain section of the Portal website. For example, you are requested to create a one-page information capture Web Page that will utilize an Entity Form, you may provide a two-hour estimate but fail to ask vital questions like “Should the Portal User be able to edit their information?” or “Should the Portal User be able to see the information they have submitted in a read-only format?” It does not exactly triple your development time, but it will increase it, and there are other considerations as well.

In the screenshot below, I have decided to select Insert for Mode. This means that this particular Entity Form can only be used to create new records inside the Microsoft Dataverse/D365 Sales environment.

Entity-Forms

Record Source Type

You will notice that if Edit or Read Only are selected for Mode, other fields appear on the Entity Form. They are Record Source Type and Record ID Query String Parameter Name.

Record Source Type determines the source of information that should be edited or displayed. For Record Source Type, there are three options:  Query String, Current Portal User, and Record Associated to Current Portal User.

Query String

When Query String is selected for Record Source Type, this means the record ID will be provided in the Portal URL when entering this page.

The URL could look something like this:  https://your-website.powerappsportals.com/application?id= 7c061bc4-bf15-44c7-8c3e-2b21faa11361

On the Entity Form, it would be set up like this:

Entity-Forms

And here is how it would be set up for Read Only:Entity-Forms

The Portal Edit form would look something like this:

Entity-Forms

Current Portal User

When Current Portal User is selected for Record Source Type, the GUID value of the Contact that is logged into the Portal will be used as the hidden URL.

On the Entity Form, it would be set up like this:

Entity-Forms

On the Portal, notice the URL below; the ID is not appended to it because, behind the scenes, the Dataverse and D365 Portals knows what Contact is logged in and what record to display.

Entity-Forms

As you would imagine, the Current Portal User will only work for records of the same type as who is logged in; in this case, it is Contact.

Record Associated to Current Portal User

When Record Associated to Current Portal User is selected for Record Source Type, the GUID value of the associated record will be used as the hidden URL.

On the Entity Form, it would be set up like this:

Entity-Forms

On the Portal, notice the URL below; the ID is not appended to it because, behind the scenes, the Microsoft Dataverse and D365 Portals knows what associated record to display.

Entity-Forms Entity-Forms

Inside D365 Sales, we can observe that the Contact only has one ID Document record.

Entity-Forms

IMPORTANT: If more than one record exists, the Portal page will fail to load:

Entity-Forms

Enable Entity Permissions

This blog will not go into too many details about Entity Permissions, but if the checkbox is checked on the Entity Form, permissions will need to be defined.

Entity-Forms

Otherwise, we navigating to the respective Web Page, this error message will display:

Entity-Forms

At a high level, create a new Entity Permission record, and assign the desired privileges (permissions).

Entity-Forms

Once the record is created, Web Roles may be assigned to determine which Portal users will be able to perform any of the actions above.

Entity-Forms

If the actions are needed to be performed by non-logged in users, assign Anonymous Users Web Role.

Entity-Forms

Select the correct Website and Save.

Entity-Forms

Web Page

If the Entity Form needs to be displayed on its own page on the Portal, a Web Page needs to be created.

Consider a one-page application that needs to be displayed on a client’s Portal website. Here is the Entity Form:

Entity-Forms

But this by itself will not display anywhere on the Portal; we must specifically place it on a Web Page first.

Navigate to Web Pages in the left navigation and click + New.

Fill in the necessary information.

Entity-Forms

The focused item here is the Entity Form field; select the Entity Form you created above.

When we navigate to the actual Portal page, we will see the below:

Entity-Forms

Insert Example

Developing an Insert Entity Form attached to a Web Page would look something like this:

Entity-Forms

When successfully completing the form and clicking Submit, you would receive this message:

Entity-Forms

Navigating to D365 Sales Applications, you would find the new record.

Entity-Forms

Edit Example

Entity List to Entity Form with Web Page

Creating an Entity List that points to an Entity Form with a Target Type of Web Page is designed like this:

Entity-Forms

The Web Page would need to be created first (Portal Applications – Edit).

Entity-Forms

And would look like this:

Entity-Forms

Clicking one of the links for the Application would direct you to the Entity Form on a Web Page.

Entity-Forms

Entity List to Entity Form

Creating an Entity List that points to an Entity Form with a Target Type of Entity Form is designed like this:

Entity-Forms

The Entity Form already exists so no need to create additional Portal components.

Entity-Forms

And would look like this:

Entity-Forms

Clicking one of the links for the Application would open an Edit dialog window.

Entity-Forms

Read Only Example

Developing a Read Only Entity Form would look something like this:

Entity-Forms

Adding an Item Action for the Entity List that points to the read-only Entity Form looks like this:

Entity-Forms

It would look like this:

Entity-Forms Entity-Forms

This blog has demonstrated the purpose of Entity Forms and the three different Modes that can be administered along with a description of the fields on the General tab of the Entity Form entity record. Be thoughtful in your Portal development: only develop what you need and do your best to reuse Portal components for many purposes.

If you have any questions about using Portals in Dynamics 365, please contact us.

Dynamics 365 CE (CRM) How-To eGuide

41 pages of step-by-step instructions for 6 different key tasks in Dynamics 365 Customer Engagement (CRM). Includes interactions with PowerApps and Flow!

Get the eGuide

Dynamics 365 CE (CRM) How-To eGuide

Get the eGuide