How to connect Asana to Slack for work arriving from other teams

Asana's most distinctive idea is that one task can live in several projects at once. It is genuinely useful — a piece of work appears in a team's board and in a cross-functional initiative without being duplicated — and it is also why the most common complaint about Asana notifications is that nobody can tell which project something arrived from.

That is the shape of the problem worth solving. Not another stream of task updates, but making it clear when work has arrived for your team from somewhere else, which is exactly the case Asana's own notifications handle least well.

What we'll cover

• Why a notification never says which project
• Work arriving from outside your team
• Building it with CodeWords
• Messages worth sending
• Dependencies, which nobody is watching
• Choosing the recipient
• What the built-in Slack integration covers
• Asking for work without creating it
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Why a notification never says which project

The specific confusion Asana users have, and the thing an integration can fix in one line.

A task can belong to several projects at once, which is a good idea and means a notification about it has no single origin.

Asana's own notification does not name the membership that triggered it, so a person following four projects cannot tell which one this concerns.

Your integration can say it explicitly — the project, and the section within it — which is a small addition and the most appreciated one.

Subtasks complicate it further, because they do not inherit project membership, so a message scoped to a project will not mention subtask work at all unless you decide it should.

The Asana integration page covers the object model and how custom fields shape what you can report on. Here the concern is narrower: making a message say enough that the recipient knows why they received it.

Work arriving from outside your team

The case worth building for, because it is where things sit.

A task added to your team's project by somebody in another team is a request, and it is the notification Asana handles least clearly.

A task assigned to one of your people from a project they do not follow is the same problem at the individual level.

A dependency cleared elsewhere unblocks your work, and nobody tells you — this is the one that costs days.

A due date set by somebody else on work you own is a commitment you did not make, and it is worth knowing about.

Each of these has the same shape: another team's action creates an obligation for yours, and the notification that would surface it is buried in a stream of updates from projects you follow for other reasons.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which projects, which arrivals matter, and who should be told.
3. Authorize the connection to Asana with a dedicated service account, and to your Slack workspace.
4. Describe the exceptions: a task already completed, an assignee who has left, a custom field that does not exist in that project.
5. Test against a scratch project and a test channel before anything reaches the team.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Messages worth sending

A task added to your project by somebody outside the team, with who added it and why, to the team channel.

A dependency cleared, to whoever owns the task that was waiting. Covered below because it is the highest-value one.

A task assigned to somebody, to that person, where the assignment came from a project they do not follow.

A due date changed on work your team owns, to the owner, since a date somebody else moved is a commitment changing without a conversation.

A weekly summary of what arrived, what completed, and what is overdue in your team's projects.

Nothing per comment, per field edit, or per section move. Those are activity, and forwarding them recreates the problem Asana's own notifications already have.

Dependencies, which nobody is watching

The most valuable message here and the one nobody builds.

A blocked task waits silently. The person who owns it has no reason to check the blocking task, and the person who clears it has no reason to tell anybody.

Notify the waiting owner when the blocker completes, which converts a days-long silence into an immediate handoff.

Report tasks blocked longer than a threshold, weekly, since some blockers are never cleared and nobody notices.

Report tasks blocked by something already complete, which is a surprisingly common data quality problem and means somebody is waiting for nothing.

Say what cleared it and who. A dependency notification with the blocking task named lets the waiting person pick up immediately rather than investigating.

Choosing the recipient

The Slack-side decision, and on a cross-team message it is the whole thing.

A request from another team goes to the receiving team's channel, not to the requester's, and not to a shared one where both assume the other is handling it.

An assignment goes to the person, as a direct message, since a channel message about somebody's assignment is addressed to nobody.

A dependency clearing goes to the waiting owner, privately, because it is an instruction to start work rather than news.

A summary goes to whoever looks across projects, usually a lead, and not to the team who are already in the tasks.

Ask people where they want their own messages. Some prefer a personal channel to direct messages, and honouring that costs nothing and improves the response rate.

When you cannot resolve a recipient, say so somewhere rather than dropping the message. A silently unroutable notification is a notification nobody knows they missed.

What the built-in Slack integration covers

Worth knowing precisely, because it decides what is left to build.

Task activity posted to a channel, configured per project, with no development.

Link unfurling, so a pasted task link shows its title, assignee, and due date.

