Which documents changed after the decision in Teams

At 4:12pm on a Thursday, in a Teams channel called Renewals, EMEA, the account director types: "Agreed with legal, we drop the auto-renew clause and re-issue. Nadia has the redline." Three people react with a thumbs up. The thread moves on to something about a demo environment.

Eleven days later, the customer's procurement lead emails asking why the contract they just received still contains the auto-renew clause.

Now the account director is looking at two screens. On the left, Teams, scrolled back through eleven days of channel messages, trying to find the exact wording of what was agreed and when. On the right, OneDrive, in the shared EMEA Renewals 2026 folder, sorted by Modified date, looking at eight files whose names all start with the same customer name and end with things like _v4_final, _v4_final_LEGAL, and _v5_clean. Two of them were modified after 4:12pm on that Thursday. One of them was modified by Nadia. The question the account director actually needs answered is not "what changed in OneDrive" and not "what was said in Teams." It is: after we agreed to drop that clause, did anyone actually open the contract and change it, and is the file that got sent the one they changed?

That question sits between two products, and neither of them owns it.

What OneDrive shows on its own

OneDrive is genuinely good at the file half of this. Every item in that folder carries a modified timestamp, a modified-by identity, and a version history you can open and step through. On a Word document with version history intact, you can see that version 6 was saved by Nadia at 5:47pm and version 7 by someone in legal the following Tuesday. If the tenant has retention and auditing configured, the unified audit log records FileModified events with user, timestamp, and file path, and you can query those over a date range.

You can also compare. Open two versions of a Word file, run Compare, and Word will show you the clause that was removed as tracked markup. That is a real answer to "what changed in this document."

Where OneDrive stops is one step earlier and one step to the side. It knows a file changed. It does not know why the file changed, because the reason was never typed into OneDrive. Nadia did not annotate her save with "removing auto-renew per Thursday's call." Almost nobody does. The version comment field exists and sits empty in the overwhelming majority of real folders.

And OneDrive has no way to relate the eight lookalike files to each other beyond name similarity. It cannot tell you that _v5_clean was the one attached to the email that went to procurement, or that _v4_final_LEGAL was a dead branch someone abandoned. Modified date is a fact about a file. It is not a fact about a decision.

What Microsoft Teams shows on its own

Teams holds the other half, and holds it well. The message is there, with the author, the exact timestamp, the reactions, and the replies underneath it. Search will find "auto-renew" across channels you are a member of. If someone attached the redline to the message, the attachment is right there, and because Teams channel files live in the connected SharePoint site, that attachment is a real file with a real location, not a copy floating in a mailbox.

Teams even gives you a partial bridge: the channel Files tab shows what has been shared in that channel, and Microsoft's activity feed will tell you when a file you care about was edited.

Where Teams stops is that the sentence is not attached to anything. "We drop the auto-renew clause and re-issue" is a plain string in a channel. It names no file. It names a person, Nadia, by first name only. It implies a document exists, and the document it implies might live in a different SharePoint site, or in a private chat, or in a folder in someone's OneDrive that was never shared into the channel at all. Teams search is very good at finding messages containing a phrase. It has no concept of "the decision this message represents" or "the files that decision was about," because that relationship was never expressed as data. It only existed in the heads of the four people in the thread.

Why the gap is structural, not a missing feature

Here is the asymmetry worth naming plainly:

The join between them is not a reporting feature Microsoft neglected to ship. It is a join with no key. The Teams message and the OneDrive version are two independent facts that happen to be about the same thing, and nothing in either system records that they are about the same thing.

This is also why the usual tooling does not close it. Automation platforms like Power Automate, Zapier and Make are trigger based and excellent at that job: when a file is modified, do something next. But a trigger fires forward. It cannot be asked, eleven days later, about a decision that was made before anyone thought to configure a trigger for it. The event you needed to capture was not identified as an event at the time.

BI tools have the opposite constraint. Power BI Copilot and Looker Conversational Analytics are strong on modelled data, and file audit events can absolutely be piped into a warehouse and analysed. But the deciding half of this evidence is a sentence in a channel. It is not a row, it has no schema, and the meaning that matters is carried by ordinary English. A BI tool connected to your audit log can tell you every file modified after 4:12pm on that Thursday. It cannot tell you which of those modifications was the one the sentence was asking for, because the sentence is outside what it can see at all.

What the join actually requires

Two things, and only one of them is mechanical.

The mechanical part is the key. It is a compound one: time window plus person plus file scope. Take the timestamp of the decision message. Take the people named or present in the thread, resolved from first names to real accounts. Take the folder or SharePoint site that the customer's documents live in. Intersect those, and you get a short candidate list, usually two to five files, rather than eight hundred.

The part that cannot be matched is the judgement. Given the candidate list, someone has to read the sentence and read the diff and decide whether they correspond. "We drop the auto-renew clause" and a version-7 diff that removes the paragraph beginning "This Agreement shall renew automatically" are obviously the same act to a human and are not string-equal to anything. Meanwhile, a version that changed only the pricing table is a modification inside the same window by the same person and is not the change that was asked for. No matching rule survives that. It needs reading.

That is exactly the shape of work that sits badly with both categories of tool: the mechanical half is too fiddly to do by hand, and the judgement half is not automatable by rules.

Answering it with Skopx

Skopx connects to nearly 1,000 SaaS tools, OneDrive and Teams among them, and answers questions across them in chat with citations back to the source.

The realistic thing the account director types is not a query. It is the question as they would ask a colleague:

In the Renewals EMEA channel, find where we agreed to drop the auto-renew clause on the Contoso contract, then show me which files in the EMEA Renewals folder changed after that message and whether any of them actually removed the clause.

What comes back is the message itself with its timestamp and author, the files modified in the window after it, who modified each one, and a read of which change corresponds to the decision and which does not. Each part cites where it came from, so the account director can click through to the Teams message and to the specific OneDrive version rather than taking the summary on trust. The likely finding in our example: Nadia's version 6 did remove the clause, and version 7, saved by legal the following Tuesday, restored an earlier draft, which is why procurement received the wrong text.

Once that question has been asked three times, it stops being a question and becomes a view. Typing a sentence like "build me a console showing decisions in our renewals channels with the documents that changed after them" produces a standing internal app over the same two sources. It would show, per customer: the decision message, the file that changed after it, the person who changed it, the gap in days between the two, and the cases where a decision has no corresponding file change at all. That last column is the one worth having, because the expensive failure is silent. Nobody notices the change that never happened. If the console needs to act, the action is a button a person clicks with a confirmation, for example posting a reply in the Teams thread flagging the unmatched decision.

What this does not do

It does not watch. There is no trigger sitting on your renewals channel catching decisions as they are made. This answers questions about what already happened, which is precisely why it works on decisions nobody thought to instrument at the time, and precisely why it will not page you at 4:13pm.

It does not store anything of its own. There is no new record of decisions being created on the side, no forms, no scheduled runs, no alerts, no public links. Your evidence stays in Teams and OneDrive.

It does not read what it cannot reach. Decisions made in a private chat you are not in, or a Teams call with no transcript, or a hallway, are invisible. Permissions are respected: you see what your Microsoft account can already see, which means a console can legitimately show one person a decision another person cannot.

And it is a read plus a judgement, not a verdict. When it says version 6 removed the clause, that is a claim with a citation attached, and the citation is there so a person can check it. On something contractual, a person should.

Skopx is $16 per seat per month on Team, including 2.3 million AI tokens per seat, and $5 on Solo. SOC 2 controls are in place.