This is arguably the most important chapter in this course — it's the one thing that keeps a Power Pages site from becoming a security incident. Lists and Forms let a visitor see or submit data. Table Permissions decide exactly which records, and which fields, any given visitor can reach through them.
- Table permissions are a separate system from internal security roles — the two never overlap
- Each one defines a table, a scope, and a set of privileges
- Scope options: Global, Contact, Account, Parent, Self
- Privileges: Read, Write, Create, Delete, Append, Append To
A completely separate system from security roles
If you've been through the Security & Access course, you already know how internal users get access: a security role is assigned to a user, deciding which tables and privilege levels they have inside the model-driven app. It's natural to assume Power Pages reuses that same mechanism for external visitors. It doesn't.
A visitor's access on the portal is governed entirely by table permissions and web roles (next chapter). An internal security role has no bearing whatsoever on what an external visitor can see, and a table permission has no bearing on what an internal user sees inside the model-driven app. The two systems run in parallel, deliberately kept apart.
What a table permission actually says
A single table permission record answers three questions:
- Which table does it apply to?
- What scope of records within that table does it cover?
- Which privileges (specific actions allowed) does it grant?
Getting the scope right takes the most care — it's what stops one visitor from seeing another visitor's data.
| Scope | What it means |
|---|---|
| Global | Every record in the table, regardless of who it belongs to |
| Contact | Only records where a lookup field equals the visitor's own Contact record |
| Account | Only records linked to the visitor's Account (company) |
| Parent | Records related through a parent record the visitor already has access to |
| Self | Only the specific record the visitor themselves created |
Alongside scope, a table permission grants specific privileges, which work much like the privilege checkboxes on an internal security role:
- Read — view a record
- Create — make a new one
- Write — edit an existing one
- Delete — remove one
- Append / Append To — link records together
A table permission can grant any combination of these, so a visitor might be allowed to Read and Create Cases, but never Delete or Write to one once it's submitted.
A second keycard system, just for the storefront
Picture the storefront-and-back-office idea from Chapter 1 more literally. Employees carry a regular building keycard that opens the stockroom, office, and loading dock. Out at the storefront counter, an entirely separate keycard system controls which shelves a customer can reach — the employee badge was never part of it at all.
That's exactly the relationship between security roles and table permissions. An employee's internal keycard doesn't even apply at the storefront — it wasn't built for that door. Table permissions are the separate keycard system installed specifically for the visitor-facing side of the building, and they're the only thing deciding what an outside visitor can reach.
Why getting this wrong is dangerous
Table permissions are the only gate standing between a public visitor and real Dataverse data. A scope set too loosely — Global instead of Contact, for instance — can silently expose every customer's records to every other customer.
There's no security role quietly backstopping that mistake, because security roles don't apply here at all. Getting the scope, and the specific privileges, right on every table exposed to a portal isn't optional polish — it's the core safety mechanism of the entire site.