Drag and Drop Question A company implements Dynamics 365 Finance. You must prevent users from viewing vendors based on vendor group. You need to create an Extensible Data Security (XDS) policy to…

Question

Exhibit

Answer Area

Explanation

XDS Policy Creation Order - Explained

The Correct Sequence and Why

Step 1: Create a policy query for the primary table

Why first: The policy query is the foundation of the entire XDS policy. It defines the data source (here: VendTable) and the filter logic that determines which records a user can see. You must build this query object in the Application Object Tree (AOT) before anything else, because the security policy object will reference it during creation. You cannot reference something that doesn't exist yet.

Technical detail: This is a standard AOT Query object. It establishes the primary table (e.g., VendTable) and the join/range conditions that will be injected as a WHERE clause at runtime when users query vendor data.

Step 2: Create a security policy

Why second: Now that the query exists, you can create the SecurityPolicy object and bind it to that query. During creation you set key properties: the policy name, the associated policy query (from Step 1), the operation type (Select/All), and whether the policy is enabled.

Technical detail: The security policy is the container that the runtime uses to apply restrictions. Without it, the query has no enforcement mechanism. You need the query to exist first so you can assign it here.

Step 3: Add a constant table to the security policy

Why third: After the policy exists, you configure which tables it protects by adding them. In XDS terminology:

• A constrained table = the table being secured (records get filtered)
• A constant table = a reference table providing the filtering context (e.g., a user-to-vendor-group mapping table)

You add the constant table to give the policy its decision-making data - in this case, which vendor groups a user is permitted to see.

Common misconception: People confuse "constant table" with "constrained table." The constant table is NOT the table being hidden; it's the lookup table that drives the filter logic.

Step 4: Build and sync the XDS policy

Why last: This compiles the policy objects and synchronizes them to the database. Until this step, the policy exists in metadata only - it has no runtime effect. Build = compile the AOT objects; Sync = push the schema/policy to the SQL layer so it is enforced on live queries.

Common mistake: Skipping or doing this step before configuring all tables. If you sync before adding the constant table (Step 3), the policy is incomplete and may not filter correctly, or you must rebuild and sync again.

Summary Table

The pattern is: define the filter logic → create the enforcement container → configure the filter criteria → activate. Each step depends on the previous one existing before it can proceed.

No community discussion yet for this question.