Which shared files got discussed and never actioned

It is Thursday afternoon. A delivery lead at a 40 person agency has two windows open side by side.

On the left is Dropbox. A folder called Client Deliverables / Q3. Forty one files, most of them PDFs and a few Figma exports, sorted by modified date. She can see who uploaded each one and when. Three files have comment threads with a small blue dot.

On the right is Slack. The #client-northwind channel. Somewhere in the last three weeks, an account manager dropped a link to NW_brand_audit_v4.pdf and wrote "have a look before Friday, I think page 9 is wrong." Two people reacted with a thumbs up. Nobody replied. The file has not been touched since.

She is trying to answer one question before the Friday client call: of everything we shared with this client, what got talked about and then dropped. Not what got shared. Not what got discussed. The intersection, minus the follow through.

Right now she answers it by scrolling. Dropbox gives her the file list. Slack search gives her a wall of messages containing "pdf". She reads both, holds the overlap in her head, and forgets two of them.

What Dropbox shows on its own

Dropbox is genuinely good at the file half of this. It knows every file in the folder, who created it, every version and when it was saved, who opened it and when they last did, and who has been granted access. The activity feed on a shared folder is detailed. If you want to know whether anyone has looked at NW_brand_audit_v4.pdf since it was uploaded, Dropbox will tell you, down to the viewer and the timestamp.

It also has comments. Someone can annotate a specific page and start a thread that lives with the file. For teams that use that feature consistently, quite a lot of the discussion is right there.

Where it stops is the word "consistently." Most conversation about a file does not happen in Dropbox comments. It happens wherever the team already is, which for most companies is Slack. Dropbox can tell you the file was viewed nine times and never changed. It cannot tell you that the reason nobody changed it is that someone said in a channel that page 9 was wrong and everyone assumed someone else would fix it.

And Dropbox has no concept of "actioned." A file being viewed is not the same as a file being dealt with. Dropbox records what happened to the object. It does not record whether the thing the object was supposed to trigger has happened.

What Slack shows on its own

Slack has the other half. The #client-northwind channel contains the sentence "I think page 9 is wrong," the two thumbs up, the follow up question nobody answered, and the moment three days later when the conversation moved on to a different client without ever returning.

Slack's search is capable. You can filter by channel, by person, by date range, by has:link, by files. If you know roughly what you are looking for you can usually find it. Slack Connect brings the client's own messages into the same place. Saved items and reminders exist for exactly this problem.

Where Slack stops is that a message about a file is not connected to the file's state. Slack knows a link was posted. It does not know whether the document behind that link has been modified since, whether anyone opened it, or whether a newer version now exists. If the account manager pasted a Dropbox link three weeks ago, Slack's record of that is frozen at the moment of pasting.

Slack also has no idea what "unactioned" means. A thread that ends is indistinguishable from a thread that was resolved silently in a call. Slack shows you the absence of further messages. It cannot tell you whether that absence means done or dropped.

Why the gap is structural

Look at what each half of the evidence actually is.

The file side is a record. It has fields. file_id, modified_at, last_viewed_by. You can sort it, filter it, count it. Any reporting tool can work with it.

The discussion side is not a record. It is prose. "I think page 9 is wrong" carries a concern, but there is no field called concern_raised anywhere in Slack's data model. The same meaning could arrive as "page 9?" or "hmm, the numbers on the audit don't match what we sent last month" or a screenshot with a red circle on it. There is no schema that covers those.

This is why the join is not a reporting feature either product forgot to build. Dropbox could add every Slack message to its activity feed and still not know which messages raise a concern. Slack could show live file status on every link and still not know whether the thread that ended meant resolved or forgotten. Both would be showing you more of what they already have. Neither would be doing the part that is hard, which is reading a sentence and deciding what it means.

