Dynamics 365 Timeline Extraction with Power Automate & Copilot Studio
Copilot Studio · Dataverse · Power Automate · Dynamics 365 · SharePoint
✅ Complete
There are gaps in every platform. Most of them are small — a missing filter option, a report that doesn’t quite do what you need. You work around them and eventually stop noticing they’re there. But occasionally you hit something that genuinely stops you in your tracks. Not an inconvenience — just something you’d reasonably expect to exist that simply doesn’t.
Extracting a Dynamics 365 activity timeline is one of those things.
The timeline is one of the most information-rich parts of any Dynamics record. Every email, every note, every phone call, every task — the full story of that record in one place. In a case management environment, the timeline isn’t supplementary context. It often is the evidence. And yet there’s no native, out-of-the-box way in Dynamics 365 to extract that data into something structured and shareable.
We’d been receiving an increasing number of requests asking whether it was possible. For a while, the honest answer was: not really. The best available option was screenshots — taken manually, one scroll at a time, assembled by hand. It was slow, it was unreliable, and in any context where accuracy and completeness actually matter — FOI requests, internal investigations, regulatory audits — it wasn’t good enough.
That was the problem. So I started looking for a solution.
The Solution Overview
The solution is an Agent Flow in Power Automate, triggered through the same Copilot Studio agent already in use for record management — if you haven’t seen that yet, you can read about how that works here.
When a user says “Timeline Management”, the topic fires. It runs through both Copilot Chat and Microsoft Teams, and in practice Copilot Chat is where it performs best. The agent opens by explaining what it can do — extract the full activity timeline for a record and return it as an Excel spreadsheet, suitable for FOI requests, regulatory enquiries, and general record management — before handing the user a choice.
That choice is where the solution has grown since it first went live. Rather than a single question asking for a record reference, the agent now presents an Adaptive Card with two paths: extract the timeline for one record, or run a bulk export across many at once. What happens next depends on which one the user picks.
Once the request is submitted, it’s passed to the Power Automate flow, which identifies each record, queries its timeline, processes the results, and writes everything into a structured Excel file on a specified SharePoint site. No system administrator involved, no manual steps, no screenshots — though the way the user receives the finished file has changed too, and I’ll come to that shortly.
The Adaptive Card — Single or Bulk
The first version of this solution did one thing: you gave it a record reference, and it extracted that record’s timeline. That covered the most common request, but not the ones that mattered most — the large FOI or audit exercises where someone needs the timelines for dozens of records, not one.
An Adaptive Card solved both in the same place. When the topic triggers, the card asks a straightforward question: Single Record or Bulk Export?
- Single Record works exactly as before. The card asks for the record reference number, and the flow extracts that one timeline.
- Bulk Export asks for two things instead: the location of a CSV file and an Incident Number. The CSV holds a list of record references, and the flow works through each one in turn.
The card does more than tidy up the interface. A free-text question leaves room for ambiguity — the user isn’t always sure what the agent expects. Clearly labelled options remove that guesswork and make the two very different journeys, one record versus many, explicit from the start. It also keeps the whole interaction inside the conversation, whether that’s Copilot Chat or Teams.
The Copilot Chat conversation showing the agent introduction, the Adaptive Card with Single Record / Bulk Export selector, and the “in progress” reply.
The Configuration Table - Built to Scale
One of the more considered decisions in this build is how the flow works out which Dynamics entity it’s dealing with. Different record types — cases, assessments, notifications, enforcement records — each have their own table structure, their own reference number format, and their own Dataverse field names. Rather than hardcoding any of that into the flow, a dedicated Configuration Table holds all of it instead.
Each row in the table represents one supported entity type and contains everything the flow needs: the prefix (e.g. CAS-), the Dataverse logical name, the table set name used in OData queries, the reference number field name, and the primary key field name. When the flow receives a reference number from the agent, it loads the configuration table, finds the row whose prefix matches the start of the reference, and extracts the entity metadata it needs from there.
What this means in practice is that adding support for a new entity type requires no changes to the flow at all. One new row in the configuration table, and the next time someone provides a reference in that format, it just works. If you’re exploring how Dataverse tables fit into a setup like this, the Power Platform developer environment guide is a good starting point for getting a space to experiment.
The Timeline Entries
Every activity and note processed by the flow is appended to an array, with each entry capturing: activity type, subject, body text, From / To / CC addresses (emails only), direction (emails and calls), status, created by, modified by, owner, and timestamps. That’s fourteen columns per row — enough to give a complete picture of each entry without needing to go back to Dynamics to fill in gaps.
The Output - What the User Receives
Here’s the other significant change. In the first version, the agent returned the download link directly in the conversation the moment the file was ready. That’s fine for a single record, where the extract completes in seconds. It doesn’t hold up for a bulk export of dozens of records, which takes considerably longer — you don’t want someone watching a chat window waiting for it to finish.
So the process now runs in the background. As soon as the request is submitted, the agent confirms it’s been received and is running, and tells the user they’ll get a Teams notification once it’s done — with a note that larger requests take longer depending on how many records are being processed.
When the flow finishes, it posts a message straight to the requester in Teams with a link to the completed Excel file in SharePoint. The user gets on with their work and picks the file up when the notification lands, rather than waiting on the process.
For a bulk export, every record’s timeline goes into one combined spreadsheet. Ten references in the CSV means a single file containing all ten timelines — not ten separate files to stitch together afterwards.
The use cases for that file are deliberately broad — and that was intentional from the start:
- FOI and GDPR requests — where a complete, structured account of everything that happened with a record may be a legal requirement
- Internal investigations — where the timeline of activity needs to be reviewed and potentially shared with others
- Regulatory and compliance audits — where evidence of what was done, when, and by whom may be examined externally
- General record management — where a team needs a clear picture of a record’s history without navigating through Dynamics
One agent, one output format, one conversation — whether that’s a single record or several hundred.
Reflections
The gap that drove this build — no native way to extract a Dynamics 365 timeline — is the kind of thing you can easily accept as just how the platform works. The requests were coming in, the answer was always “screenshots”, and it became the normal answer. What changed wasn’t the platform. It was the decision to actually look for a better way.
The HTML to Text addition is a good example of how that kind of iterative thinking plays out in practice. The first version of the output was technically correct. The data was there. But it wasn’t useful in the way it needed to be — and that only became obvious when the flow was tested against real email data. Feedback from that testing led directly to the fix, and the fix went in before the solution hit production. That’s the right order of events.
The Adaptive Card and bulk export are the same idea, one step on. The solution had been in production a while before the limitation showed itself — single-record extraction was fine until someone needed forty timelines for one FOI response. Rather than treating “it only does one at a time” as just how it worked, the card and the background processing went in as a follow-up. A solution being live doesn’t mean it’s finished.
There’s a broader point here too, which I wrote about in more depth in this post on using AI to accelerate Power Platform work. The most valuable automation isn’t always the most technically complex — it’s the one that closes a gap that people had quietly accepted as permanent. This solution didn’t require custom development or platform extensions. It required Power Automate, a well-structured flow, and a configuration table that means the next entity type is a five-minute addition rather than a deployment cycle.
As with the rest of the agent, every extraction is initiated by a human, for a specific record, through a conversation that makes the process explicit. The agent doesn’t act on its own. In a context where the output might be used for legal, regulatory, or investigative purposes, that accountability matters — knowing who requested it, for which record, and when is part of what makes the output worth trusting.
The solution is in production. It’s being used. And when the next entity type needs to be added, it’ll be a new row in a table — not a rebuild.
Technologies Used
Got a Project in Mind?
Whether you're trying to close a gap in your platform, automate a process that's grown beyond manual effort, or build something your team actually needs — I'd love to hear about it. Take a look at the full portfolio to see what's been built, or get in touch directly.
Let's Talk