Developed a Power Pages proof‑of‑concept that allows external users to securely submit data requests. The site uses Local Login authentication, storing user profile details and hashed passwords in the Dataverse “Contact” table. Table permissions ensure each user can only view and manage their own submitted requests. Internal staff use a model‑driven app to review incoming requests, assign reviewers, manage approvals, and upload the final data files. While not deployed to production, this project demonstrates a complete end‑to‑end workflow for secure external data submission and internal processing.
Data Request Home Page
Overview
Here is the end-to-end experience from a user’s perspective as they sign in and submit a data request. After walking through the data request submission process, I’ll break down exactly how the underlying configuration makes this functionality possible.
Users log in or register. Upon successful login, users are redirected to the home page where they can submit a new data request or view their submitted requests. Users can only see the requests they submitted.
Creating a Power Pages with the correct securities, web roles, and authentication can be a challenging process because settings required to allow access to the site and the data it contains is disperse throughout multiple different screens. Below are the table permissions, web roles, authentication, and associated table reference settings required for this solution to function.
Table Permissions
The first table permission I configured was connected to the New Data Request Form in the Power Pages site. The permission uses the “Contact” scope coupled with the “Authenticated Users” web role. This ensures only authenticated users can read, updated, create, append, and append to their own records.
The second table permission I created targeted the Contact table. Simply referencing the relationship between Data Requests and the submitting Contact in the first permission wasn’t enough to allow users to submit new requests. This is because creating a Data Request involves interacting with the Contact table through the lookup column. Power Pages treats that as accessing the Contact record itself. To support this, I added a separate permission on the Contact table. I set its Access Type to Global, which is safe in this scenario because the first permission on the Data Request Table already restricts visibility to only the logged-in user’s own Contact record. In other words, even though the Contact permission is global, the combination of permissions ensures users can reference their own Contact record without gaining access to anyone else’s. All this did in effect was allow the lookup column called “Contact” that points to the Contact table actually editable in the “New Data Request” form.
Web Roles
In addition to table permissions, each page in a Power Pages site must also have its own visibility settings. Page access is controlled through web roles and can be set to Anonymous, Authenticated, or Administrative. Since I only want logged‑in users to access the site, I set every page to Authenticated Users. With this configuration, anyone who isn’t signed in is automatically redirected to the sign‑in or sign‑up screen before they can view any page.
An alternative approach to page permissions is to set the Home screen visibility permissions to “Anyone can see this page.” This allows users to land on the home screen and opt to sign in. Clicking the “New Data Request” and “View Your Requests” button redirects the user to the sign in/register screen automatically with no other configuration needed.
Authentication
To ensure only authenticated users can access the site, I enabled Local sign‑in within the Identity Providers section of the Security settings. Local sign‑in lets users log into Power Pages using a username and password which are securely stored (hashed) in the Dataverse Contact system table.
After enabling Local sign-in, I also allowed External Login, Open Registration, and Require Unique Email. This allows people to not only sign in, but sign up (i.e. register) without a Microsoft Account. Registering on the Power Pages adds a new row to the Contact table with the user’s profile information. The Unique Email requirement prevents duplicate entries on the Contact table at registration.
Associated Table Reference
The next challenge was finding a way to ensure the “Contact” lookup field in the “New Data Request” form defaulted to the logged in user. This functionality is achieved by configuring the “Associated Table Reference” settings. The tutorial linked below was incredibly helpful for this process.
Click the ellipses next to the appropriate app in Power Pages and enter Power Pages Management
Click Websites > Select the applicable site > select the Form you want to configure
Set Table Reference on Save to “Yes” and select “Associated Table Reference” option and configure the table, relationship, and enable “Populate Lookup field.” Additionally, select “Record Associated to Current Portal User” in the “Source Type” setting and select the “master_contact” relationship.
Next open the Basic Form Metadata option and configure accordingly
Finally, select the Additional Settings > Advanced Settings Option and enable Associated Current Portal User Option and Select the Contact Lookup from the column Dropdown.
Results
The Contact field now auto populates to the logged in user. Ideally, in production, the Contact field would be hidden, but it’s visible for demonstration purposes here.
Model-Driven App
Now let’s take a look at the solution from the internal, model-driven app side using the “New Data Request” view.
The highlighted portion shows the Request Status is automatically set to new so it displays in the correct view in the app. This behavior is enforced by a business rule set at the entity level shown below.
This entity-level business rules ensures the Request Status value is set to “New” when a record is created regardless of the source.
Here we will update the Reviewer and Reviewing Supervisor fields. A business rule shown below sets the “Request Status” to “Pending” automatically.
Business rule that updates the request status to pending when both a reviewer and reviewing supervisor are added.
From the external user’s perspective in the Portal, the Request Status field on the List component reflects the status change.
Next, we’ll complete the review and upload the file that contains the data the contact requested.
This implementation is clearly a proof‑of‑concept, as a production system would separate approval responsibilities across different roles and ideally incorporate a Business Process Flow to guide the review and approval stages. Even so, the overall design lends itself well to a data governance team responsible for evaluating data requests and securely delivering reports back to users.
Challenges
No records showing in the List component on the “My Requests” screen
One of the trickiest issues I ran into was troubleshooting the List component on the “My Requests” page. Even though the Data Request table clearly contained rows with the correct Contact lookup, signing in as that Contact always showed an empty list with a message saying no records were available. After digging into the configuration, I discovered the problem wasn’t permissions at all. It was the view I had assigned to the List component. The view included a filter that excluded the record I expected to see. The fix ended up being simple: I created a new view without the filter, and the records appeared immediately.
