Copilot Studio Memory: What Persists Between Conversations

Copilot Studio does not have a single "memory" feature — it has several storage types that work at different scopes. Conversation variables hold values within a single session and reset when the conversation ends. Global variables persist across conversation branches within a session. Durable storage — Dataverse tables, SharePoint lists, or external systems reached through Power Automate — persists between sessions. Tools like fenbs fill a different need: holding approved project rules and handoff notes for agent sessions that need a consistent brief across conversations.

This guide covers each storage type, what resets when a conversation ends, and how to choose the right approach for your use case.

How memory works in Copilot Studio

In Copilot Studio, information is stored in variables. A variable can hold a text value, a number, a Boolean (true/false), or a table of records. Variables have a scope: conversation scope means the value is available anywhere in the current conversation but wiped at session end; global scope means the value persists for the duration of the conversation and is accessible across topics within it.

Neither scope type writes to a database automatically. If you want information to survive beyond the current session, you must explicitly write it to durable storage — Dataverse, a SharePoint list, or an external API — using a Power Automate cloud flow or a Copilot Studio connector.

Conversation variables

Conversation-scoped variables are the default. They are created inside a topic, hold a value for the duration of that conversation, and are cleared when the session ends. They are ideal for collecting user input during a session — a name, a case number, a preference — and passing it between topics within the same conversation.

Use conversation variables for: form-style data collection across multiple topics, tracking which path a user took through a dialog, temporarily holding an API response while the bot decides what to do next. Do not use them for anything you need to read in a future conversation, because they will not be there.

Global variables

Global variables in Copilot Studio are accessible from any topic in the bot, not just the topic where they were set. They still reset at session end — "global" means global within the conversation, not global across conversations. Use them when a value set early in a session (a user's role, an authenticated identity, a session flag) needs to be readable from multiple topics later in the same conversation.

Durable storage with Dataverse and Power Automate

For information that must survive the end of a conversation, write it to a durable store during the session. Dataverse is Microsoft's purpose-built data platform for Power Platform apps and integrates natively with Copilot Studio. You can call a Power Automate flow to read or write a Dataverse table, a SharePoint list, or an external API at any point in a topic.

• Session summary: at the end of a conversation, call a Power Automate flow to write a case record to Dataverse with the session outcome and next step.
• User preferences: read a Dataverse record at the start of the session to restore a returning user's preferences.
• Case history: write each resolved step to a SharePoint list so agents or people can see what was already tried.
• External lookup: call a REST API via Power Automate to fetch a customer record or a work item at session start.

For current limits on Dataverse row storage and API call volumes in Power Automate, check the Microsoft Power Platform documentation — these vary by license.

What resets at conversation end

When a Copilot Studio conversation ends, all conversation-scoped and global variables are cleared. The system topics reset to their initial state. Anything not explicitly written to durable storage during the session is gone. This is the most common source of confusion: a bot that works well in testing seems to "forget" everything when a real user returns the next day.

The practical fix is an explicit save step at the end of each conversation for anything you want to persist. Build it as a topic that runs before session end and writes the outcome to your chosen store. Test it by ending the conversation and starting a new one to confirm the record is there.

How to use Copilot Studio memory with fenbs

Use Copilot Studio's variables and Dataverse for session and operational data. Use fenbs for the reviewed project context that should be consistent across every agent session.

1. Create a free account at fenbs and add a project for the work your Copilot Studio agent supports.
2. Write the standing rules and key decisions in Decisions and rules: what the agent should always say, what it should escalate, and any policy constraints.
3. Copy the current project context from fenbs and paste it into the agent's system topic instructions or a dedicated opening topic.
4. When the agent completes a significant workflow, use Power Automate to write the outcome back to your durable store, and update the fenbs task status manually.
5. Review and update the fenbs context when project rules change, so the agent's system instructions stay current.

For a broader view of memory in AI agents, what is agent memory explains the different types. For the Copilot Studio platform itself, Copilot Studio covers how to set up and deploy agents.

When Copilot Studio memory alone is enough

If your Copilot Studio bot handles self-contained support flows — a user asks a question, gets an answer, and leaves — in-session variables are sufficient. Durable storage becomes necessary when you need case continuity, returning user recognition, or audit logs. A shared project brief in fenbs adds value only when the agent's behavior needs to reflect approved decisions that change over time and need to be reviewed by a person before they affect the bot.