Entity lists are a fundamental building block of Power Apps Portals, now known as Power Pages, that allow portal developers to display collections of Dataverse table records to authenticated and anonymous portal users through configurable list views that support filtering, sorting, pagination, and search without requiring custom code for basic scenarios. An entity list connects a portal page to a specific Dataverse table and a specific system view or personal view defined in that table, rendering the records returned by that view as a table or gallery on the portal page with columns corresponding to the fields selected in the view. This declarative configuration approach allows business users and low-code developers to surface Dataverse data on customer-facing and employee-facing portals quickly and consistently without the overhead of building custom data retrieval and rendering components from scratch for every list requirement.
The practical value of entity lists extends far beyond simple data display because they serve as the launchpad for user interactions with individual records, linking each listed row to entity forms that allow users to view record details, initiate editing workflows, and trigger business process actions. In a customer self-service portal, an entity list might display a customer’s open support cases with status indicators and creation dates, allowing each case row to link to a detail form where the customer can read case notes or submit additional information. In an employee portal, an entity list might show pending approval requests assigned to the current user, with each row linking to an approval form where the reviewer can examine the details and take action. These interaction patterns are the bread and butter of portal application development, and mastering entity list configuration including the security controls that govern which records each user sees is essential for building portals that deliver the right information to the right people reliably and securely.
Dataverse Security Model Foundations
Before configuring record-level security on entity lists, understanding how the Dataverse security model works and how it interacts with Power Apps Portals authentication is essential because the portal security configuration does not operate independently but rather layers on top of and integrates with the underlying Dataverse security architecture. Dataverse implements a comprehensive security model built on business units, security roles, teams, and table permissions that controls access to records at multiple levels of granularity. Security roles define the privileges that control whether a user can create, read, write, delete, append, and append to records in each table, and these privileges are applied at different levels including organization-wide access to all records, business unit access to records owned by users in the same business unit, team access to records shared with a team, and user-level access to records owned by the specific user.
Portal users are distinct from internal Dataverse users in how their identity and security context are managed. When a portal user authenticates to a portal, their portal contact record is associated with a system user record in Dataverse that serves as their identity for security evaluation purposes. The portal user’s access to Dataverse records is governed by table permissions configured in the portal, which translate the portal user’s authenticated session into appropriate Dataverse security role assignments that determine what records are accessible through portal operations. This translation layer means that configuring record-level security for portal entity lists requires configuring both the Dataverse table permissions that define what operations portal users can perform and the entity list security settings that enforce those permissions on the specific list being configured. Understanding this two-layer security model prevents the common configuration mistake of securing one layer while leaving the other open, which either prevents all access when the Dataverse layer is restrictive or exposes all records when the portal layer is permissive.
Table Permissions Configuration
Table permissions are the portal-specific security constructs that define what Dataverse records portal users can access and what operations they can perform on those records, and configuring them correctly is the most critical step in implementing record-level security for entity lists. Table permissions are created and managed through the Portal Management app in the Power Platform, and each permission defines the access scope, the privilege level, and the relationship filters that together determine which specific records are accessible to users who hold that permission. Without any table permissions configured for a table, entity lists displaying records from that table will show no data to portal users regardless of how the entity list itself is configured, because the portal enforces a deny-by-default security posture that requires explicit permission grants for all data access.
The access scope setting on a table permission is the most consequential configuration choice because it determines which records in the table are included within the scope of the permission. Global scope grants access to all records in the table regardless of ownership or relationship, which is appropriate for reference data and lookup tables that every user needs to read but that would be inappropriate for sensitive records that should be visible only to their owners or related parties. Contact scope grants access only to records that are directly related to the portal user’s contact record through a specified relationship, which is the correct scope for records that belong to individual users such as their own orders, cases, or profile information. Account scope grants access to records related to the contact’s parent account through a specified relationship, enabling scenarios where all users within the same customer account should see the same set of records such as all support cases opened by anyone in their company. The parental and self-referential scope options support hierarchical and recursive relationship scenarios that arise in more complex data models. Selecting the access scope that correctly matches the business rule for which users should see which records is the design decision that most directly determines whether the resulting security implementation is both correct and appropriately restrictive.
Configuring Entity List Security
Entity list security configuration in the portal layer complements the table permissions configured in the Dataverse layer by enabling the security evaluation that enforces table permissions on records displayed in the list. The most important security setting on an entity list is the Enable Table Permissions toggle, which when enabled causes the entity list to evaluate the table permissions of the current user before displaying records and to filter the displayed records to only those the user is permitted to see according to their table permissions. When this toggle is disabled, the entity list bypasses table permission evaluation entirely and displays whatever records the underlying view returns to all users regardless of their authentication status or configured permissions, which is appropriate only for lists of public reference data with no security requirement but is a significant security misconfiguration for lists of sensitive or user-specific records.
The Create, Edit, Delete, and Details action buttons that can be configured on entity list rows each have their own permission requirements that can be tied to table permissions, ensuring that users only see action buttons for operations they are actually permitted to perform on a specific record. Configuring the Create button to require the Create privilege in the table permission, the Edit button to require the Write privilege, and the Delete button to require the Delete privilege prevents users from seeing and attempting actions that their permissions would not allow, reducing both security risk and user confusion from operations that fail with permission errors after the user has already initiated them. Metadata filters on the entity list that restrict which records are displayed based on column values can complement table permissions by applying additional business rule filters beyond the ownership and relationship criteria that table permissions express, such as showing only records with a specific status value or records created within a specific time period, narrowing the displayed records to the relevant subset for each use case.
Contact Scope Implementation
Contact scope table permissions are the most commonly used record-level security configuration for portals serving individual authenticated users because they implement the intuitive and widely applicable business rule that each user should see their own records and nobody else’s. Implementing contact scope correctly requires that the Dataverse table being listed contains a lookup field that references the Contact table, establishing the relationship through which the portal determines which records belong to the current user. For tables that directly represent user-owned records such as service requests, feedback submissions, or personal profiles, this lookup field is typically a direct relationship to Contact that identifies the submitting or owning contact, and the contact scope table permission references this relationship to filter records to those where the lookup field matches the current portal user’s contact record.
Configuring the contact scope permission requires opening the Portal Management app, navigating to the Table Permissions section, creating a new permission for the relevant table with Contact scope selected, specifying the relationship name that connects the table to Contact, and assigning the appropriate privileges. The relationship name must exactly match the schema name of the lookup field in Dataverse, and using the correct technical relationship name rather than the display label prevents the silent misconfiguration where the permission appears configured but does not correctly identify matching records because the relationship name does not resolve. Associating the configured table permission with the appropriate web role that the portal assigns to authenticated users completes the permission configuration and makes it active for users holding that role. Testing the contact scope configuration by authenticating as different portal users and verifying that each user sees only their own records, and that no user can access records belonging to other users by manipulating URL parameters or query strings, validates that the security implementation correctly enforces the intended access boundaries.
Account Scope for Organizations
Account scope table permissions extend record visibility beyond individual users to encompass all portal users associated with the same parent account, enabling the business-to-business portal scenario where multiple contacts from the same customer organization need shared visibility into records that belong to their organization rather than to any individual. A procurement portal where all purchasing staff from a customer company need to see all purchase orders submitted by anyone in their organization, a warranty portal where any authorized technician from a service company can access service records for all equipment owned by that company, and a partner portal where all users from a reseller partner need to see the shared pipeline and deal registration records for their organization are all examples where account scope provides the correct access boundaries.
Implementing account scope requires that the portal users being served have a parent account relationship established on their contact records, which is the standard Dataverse data model for business contacts associated with account records. The table being listed must have a relationship to the Account table that the account scope permission can reference, either directly through a lookup field on the table that references Account or indirectly through a relationship chain that the permission configuration traverses to determine which records are associated with the current user’s parent account. When a portal user with account scope permissions accesses an entity list, the portal evaluates the permission by finding the user’s contact record, retrieving the parent account associated with that contact, and filtering the entity list to display only records related to that account through the specified relationship. Combining account scope with contact scope through multiple table permissions assigned to the same web role enables mixed visibility scenarios where users see both their personally owned records and shared organizational records in the same entity list, with the portal combining the results of both permission scopes to produce the complete set of accessible records.
Self Scope for Profile Records
Self scope is a specialized table permission scope designed specifically for scenarios where the portal user needs to access or modify their own contact record or a record that directly represents their identity in the system, such as profile settings, notification preferences, or account configuration data stored on the Contact table itself. Without self scope permission for the Contact table, portal users cannot read or update their own contact information through portal forms, which would prevent standard portal functionality like profile editing, address management, and communication preference updates that are expected features of most self-service portals.
Configuring self scope for the Contact table requires creating a table permission with the Contact table selected, choosing the Self scope option, and assigning the Read and Write privileges that allow portal users to view and modify their own contact records. The self scope permission is unique in that it does not require a relationship field specification because the relationship is implicitly the portal user’s own contact record, which the portal identifies directly from the authenticated session. Restricting what columns of the contact record are exposed to self scope operations is accomplished through the column security profiles and field-level security settings in Dataverse rather than through the table permission configuration, ensuring that sensitive internal fields like credit ratings, internal notes, and system integration fields are not modifiable by the portal user even when self scope write access is granted. Testing self scope configuration requires verifying that an authenticated portal user can view and edit their own contact information and cannot view or modify the contact records of other portal users, which validates both the positive access case and the security boundary enforcement.
Using Web Roles Effectively
Web roles are the mechanism through which table permissions are assigned to categories of portal users, functioning as the portal-layer equivalent of Dataverse security roles that group permissions and assign them to users based on their classification within the portal’s user population. Every Power Apps Portal has at least two built-in web roles that every portal implementation must understand: the Authenticated Users role that is automatically assigned to all users who have successfully authenticated to the portal regardless of any additional profile or account characteristics, and the Anonymous Users role that applies to all visitors who have not authenticated. Table permissions assigned to the Authenticated Users role apply uniformly to all logged-in portal users, making this role appropriate for permissions that should apply to everyone who is authenticated without regard to their specific account, subscription, or organizational characteristics.
Custom web roles beyond the built-in roles enable the differentiated access control scenarios where different categories of authenticated users should have different record visibility and action permissions. A portal serving both customers and partners might define separate Customer and Partner web roles with different table permissions that reflect the different data access appropriate for each relationship type. A portal with tiered subscription levels might define Bronze, Silver, and Gold web roles with progressively broader record access reflecting the expanded capabilities available at higher subscription tiers. Assigning web roles to portal users is accomplished through the portal contact record where the web roles associated with each contact are managed, and this assignment can be performed manually through the Portal Management app, automatically through Power Automate flows triggered by registration or profile completion events, or conditionally through portal business rules that evaluate contact attributes and assign appropriate roles based on the evaluation results.
Filtering Records With FetchXML
FetchXML filters applied directly to entity list configurations provide an additional mechanism for controlling which records appear in a list that complements table permissions by expressing conditions based on record field values, date ranges, related record states, and other data-driven criteria that table permissions cannot express through their scope and relationship model. FetchXML is the XML-based query language used natively by Dataverse that supports filtering, sorting, aggregation, and related entity joins, and embedding FetchXML filter conditions in an entity list configuration causes those conditions to be appended to the query that retrieves records for the list, narrowing the result set to records that satisfy both the table permission scope and the explicit field value conditions.
Implementing FetchXML filters on an entity list requires editing the entity list configuration in the Portal Management app and entering valid FetchXML filter XML in the Filter field. A filter that restricts the list to active records only would include a condition element checking that the statecode field equals zero, while a filter that restricts the list to records created within the last thirty days would include a condition using the last-x-days operator. Combining multiple conditions using and and or logical operators within the filter XML enables complex filtering logic that enforces business rules specific to the list’s use case. Dynamic FetchXML filters that reference the current portal user’s contact ID or account ID through substitution parameters enable record filtering based on the authenticated user’s identity even when table permissions alone would not achieve the exact filtering behavior required, providing an additional layer of targeted data restriction for cases where the standard scope options do not precisely match the business requirement.
Testing Record Level Security
Thorough testing of record-level security implementation is non-negotiable for any portal that handles sensitive data, and testing must verify not only that each user sees the records they should see but also that no user can access records they should not see through any available access path including direct URL manipulation, browser cache exploitation, and API endpoint probing. Creating a structured test plan that defines specific test cases for each configured permission scope and web role combination, documents the expected records visible to each test user, and verifies the results through actual portal sessions provides the evidence that security is implemented correctly and the documentation that supports compliance and audit requirements.
Positive test cases that authenticate as specific portal users with known record ownership and relationship configurations verify that the expected records appear in entity lists and that appropriate action buttons are visible for records within the user’s permission scope. Negative test cases that attempt to access records belonging to other users by navigating directly to detail page URLs that reference other users’ record IDs verify that the portal enforces access boundaries even when the portal user constructs a direct URL rather than navigating through the entity list. Testing with users assigned to each distinct web role configured in the portal verifies that role-based permission differentiation works as designed and that role assignment changes are reflected immediately in subsequent portal sessions. Automated security testing using tools that systematically probe portal endpoints with requests that should be denied provides more comprehensive coverage than manual testing alone and should be incorporated into the deployment validation process for portals handling personally identifiable information, financial data, or other sensitive record types that carry regulatory compliance implications.
Handling Multi-Table Relationships
Real-world portal implementations frequently need to display records from tables with complex relationship structures where the records to be shown are not directly related to the current user’s contact record but are accessible through a chain of relationships that must all be traversed to establish the connection between the user’s identity and the appropriate records. A portal that displays invoice line items to the customer who placed the order requires navigating from the current user’s contact to their account, from the account to orders associated with that account, and from orders to the line items associated with those orders, a three-hop relationship chain that requires careful configuration to implement correctly with table permissions.
Parental table permissions that establish a chain of permissions across related tables allow this multi-level relationship navigation to be implemented securely by defining permissions at each level of the hierarchy and linking them through parent permission references. A Contact scope permission on the Order table establishes that users can access orders related to their contact record, and a parental permission on the Order Product table that references the Order permission as its parent establishes that users can access order product records for the orders they can already access. This parent-child permission chain allows the portal to traverse the relationship hierarchy and correctly identify which order product records are accessible to each user without requiring a direct relationship between Order Product and Contact. Testing multi-level permission chains requires verifying that records accessible through each step in the chain are correctly visible and that records accessible only through relationships belonging to other users are correctly hidden, with particular attention to the boundary cases where a user has access to some parent records but not others and the portal correctly segments the child record visibility accordingly.
Performance Considerations for Security
Record-level security evaluation adds computational overhead to entity list data retrieval because the portal must evaluate permission scopes, traverse relationships, and filter records against the current user’s identity context for every list rendering, and this overhead can significantly impact portal page load performance when entity lists contain large numbers of records or when permission evaluation requires complex relationship traversal. Understanding the performance implications of different security configurations and designing accordingly ensures that security requirements are met without degrading the user experience to an unacceptable degree for portal users who expect responsive page loads comparable to what they experience on other web applications.
Entity list configurations that enable server-side pagination limit the number of records retrieved and rendered on each page load, which bounds the performance impact of permission evaluation to the page size rather than the total result set size regardless of how many records pass the permission filter. Setting a page size appropriate for the use case, typically between ten and fifty records for most portal lists, ensures that even entity lists browsing large record sets load quickly by retrieving only the current page worth of records at a time. Optimizing the Dataverse view used as the data source for the entity list to include only the columns displayed in the list reduces the data transfer volume between Dataverse and the portal rendering engine, which improves performance particularly for lists with many records. Creating appropriate Dataverse indexes on the relationship fields used in table permission scope evaluation improves the efficiency of the database queries that the portal generates when evaluating permissions, reducing query execution time for permission evaluation against large tables where unindexed relationship lookups would result in full table scans.
Troubleshooting Common Security Issues
Despite careful configuration, record-level security implementations on Power Apps Portals entity lists frequently encounter issues that require systematic troubleshooting to diagnose and resolve, and familiarity with the common failure patterns and their causes significantly reduces the time required to diagnose and correct security configuration problems. The most frequent issue is entity lists that display no records to authenticated users who should see data, which is most commonly caused by missing table permission configuration, table permissions not associated with the appropriate web role, or the Enable Table Permissions toggle not being activated on the entity list itself. Checking each of these configuration elements in sequence eliminates the most common causes efficiently before investigating more obscure configuration issues.
Entity lists that display all records rather than filtering to the current user’s permitted records indicate that table permissions are not being enforced, which occurs when the Enable Table Permissions setting is disabled or when the table permission is configured with Global scope when Contact or Account scope was intended. Entity lists that display an error message rather than records or blank space often indicate a configuration error in the table permission relationship name that causes the permission evaluation to fail rather than silently return empty results, and reviewing the exact relationship schema name in Dataverse and comparing it against the relationship name specified in the table permission configuration typically reveals the mismatch. Portal diagnostic mode, enabled by appending a diagnostic parameter to the portal URL, provides detailed rendering and security evaluation information that reveals which permissions were evaluated, which records were included or excluded by permission filtering, and what errors occurred during evaluation, making it the most powerful available tool for diagnosing complex permission configuration issues that are not immediately apparent from the visible portal behavior.
Conclusion
Power Apps Portals entity lists with record-level security represent one of the most important and frequently used capabilities in the portal development toolkit, enabling the secure, user-specific data presentation that is the foundation of every meaningful self-service portal experience. The combination of Dataverse table permissions that define access scopes and privileges with portal entity list security settings that enforce those permissions on displayed records creates a layered security architecture that provides both flexibility to address diverse business requirements and depth to resist the access boundary violations that inadequate security configuration would allow.
The investment in understanding and correctly implementing record-level security for entity lists pays dividends throughout the portal lifecycle by preventing the security incidents and data exposure events that result from misconfigured or absent access controls, by building user trust through consistent and correct data presentation that shows each user exactly what they should see, and by establishing the secure foundation on which additional portal features and data integrations can be built with confidence that the security model will correctly govern access as capabilities expand.
The technical concepts covered throughout this guide, from the foundational Dataverse security model and table permission scopes through web role configuration, FetchXML filtering, multi-table relationship handling, and performance optimization, represent the knowledge that distinguishes portal developers who can confidently design and implement security for complex real-world portals from those whose portal security implementations work only for the simplest single-user single-table scenarios. Developing genuine proficiency with all of these concepts requires hands-on practice across a variety of portal configurations, deliberate attention to edge cases and boundary conditions during testing, and willingness to engage deeply with the Portal Management app configuration and the Dataverse security model that underlies it.
As Power Pages continues to evolve with new security capabilities, improved administration tooling, and enhanced performance characteristics, the foundational principles of record-level security covered here will remain relevant because they reflect the enduring requirements of portal applications to present the right data to each user and to protect sensitive records from unauthorized access. Building on this foundation with attention to the platform updates that Microsoft releases regularly will enable portal developers to take advantage of new capabilities as they become available while maintaining the security posture that organizations and their portal users depend upon.