Creating a task from a message, which covers simple intake without any custom work.

What it does not cover is cross-project logic, dependency notifications, routing that depends on which team a task arrived from, or anything joining Asana with another system. Those are the reasons to build something, and if none applies, the built-in integration is less work and stays visible in the project settings.

Asking for work without creating it

Intake from a conversation is where these integrations most often go wrong, and the failure is predictable.

A message is a request, not a task. Creating one directly puts unreviewed work into somebody's project, which is how a team's board fills with things nobody agreed to.

Create into a dedicated intake project, reviewed by whoever owns the team's workload, rather than straight into a working project.

Require the asker to say what they need and by when, as a short form on the action rather than parsing it out of a sentence.

Link the thread so the context survives, since a one-line task created from a long conversation loses the half that mattered.

Check for a similar existing task first, because the same request gets raised repeatedly by different people who did not see each other ask.

Tell them what happened. A confirmation with the task link, and a message when it completes, is what stops people bypassing the route and messaging somebody directly next time.

Making it survive

Be explicit about project and section, since a task in several projects has a section in each.

Make it idempotent, keyed on the task and the change, since webhooks are at-least-once.

Handle the webhook handshake, which Asana requires when establishing one, and monitor that events are still arriving — a webhook deactivated after repeated endpoint failures is a silent stop.

Decide about subtasks for every message and report, and say which you chose.

Report the outcome. Messages sent, arrivals detected, and anything skipped.

Limits worth knowing about

Rate limits apply per token and vary by plan.

Pagination applies to task listings, so reports built from a first page understate.

Search is constrained and is not a general query language, so complex selection is easier done by filtering retrieved results.

Some features are plan-dependent, including portfolios and parts of the rules engine.

Webhooks can be deactivated if your endpoint fails repeatedly, which is a failure that produces silence rather than errors.

What to set up first

Dependency clearing notifications: when a blocking task completes, tell whoever owns the task that was waiting, naming what cleared and who cleared it. Nothing else on this list converts a multi-day silence into an immediate handoff, and Asana will not tell either person on its own.

Two habits make the difference. Name the blocking task and the person who completed it, so the waiting owner can start rather than investigate. And add the weekly report of long-blocked tasks at the same time, because some blockers are never cleared and the notification alone will never surface those.

Frequently asked questions

Why is it unclear which project a notification came from?

Because a task can live in several projects and the notification does not say which membership triggered it. An automation can say so explicitly, which is one of the more useful things it adds.

Why does my report omit work?

Subtasks, most likely. They do not inherit project membership, so anything scoped to a project misses them entirely. Decide explicitly whether they are in scope rather than accepting the default.

What is the most valuable message to build?

A dependency-cleared notification to the waiting owner. Blocked tasks wait silently — the owner has no reason to check and the person who cleared it has no reason to say — and this converts days into minutes.

Should I use Asana rules instead?

For anything driven entirely inside a single project, yes, and they stay visible in the project settings. Build externally for cross-project logic, dependencies, other systems, and anything that should work the same way across many projects.

Why does setting a custom field fail?

Usually an enum option that no longer exists, or a project-specific field being set on a task in another project. Read the field definition rather than hard-coding options, since options change.

Why did our webhook stop firing?

Asana deactivates webhooks whose endpoint fails repeatedly. It produces silence rather than errors, so monitor that events are still arriving instead of assuming no events means nothing happened.

Should the channel receive comments?

No. Comments belong where they have the task's context, and forwarding them recreates exactly the volume problem that made Asana's own notifications hard to follow.

Should Slack messages create Asana tasks directly?

Into a dedicated intake project, reviewed by whoever owns the team's workload — not into a working project. A request is not a commitment, and creating tasks straight into active work is how a board fills with things nobody agreed to.

What makes an intake route stick?

Confirming that it landed, and telling the asker when it completes. Without both, people conclude the route swallows requests and go back to messaging somebody directly, which is the thing the route existed to stop.

How do I notice a dependency pointing at something already done?

Report it. Tasks blocked by a completed task are a common data quality problem, they mean somebody is waiting for nothing, and nothing in Asana surfaces them — the owner simply assumes the blocker is still outstanding.

Related reading

• Asana and CodeWords
• Connecting ClickUp to Slack
• CodeWords integrations and templates