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. Unlike the record management topic — which presents a menu of available actions — this one has a single purpose right now: extract the timeline for a specified record. So rather than asking what the user wants to do, the agent moves straight to asking for the record reference number, and the process begins.
Once the reference is provided, it’s passed to the Power Automate flow. From there, the flow identifies the record, queries the timeline, processes the results, writes everything to a structured Excel file on a specified SharePoint site, and hands a download link back to the user through the agent. No system administrator involved. No manual steps. No screenshots.
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
The final step copies a pre-built Excel template from a designated SharePoint folder, populates it with all the processed timeline entries, saves the file with the record reference and a timestamp in the filename, and returns the SharePoint URL to the Copilot agent. The agent delivers this back to the user as a clickable download link, alongside a count of how many entries were exported.
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 flow, one output format, one conversation with the agent — regardless of which of those scenarios applies.
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.
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