Understanding “Parent” Access Type in Table Permissions in Power Pages

Watch the Video below or scroll to read the article.

With Real Example: Appointment (Parent) and Prescription (Child)

In Microsoft Power Pages, Table Permissions are critical to control what authenticated users can view, create, edit, or delete. When building data-driven portals, setting the right access level is essential — not just for security, but for a seamless user experience.

Among various access types, one important but often misunderstood type is the “Parent” access type. In this blog, we’ll explore what it is, how it works, and demonstrate it using a real-world healthcare scenario with Appointments and Prescriptions tables.

---

📘 What is the “Parent” Access Type?

When configuring table permissions in Power Pages, the Access Type determines how records are matched to the logged-in user. Typical access types include:

• Global – Access to all records
• Self – Access to records where the logged-in contact is the owner
• Contact – Access to records where a lookup points to the contact
• Account – Access via related account
• Website – Shared records for the portal site
• ✅ Parent – Access records based on a related parent entity where the user already has access

The Parent access type allows users to access child records (e.g., Prescription) only if they have access to the related parent record (e.g., Appointment).

---

👨‍⚕️ Real-Life Scenario: Appointments and Prescriptions

Let’s say you’re building a healthcare portal. You have the following Dataverse tables:

• Appointment: Contains appointment details and is linked to a patient (Contact)
• Prescription: Linked to the Appointment table via a lookup

🔗 Entity Relationships

• Appointment has a lookup to Contact
• Prescription has a lookup to Appointment

Here, Appointment is the parent, and Prescription is the child.

---

🎯 Goal

Allow logged-in patients (contacts) to:

• View their own Appointments
• View Prescriptions associated with those Appointments
  (but not prescriptions from other users’ appointments)

---

🔐 Step-by-Step: Configuring Table Permissions

1. Appointment Table Permission

Setting	Value
Table	Appointment
Access Type	Contact
Relationship	Contact (lookup)
Permissions	Read, Create, Append, Append To (as needed)
Web Role	Authenticated Users / Patients

✅ This allows logged-in users to access only their own appointments.

---

2. Prescription Table Permission (with Parent Access Type)

Setting	Value
Table	Prescription
Access Type	Parent
Parent Table Permission	Appointment Table Permission (created above)
Permissions	Read
Web Role	Same as Appointment (Patients)

✅ This configuration ensures the user can only view Prescriptions that are linked to Appointments they already have access to.

---

🧠 Why Use Parent Access Type?

Using Parent keeps your security model clean and dynamic. Instead of replicating logic (e.g., checking for contact access in both Appointment and Prescription), it follows the relationship hierarchy naturally.

This is especially useful when:

• You have deeply related tables (parent-child-grandchild)
• You want fine-grained access control
• The child table doesn’t directly link to the Contact or Account

---

🛠️ Example in Power Pages List/Grid

1. Create a Web Page to show Prescriptions.
2. Add a List connected to the Prescription table.
3. Make sure this List is using the Web Role with the above Table Permissions.

Now, when a logged-in user visits this page:

• They will see only Prescriptions for their Appointments.
• No extra filtering logic is needed in the List configuration.

---

🔄 Recap

Table	Access Type	Purpose
Appointment	Contact	Allows user to access their own records
Prescription	Parent	Allows user to access records linked to their appointments

---

✅ Summary

• Parent Access Type is a powerful way to grant access to child records only when the parent is accessible.
• In our healthcare use case, patients can only view prescriptions tied to their own appointments.
• This approach is clean, secure, and scalable — a best practice in Power Pages security design.