AB-400: Designing Security and Dataverse Data Boundaries

Introduction

Designing security and Dataverse data boundaries starts with four decisions: identify the principal that actually performs each operation, define which data that principal may access, choose a table model that can enforce the required behavior, and confirm that environment governance permits the complete data path. Make these decisions before choosing a convenient connector or adding a custom interface. A successful sign-in establishes identity; it does not establish permission to every record or external system.

Use the framework in that order, then revisit earlier decisions whenever an integration changes identity or moves data. The outcome should be an explicit access contract for each operation, rather than a diagram in which every component simply connects to Dataverse. This guide addresses design choices for Microsoft Power Platform online services documented on October 15, 2026. Authentication code and synchronization implementation are separate tasks.

Architecture Overview: Trace One Operation End to End

A useful architecture record describes one business action as a sequence of trust boundaries. For example, a regional dispatcher reads a service request, checks an external asset register, and asks a background process to create a follow-up task. Treat the request read, asset lookup and task creation as separate operations even if the interface presents one button.

For each operation, record the following design evidence:

This is a recommended design record, not a Microsoft configuration object. Its value is that a reviewer can trace a requirement to an enforcement point and a test. If no component owns a required check, the check is still missing.

Core Components and Their Security Boundaries

Identity Establishes the Caller

Microsoft Entra ID is the identity provider for Dataverse OAuth authentication. A client acting for an authenticated user and a noninteractive application connecting as a Dataverse application user represent different execution identities. The latter is bound to a registered application; it is not automatically the person who initiated a business process.

Choose between these identities according to whose authority the operation requires. For an interactive read, preserving the user's identity makes the access decision align with that user. A scheduled workload needs an independently defined permission boundary. Do not give it administrator access simply to remove development friction. When a user-facing service invokes a more privileged workload, specify how the service verifies the user's right to request that particular operation before the workload acts. Token acquisition alone does not supply that business authorization.

Ownership Determines Record Scope

Dataverse security roles group privileges and can be assigned through users or teams. Grants are cumulative: a narrower role cannot cancel a broader grant. Business units help define access boundaries through role scope; they need not copy the organizational chart.

For ownership-based tables, organization ownership gives an all-records-or-no-records privilege boundary. User or team ownership supports finer access levels. Choose ownership when creating the table; it cannot later be changed. Owner teams can own records. Access teams cannot own records or hold security roles; they receive access through sharing. Use record sharing for exceptions rather than as the default access model.

As a design recommendation, express access first in business terms: “regional dispatchers update their region's active requests; a temporary specialist reads this request.” Then map recurring access to roles, business units and ownership, and exceptional access to sharing. Review every grant together. A test account with an unrelated broad role can make an otherwise incomplete design look correct.

Choose the Data Model Before Promising Behavior

Table choice is part of the security contract because ownership and supported operations vary. Begin with required behavior rather than expected row count alone.

Standard Tables for Transactional Business Records

Microsoft recommends standard tables when an application needs strong consistency, relational modeling, transactions across tables and plug-in execution stages, or complex joins. They are a sensible starting point for a service-request system whose accepted changes must remain consistent with related business records.

Write down the invariant before choosing storage. In the example, suppose an approved request must always have a corresponding assignment. That requirement is different from “the app displays assignments quickly.” A design review must determine which operation guarantees the invariant and what happens on failure. Selecting a familiar interface or an apparently faster table does not answer that question.

Virtual Tables for Externally Owned Data

Virtual tables represent external records in Dataverse without storing a replicated physical table there. A provider retrieves data at runtime, so provider behavior and external availability remain part of the application contract. The documented model supports organization-owned tables, not user-owned security filtering, and does not support field-level security. It also has limitations such as no Dataverse auditing or offline caching.

Consequently, do not assume that exposing an external asset register as a virtual table creates the same regional row boundary as a locally owned service request. Establish how the provider and external system restrict the data they return, under which credentials, and for which callers. If the proposed path exposes more assets than the dispatcher may see, reject that path until it has an enforceable access design. Avoid using a view filter as evidence of external authorization.

Choose a virtual table when a table-shaped representation is useful and its documented capabilities fit. Choose a connector-based operation when the reader needs an explicit external action rather than a local-looking record model. Neither choice removes the need to verify destination permissions.

Elastic Tables for High-Volume Data with Different Guarantees

Elastic tables are Dataverse-managed tables powered by Azure Cosmos DB, intended for high-volume workloads. They support ownership and field-level security, but their feature set differs from standard tables. They do not support multi-record transactions, and strong consistency is limited to a logical session. A synchronous PostOperation plug-in failure does not roll back an already created elastic-table record. Automatic removal through time to live is available; alternate keys and access teams are among the unsupported features.

For the example, a separate stream of disposable device observations may justify evaluating an elastic table. That does not justify moving request approval there. Keep the observation-retention decision independent of the request-consistency decision. Before adopting it, verify that the required query patterns, ownership model and recovery behavior fit. Treat automatic deletion as a deliberate retention policy, not an incidental performance switch.

