Dataverse Integration

Overview

Your Copilot Studio agent can carry on a conversation. But the conversations that create real value for government users are the ones that look up records, update statuses, and save inputs to a system of record. That requires data.

Dataverse is the native data platform for Power Platform and for Copilot Studio. It is a managed relational data store with built-in security, auditing, and compliance features that run within your government cloud boundary. This video walks you through connecting your agent to Dataverse tables—reading data, writing data, and using Dataverse as a configuration store.

What You’ll Learn

• Why Dataverse: How it fits as the natural data layer for Copilot Studio agents
• Reading data: Querying Dataverse tables with filtering and column selection
• Writing data: Creating and updating rows with validation and compliance
• Configuration tables: Changing agent behavior without republishing

Script

Hook: Your agent needs data

Your agent can hold a conversation. It can answer questions, guide users through processes, and even look up information from knowledge sources. But conversations that look up specific records, update a case status, or save user inputs into a system of record—those require structured data.

Dataverse is the native data platform for Power Platform and for Copilot Studio. It is not an add-on or an afterthought. It is built in.

In the next ten minutes, you will connect your agent to Dataverse tables and build real data-driven interactions that work within your government cloud boundary.

What Dataverse is and why integrate

Dataverse is a managed relational data store built into Power Platform. If you have worked with databases before, the concepts are familiar: tables, columns, rows, and relationships. Dataverse comes included with Copilot Studio and Power Apps licenses, so there is no separate service to provision.

Why is Dataverse the right choice for your agent? First, it has native integration with Copilot Studio. You do not need to build a custom connector—the Dataverse connector is built in and available as a standard action. Second, security is built in at multiple levels: row-level security controls which records a user can see, column-level security restricts access to sensitive fields, and role-based access control determines what operations a user can perform. Third, it works within your government cloud boundary. In GCC, GCC High, and DoD, Dataverse data stays within the authorized environment.

The most common patterns for agents with Dataverse are knowledge base tables where FAQ entries and policy lookups are stored as rows; case management where the agent reads case status, creates new records, and updates fields; agent configuration where feature flags, prompt templates, and response text live in tables that can be changed without republishing the agent; and user preferences and session history that persist across conversations.

Dataverse is the right choice when you have structured data that needs relationships and security, when data is shared across multiple agents or Power Platform applications, and when you need built-in auditing and compliance features for government requirements.

Reading data from Dataverse tables

To read from Dataverse in your agent, add a “Call an action” node to your topic and select the Dataverse connector. The two operations you will use most are List rows and Get a row by ID.

List rows returns multiple records from a table. Select the table name, then apply OData filter expressions to narrow the results. For example, to find open cases assigned to the current user, your filter might be: statuscode eq 1 and _ownerid_value eq the user’s ID. Always limit the number of returned rows to keep agent responses manageable—returning 500 records into a chat message helps no one. Set a reasonable top count, such as 5 or 10.

Get a row by ID retrieves a single record using its unique identifier—either a GUID or an alternate key. This is the operation you use when the user provides a specific case number, employee ID, or reference number. Select specific columns to return only what the agent needs. Returning every column from a 40-column table wastes resources and may expose data the user does not need to see.

Once the Dataverse action returns data, map the output columns to topic variables. Display the data in message nodes with formatted text—for example, “Case CS-2024-00145 is currently Open, assigned to Maria Torres, last updated February 3.” Use data in condition nodes to branch the conversation—if the case status is “Closed,” offer to create a new case instead of updating the existing one.

Government data considerations matter here. Dataverse enforces row-level security, so the connection user only sees records they are authorized to access. Use per-user connections so queries respect each individual user’s access level. Avoid returning sensitive columns—like Social Security numbers or classified data markers—unless the conversation context specifically requires them.

Here is a practical government scenario. You build an agent for benefits inquiries. The user provides their employee ID. The agent queries a Dataverse table for that employee’s enrollment status, plan details, and next action date. The agent displays a summary: “You are enrolled in Plan B, effective since January 2025. Your next open enrollment window opens November 2026.” The agent then offers next steps—update beneficiaries, request a plan change, or speak with an HR representative.

Writing data back to Dataverse

Reading data is half the story. Your agent can also create and update records.

