Which Asana tasks are blocked by a conversation nobody logged

It is Tuesday, 9:40am. Priya runs delivery for a twelve-person product team. She has the Asana board for the Q3 platform migration open on her left screen, filtered to her team, sorted by due date. Fourteen tasks are past due. Six of them are marked "In progress." One says "Waiting" in the task name, which is not a status Asana knows about, because someone typed it there in March and it stuck.

On her right screen is Slack. She is scrolling #proj-migration, and she has just found the reason one of those six tasks has not moved in eleven days. On July 24th, a backend engineer wrote: "hold off on the schema change until legal signs off on the retention window, they said end of next week." Nobody replied. Nobody updated the Asana task. The task still says "In progress," assigned to that engineer, due July 26th.

Priya has a stand-up in twenty minutes and a steering call at 2pm. What she needs is a list: which of these fourteen overdue tasks are actually stuck on something somebody said in Slack, and what the something is. She will get it by reading, one task at a time, cross-referencing by memory, for about forty minutes. She does this most weeks.

What Asana shows on its own

Asana is precise about the things it is designed to record. For any task it knows the assignee, the due date, the section, the custom fields your team configured, the full comment thread, the attachments, and every state change with a timestamp. Asana's own dependency feature is genuinely useful: mark task B as blocked by task A and the board will tell you, and Asana will notify the assignee when A completes. Rules can move a task when a field changes. Reporting can chart tasks by status, by assignee, by completion over time.

Where it stops is not a gap in the product. It stops where the recorded state stops being true. Asana can tell you a task is "In progress" and eleven days past due. It cannot tell you that the reason is a legal review, because nobody encoded that. The blocker exists, it is real, and it is not a task in Asana. It is a decision by a person in another department, communicated in a sentence, in a different application.

The Asana dependency model only works when the blocker is also an Asana task in the same workspace. That covers a meaningful share of real blockers. It does not cover "waiting on legal," "the vendor has not sent the sandbox credentials," "we decided in the design review to wait for the new component," or "Marcus said he would handle it and then went on leave." Those are the ones that hurt, because they are invisible to the board and therefore invisible to the weekly report generated from it.

What Slack shows on its own

Slack has the missing half. The sentence about legal signing off is right there, in a channel, with a timestamp and an author, permanently searchable. Slack's Asana integration is good at what it does: paste a task link and you get an unfurled preview with status and assignee, create a task from a message with an action, and get channel notifications when tasks complete or change. If your team uses it consistently, a fair number of Slack conversations do produce Asana artifacts.

Where Slack stops is on the other side. Search in Slack is retrieval by keyword within a corpus of messages. Ask it for "blocked" and you will get every message containing the word blocked, across every channel, in reverse chronological order, including the ones about a blocked IP address and the ones from four months ago that resolved the next day. Slack has no idea which of those messages correspond to work that is currently open, currently overdue, or assigned to anyone on Priya's team. It cannot rank the results by how much they matter, because mattering is a property of the Asana side.

More to the point, most real blockers never contain the word "blocked." They say "hold off," "let's park this," "I'll pick it up after the release," "still no word from them." That is the shape of the problem: the evidence is unstructured on purpose, because it is people talking.

Why the gap is structural, not a missing feature

Look at what each half of the answer actually is.

The top half is queryable. Rows, fields, filters. Any reporting tool pointed at Asana can produce it in a second. The bottom half is not queryable in the same sense at all. It is prose written by a human for another human, with no schema, no required fields, and no guarantee that the task it refers to is named anywhere in the message.

This is why the gap survives good integrations on both sides. Zapier, Make and Asana's own rules are trigger based, and they are effective at that: when something happens, do the next thing. That is the correct design for moving work forward. But a trigger fires at a moment and acts on the payload in front of it. "Which of my fourteen overdue tasks is stuck on an unlogged conversation" is a question about the accumulated state of two systems right now, including things that did not happen, like the reply nobody sent. There is no event to hang it on.

