This is the chapter that matters most for keeping a Power Pages site from leaking data. Table permissions are the entire security model for what a portal visitor can read, write, create, or delete — completely independent of internal Dataverse security roles.

Scope types

  • Global — applies to every record in the table, regardless of ownership.
  • Contact — only records where a lookup points to the current user’s own Contact record.
  • Account — records associated with the current user’s Account (useful for B2B portals where a company’s users should see their organization’s shared records).
  • Self — only the Contact record representing the signed-in user themselves.
  • Parent — inherited from a related record’s own table permission (e.g. a Case Note’s access follows its parent Case’s permission).

Permissions are explicit and deny by default

With no table permission configured for a table, portal visitors get zero access to it — not read-only, not limited, nothing. Every table a portal needs to touch must have an explicit table permission record, assigned to one or more web roles, with the specific privileges (Read/Write/Create/Delete) it needs.

The most dangerous mistake in Power Pages work. Setting a table permission to Global scope when Contact scope was intended — for example, giving every authenticated user Global Read access to a Case table instead of scoping it to their own Contact. This single misconfiguration can expose every customer’s support cases to every other customer. Always default to the narrowest scope that satisfies the actual requirement, and explicitly justify anything wider than Contact/Account scope.

Combining with web roles

A table permission is only active for the web roles it’s explicitly assigned to — this is the link between “what data exists” (table permissions) and “who gets it” (web roles, covered next chapter).