How Connectors and Governance Complete the Boundary

A connector describes operations; a connection carries saved credentials in its hosting environment. Thus, selecting a connector does not by itself tell you which person or workload will access the destination. Record the connection identity alongside the operation it enables. In a review, ask what changes when a dispatcher leaves, a credential is replaced, or the destination revokes access.

Power Platform data policies can restrict connectors and actions at design time and affect existing apps, flows and agents at runtime. Policy changes propagate through the platform; enforcement is not necessarily immediate. A dependency that was usable yesterday can become a runtime failure after a policy change. Coordinate policy changes with owners of the affected resources and retest the actual path after enforcement has taken effect.

Managed Environments provide premium governance capabilities, including controls around sharing, data policies and operational insight. They are an environment-management layer, not a substitute for a Dataverse permission design. Confirm applicable entitlements and enabled controls with the administrator before relying on them. Merely drawing an environment boundary does not describe the permissions of an external asset connection.

For an external API, agree on the smallest useful business contract. A “check asset eligibility” operation may need only an identifier and an eligibility result. Returning an entire customer profile because it is easy to retrieve creates an unnecessary exposure in the example. This payload-minimization recommendation applies even when both authentication and connector policy allow the call.

Apply the Framework to a Regional Service Extension

Consider this original design exercise: two regional teams manage service requests; occasional specialists assist across regions; a central asset system remains authoritative; device observations expire after their operational use. No implementation or tenant test is claimed here.

The proposed design assigns each requirement a separate decision:

1. Keep request and assignment business records in standard tables because the scenario requires coordinated business changes. Define which record transitions must succeed together before writing extension logic.
2. Use user or team ownership for requests and design recurring regional access through the chosen role and business-unit model. Identify the team responsible for unassigned requests instead of leaving that responsibility implicit.
3. Treat specialist access as a bounded exception with an owner and end condition. Include removal of exceptional access in the operational process.
4. Evaluate the asset interface independently. Accept a virtual-table design only after proving the external access boundary; otherwise specify a constrained connector operation that returns the business result required by the dispatcher.
5. Evaluate elastic storage only for the observation workload. Decide how long observations remain useful and how the application behaves when an observation is no longer available.
6. Review the actual connections and environment controls with the administrator. Do this before committing the interface to an external dependency.

These are scenario-specific recommendations. A different requirement, such as organization-wide request visibility or offline asset access, can change the decision. Preserve the reasoning with the design so later changes can be assessed against it.

Design Considerations: Prove Allowed and Denied Access

Use an isolated development environment, authorized test identities and synthetic records for validation. Obtain permission before changing security roles, sharing or environment policies; those changes can affect other users and running resources.

For the regional example, the acceptance evidence should include a dispatcher updating an allowed request and being denied a request outside the intended scope. Test a specialist before access is granted, during the exception and after removal. Inspect effective privileges if an expected denial succeeds; do not conclude that the application bypassed security before checking broader grants.

Exercise the external operation with a valid caller who lacks the required business permission. Authentication success must not turn that request into permission to inspect unrelated assets. Separately simulate an unavailable destination or disabled connection: the interface should explain that the lookup failed rather than present an empty response as “no eligible asset.” These are proposed acceptance criteria, not reported product output.

After testing, remove synthetic data and temporary access grants, restore any deliberately changed development policies, and retire test connections or credentials no longer required. Retain the access matrix and test evidence without credentials or sensitive record contents. A repeatable design review should depend on documented authority, not on keeping a privileged test account active.

Common Mistakes

The most costly mistakes occur when one boundary is used as proof of another: a successful token is treated as record permission, an app's availability is treated as permission to its data, or a connector's presence is treated as approval to send a full payload. Another mistake is choosing a virtual or elastic table first and discovering later that the required ownership or transaction behavior is unavailable.

Resolve these by returning to the operation record. Identify the acting principal, expected data scope, enforcement point and observable denial. If the design cannot explain those four items for a call, adding more code will make the uncertainty harder to diagnose.

Certification Relevance

Within Build Microsoft Power Platform solutions, this framework turns security and data choices into architecture constraints. Practice explaining why a requirement changes the principal, ownership model, table type or permitted connection. The useful skill is defending a coherent design under a changed requirement, rather than memorizing a list of security features.

Conclusion

A sound Power Platform extension has an access contract for each operation. Choose identity and data scope deliberately, reject table models that cannot preserve required behavior, and review the complete connection path against environment governance. Validate the denials as carefully as the successful actions; those failures reveal whether the proposed boundaries actually hold.

Authoritative Sources

• AB-400 study guide
• Use OAuth authentication with Microsoft Dataverse
• Ownership-based security in Microsoft Dataverse
• Data policies
• Managed environments overview
• Get started with virtual tables
• Create and edit elastic tables

Related Reading

• AB-400: Dataverse API Clients and OAuth Authentication
• AB-400: Dataverse MCP and Work IQ Access for Agents