BI tools have the opposite constraint and are equally reasonable about it. Power BI Copilot, Looker Conversational Analytics and the rest connect to databases and modelled sources, and they answer beautifully once the data is in a model. A Slack message about legal sign-off is not in a model and cannot easily be put into one. It has no dimension, no measure, no join key. It is a sentence. The evidence Priya needs is outside the category of thing a BI tool is built to see.

So neither side is failing. The record half and the sentence half are genuinely different kinds of material, and the join between them is not a report either vendor forgot to build.

What the join actually requires

Two things, and only one of them is mechanical.

The key. You need to connect an Asana task to the Slack messages that concern it. In practice the linkage comes from several weak signals rather than one strong one: an Asana task URL pasted in a message, which is the cleanest case; the assignee's Slack account matching the Asana assignee; the project channel matching the Asana project; and the task name or a distinctive phrase from it appearing in the message text. Timing matters too, since a message three days before a due date is more likely relevant than one from four months ago. Any single signal is unreliable. Together they narrow fourteen tasks and several thousand messages down to a few dozen candidate pairs.

The judgement. This is the part matching cannot do. Given the candidate messages for one task, someone has to decide: does this message describe a blocker, and is that blocker still in force? "Hold off until legal signs off" is a blocker. "Nice work on this" is not. "I'll pick it up Monday" was a blocker until Monday, and it is now either resolved or worse. A later message saying "legal came back, we're clear" retires the blocker, and its absence is what keeps the blocker alive. That is reading comprehension over a thread, applied per task. It is exactly what Priya does for forty minutes on Tuesday mornings, and it is the only part of the job that needs a brain rather than a query.

Doing it with Skopx

Skopx connects to nearly 1,000 SaaS tools, Asana and Slack among them, and both halves of this question are in reach at once. What Priya types in chat looks like what she would ask a colleague:

Look at every task in the Q3 Platform Migration project in Asana that is open and past due. For each one, search Slack for messages that mention the task, the task link, or the assignee discussing it in #proj-migration or #eng-backend over the last month. Tell me which tasks look blocked by something in Slack that was never recorded in Asana, quote the message, and say whether anything later resolved it.

The answer comes back as a list, and every claim in it carries a citation back to the specific Asana task and the specific Slack message with its author and timestamp, so she can click through and check before she says any of it out loud on the steering call. That last part matters more than the speed. A summary she cannot verify is worse than no summary.

Once she has run something like that three weeks in a row, it is worth making it standing rather than asked. Described in a sentence in chat, an internal app becomes a console she opens on Tuesday morning: a table of open overdue tasks in the project, each row showing assignee, days past due, the most recent relevant Slack message quoted with a link to it, and a read of whether the blocker appears live or retired. It reads Asana and Slack every time she opens it, so it is current rather than a snapshot. If she wants to act on a row, a button can post a nudge to the thread or add a comment to the Asana task, and she clicks it and confirms the action first.

What this does not do

It does not find blockers that were never said anywhere. If the schema change is stalled because an engineer privately decided it was a bad idea and told no one, there is no evidence to read and nothing will surface it.

It does not resolve anything. It reads, it reports, and the only writes are the ones a person clicks a button for, with a confirmation. There are no forms, no records created quietly in the background, no scheduled runs firing off overnight, no alerts, and no public link you can send to someone outside the workspace. It is a console for a person who opens it.

It will get some judgements wrong. "Waiting on the vendor" from three weeks ago may have quietly resolved in a DM you did not connect, and a joke about parking a task may read as a real blocker. This is why every line is cited: the output is a shortlist to check, not a verdict to forward.

It only sees what the connected accounts can see. Private channels and DMs it has not been granted access to are outside the answer, which is usually correct and occasionally the reason a blocker stays invisible.

And it does not replace people updating Asana. The right long-term fix for "legal has to sign off" is a task in Asana with a due date on it. This closes the gap between the boards you have and the conversations you actually had, which in most teams is permanent, but it is a compensation for the drift, not a cure for it.

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