To create a new row, use the “Add a new row” action. Specify the target table and map topic variables to column values. For example, a support request agent collects the user’s description of an issue, the affected system, and the urgency level through question nodes. The action then creates a new row in the SupportRequests table with those values, along with the current date and the user’s identity.

To update an existing row, use the “Update a row” action with the row’s GUID. You update specific columns without overwriting the entire record. For example, after your agent triages a support request and determines the category, it updates the case status from “Open” to “In Progress” and sets the category field.

Deleting rows is available, but use it with extreme caution in agents. In government environments, audit requirements often mandate data retention. Prefer soft deletes—updating a status column to “Inactive” or “Archived”—over hard deletes that remove the record permanently.

Validate user inputs in your topic before passing them to Dataverse. Check that required fields are filled, data formats are correct, and business rules are satisfied. If validation fails, return a clear error message: “Please provide a description of your issue. I need this to create your support request.”

Be aware of transaction considerations. Dataverse operations from Copilot Studio are individual—there are no multi-row transactions. If you need to create a parent record and multiple child records atomically, use a Power Automate flow to wrap the operations in a single transaction.

For government compliance, know that all Dataverse operations are logged in the audit trail. Write operations should follow your agency’s data modification policies. Ensure the agent’s service account or user connection has the minimal write permissions necessary—do not grant full system administrator access to an agent connection.

Using Dataverse for agent configuration

One of the most powerful patterns with Dataverse is using it as a configuration store for your agent. Instead of hardcoding greetings, error messages, routing rules, or feature flags in your topic nodes, store them in a Dataverse table. This lets you change agent behavior without republishing the agent.

Here are three configuration table patterns. A response text table stores greeting messages, error messages, and help text as rows. When you need to update the agent’s welcome message, edit the row in Dataverse—the agent picks up the change on the next session. A feature flag table enables or disables agent capabilities per environment or user group. Rolling out a new feature to a pilot group? Set the flag to “enabled” for that group and “disabled” for everyone else. A prompt template table stores and versions the prompt text used in generative answers, letting you iterate on prompts without touching the agent’s authoring canvas.

To implement this, create a custom Dataverse table with columns for the configuration key, value, and any grouping fields you need. In your agent topic, query the configuration table at the start of the conversation—typically in a greeting or system topic. Store the returned values in global variables so they are available throughout the entire session.

For performance, query configuration once per session, not on every message. Global variables persist for the duration of the session, so a single read is enough. Most configuration changes do not need real-time updates—a user starting a new session will pick up the latest values.

Here is a government use case. You build a multi-agency agent that serves users from several departments. A configuration table maps each user’s agency to specific greeting text, routing rules, and available services. When a new agency onboards, you add rows to the configuration table. No code changes, no republish, no downtime.

Close: Building data-driven agents

Here is what you learned. Dataverse is the native data platform for Copilot Studio agents, with built-in security, auditing, and government cloud compliance. Read operations use List rows with OData filters and Get row by ID with column selection to retrieve exactly the data your agent needs. Write operations create and update rows with proper validation, and you should prefer soft deletes over hard deletes in government contexts. Configuration tables let you change greetings, feature flags, and prompt templates without touching the agent’s authoring canvas.

Security runs through everything. Row-level and column-level security enforce access control on every query. Per-user connections respect individual permissions. All operations—reads and writes—are audited for compliance.

Four best practices to follow. Return only the columns your agent needs—avoid returning entire rows when you need two fields. Validate inputs in your topic before writing to Dataverse. Use Power Automate for complex multi-step data operations that need transaction support. Store configuration in Dataverse tables, not hardcoded in topics.

Three things to do next. Create a Dataverse table for a simple use case—an FAQ lookup or an agent configuration table. Build an agent topic that reads from the table and displays results to the user. Then add a write operation—let the user submit a request that creates a new Dataverse row.

Dataverse gives your agent a memory and a purpose. Read data, write data, and let configuration tables keep your agent flexible without redeployment.

Sources & References

• Use connectors in Copilot Studio — Documentation on using the Dataverse connector and other connectors as actions in agents
• Microsoft Dataverse documentation — Tables, columns, relationships, security, and data management in Dataverse
• Copilot Studio documentation — Main documentation hub for agent building, topics, and platform capabilities
• Dataverse security model — Row-level security, column-level security, and role-based access control