It is also worth being precise about the neighbouring categories, because they are good tools that are shaped for different work. Automation platforms like Zapier and Make are trigger based. They fire when something happens and move a record forward: new file in Dropbox, post to Slack. That is genuinely useful, and if you want the notification, build it there. But a trigger cannot answer a question about what already happened across three weeks of history, because there was no trigger listening at the time and no accumulated state to query.

BI tools have the opposite shape. Power BI Copilot and Looker's conversational analytics are strong at questions over modelled data, and if your file metadata is warehoused they will answer file questions well. But the evidence on the other side of this question is a sentence somebody typed in a channel. It was never modelled, it has no schema, and it is outside what those tools can see at all. Not underserved. Outside.

The gap is not inside either product. It is between them.

What the join actually requires

Two things, and only one of them is mechanical.

The key. The thing that connects a Slack message to a Dropbox file is usually the shared link itself. A Dropbox share URL contains a path and an identifier, and it appears verbatim in the message text. That is a real join key. Filenames work as a weaker fallback, since people often type NW_brand_audit_v4.pdf without linking it, and Slack's own file unfurls carry the title. Neither is perfect. Renamed files break filename matching, and the same document shared twice produces two different links. But between link, filename and folder path, most mentions resolve to a file. This part is matching, and matching can be automated.

The judgement. The other part cannot. Deciding whether a message raised something that needed doing, and whether it got done, requires reading. "Looks great, shipping it" and "looks great, one thing on page 9" both start identically and mean opposite things. A thread with four replies might end in resolution or in drift. A file modified two days after the concern was raised probably means it was addressed, but a file modified by a different person for a different reason does not.

That is why this question has stayed manual. The matching half was always doable. The reading half needed something that could read.

Answering it with Skopx

Skopx connects to nearly 1,000 SaaS tools, Dropbox and Slack among them, and you ask it questions in chat. It reads across both, in your permissions, and cites what it used.

The sentence the delivery lead would actually type:

Look at everything in the Client Deliverables / Q3 Dropbox folder. Find where each file was mentioned in Slack in the last 30 days. Show me the ones where someone raised a question or a problem and the file has not been modified since, and there was no clear resolution in the thread.

What comes back is a short list, not a dashboard. For each file: the file, the message that raised something, who raised it, the date, whether anyone replied, and the file's last modified timestamp, with links back to both the Slack message and the Dropbox file so she can check the call herself. Skopx makes the judgement about "unresolved" and shows its evidence, which means she can disagree with it on any given row in about four seconds.

Once she has run that three weeks in a row, it is worth making it standing. Typing one sentence in chat builds it into an internal app: a console she opens on Thursday afternoons that shows the current state of the same question, no re-prompting. It reads live from both tools each time it loads. It groups by client folder, sorts by how long the concern has been sitting, and shows the file's last modified date next to the date the concern was raised, which is usually the whole story. Where it makes sense, a row can carry a single action button, post a nudge back into the original Slack thread, with a confirmation before it sends.

Everyone on the team can open the same console and each person sees only the files and channels they already have access to. Nothing is copied anywhere new.

What this does not do

It does not watch. There is no trigger, no scheduled run, no alert. It answers when you ask and it shows current state when you open it. If you want a Slack ping the moment a file lands, that is a job for an automation platform and you should use one.

It does not store anything. The console holds no records of its own, creates no tasks, and has no form. It reads from Dropbox and Slack, and the only write is a button a person clicks, with a confirmation step. Close the console and nothing persists except what already lived in your tools.

It does not see conversations you cannot see. Private channels you are not in, DMs, and Dropbox folders outside your access are invisible to it, which is correct and also means the answer is only as complete as your own visibility.

It will get some rows wrong. A concern resolved in a video call looks identical to one that was dropped. A file modified for an unrelated reason will read as addressed. This is why every row cites its evidence: the judgement is legible, and you overrule it when it is wrong. The value is not that it is always right. It is that forty files and three weeks of channel history get narrowed to six rows worth reading before the Friday call.

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