A healthcare organization is deploying a Copilot Studio agent that accesses patient records stored in Dataverse. The agent must read patient demographic data but must not be able to create, update, or delete any records. Different departments will use the same agent, but clinical staff should see full demographic records while administrative staff should see only name and contact information. Which Dataverse configuration approach correctly enforces both requirements?

Dataverse security in Copilot Studio deployments involves two distinct layers: table-level access controlled by security roles, and column-level access controlled by column security profiles. Both layers must be configured to meet the requirements in this scenario. The correct approach is to assign the agent's application user a security role with only Read privilege on the Patient table, create two column-level security profiles — one granting access to all demographic columns for clinical staff, and one restricting access to only Name and ContactInfo columns for administrative staff — and assign each profile to the corresponding Azure AD group. This addresses both security requirements explicitly. The Read-only role prevents the agent from creating, updating, or deleting records at the table level. Column-level security profiles then implement field-level access differences between clinical and administrative staff. Clinical staff are assigned a profile that grants access to all demographic columns, while administrative staff receive a profile that restricts access to only Name and ContactInfo. Assigning these profiles to Azure AD groups makes the access determination automatic based on group membership. The approach that creates a single security role for the agent application user with Read privilege on the Patient table and uses topic-level conditions in the agent to show or hide fields based on the user's department property is incorrect because topic-level conditions are a UI-layer control, not a data-layer security control. This means administrative staff could still retrieve full records through other means, such as API calls or Power Apps, and it does not enforce data security at the Dataverse level. Security requirements must always be enforced at the data layer, not the presentation layer. The approach that configures the agent's application user with Read-only privileges on the Patient table and uses Dataverse column-level security profiles to restrict which columns administrative staff can read is incorrect because it describes column-level security profiles restricting the columns for administrative staff but does not specify the creation of separate profiles for clinical staff with full access. It also implies a single configuration rather than two separate profiles, which is insufficient to give clinical staff full access while restricting administrative staff. The approach that creates a custom security role with Read privilege only on the Patient table assigned to the agent's application user, creates separate column security profiles restricting Name and ContactInfo columns for the AdminStaff security group, and assigns clinical staff to an unrestricted profile is incorrect because it frames the configuration backward. Restricting specific columns in a profile only makes sense when paired with a complementary unrestricted profile for clinical staff explicitly granting all demographic columns. The wording also incorrectly conflates the Dataverse security group with the column security profile assignment, which are separate constructs. Exam tip: Remember the two layers of Dataverse security for agents — security roles control table-level CRUD privileges, and column security profiles control field-level read/write access. An agent's application user is always the identity that the security role is assigned to. End-user field visibility is controlled by column security profiles assigned to Azure AD groups or Dataverse teams, not by the agent's role.