Asana Salesforce Integration: Options, Setup and Limits (2026 Guide)

What an Asana Salesforce integration is for

The split is common: sales tracks accounts and opportunities in Salesforce, and onboarding, professional services, legal or marketing plan the work in Asana. Without a link, the handoff runs on Slack messages and copied fields, and sales has no idea whether the customer is live yet.

The jobs people want done:

• Closed-won to onboarding. When a deal closes, the delivery team gets a task or project with the account, amount, products, close date and owner filled in.
• Requests from sales. A deal hitting a stage (proposal, security review, contract) creates a task for solution engineering, legal or finance.
• Fresh data in Asana. When the amount, close date or account name changes in Salesforce, the Asana task changes too.
• Progress back in Salesforce. Account managers see project status and the go-live date on the account or opportunity.

Asana’s native integration covers the first three. The fourth needs another route, and that is where most of the planning goes.

What changed in 2026: the AppExchange app is gone

Many guides still describe Asana for Salesforce, a managed package from AppExchange (now AgentExchange). It added Asana components to Salesforce pages, created projects from a template when an opportunity reached a chosen stage, and offered Asana actions for Salesforce automation.

According to Asana’s deprecation FAQ, that app was deprecated and removed from the marketplace on February 27, 2026. From that date its Lightning components for linked tasks and projects and its Apex actions stopped working. If your org still has flows or automation that call those Asana actions, they need replacing.

The replacement is Salesforce in Asana, which Asana says it released in early 2025. It is built on Asana’s own rules engine, set up in Asana rather than in Salesforce, and works the other way around: Salesforce events drive Asana automation.

How Salesforce in Asana works

According to Asana’s help center, as of October 2026 the integration adds Salesforce as an external trigger for Asana rules. A rule is a trigger plus actions, set per project.

Requirements

• Asana plan: Asana’s app directory lists the integration for Advanced, Enterprise and Enterprise+ as of October 2026.
• OAuth per user: each person who builds rules or links records signs in to Salesforce from Asana.
• Salesforce permissions for rule builders: Customize Application, Run Flows, Manage Flows, Modify Metadata Through Metadata API Functions, and Enable System Mode Flow Activation. These are admin-level rights, so most teams let a Salesforce admin or a small group build the rules.
• Record access: rules and links only see records the connected user can see in Salesforce. In Asana, linked Salesforce data follows normal task permissions.

What it doesn’t do

• No write-back. Asana documents sync from Salesforce into Asana only. Completing a task or a project in Asana does not update the opportunity.
• No Asana panel in Salesforce. The components that showed tasks on records went with the old app.
• Tasks, not projects. Rules create tasks from Salesforce events. A full onboarding project from a template needs a conversion step: done by hand, or by another tool through the Asana API.
• Field type gaps. Single-select and multi-select custom fields are not supported in field syncing, and the keep-in-sync action won’t update a mix of text and variables such as “Account: {Account Name}”.
• Stage-specific sync takes two rules. Asana’s help center says the preset keep-in-sync action does not sync correctly when you only want tasks for one stage. You need a creation rule and a separate sync rule (covered in the setup steps below).

Your options compared

Four routes, from simplest to most flexible:

Zapier, Make and Workato all publish ready-made Asana and Salesforce connections, such as “create an Asana task from a new Salesforce opportunity”. Unito sells two-way, field-level sync between Asana tasks and Salesforce records. Check each vendor’s current plan and object support before you trial one.

Which option fits you?

The key question is whether anything must flow back from Asana to Salesforce, since the native rules only go one way. Five questions in all, including deal volume and your Asana plan.

How the data flows

The design that holds up: Salesforce is the system of record for the customer and the deal. Asana is the system of record for the work. Deal data flows into Asana; at most a few summary fields flow back.

Field mapping: what goes where

Start with this minimum set. Add a field only when someone can name the decision they will make with it.

Asana’s help center lists how Salesforce field types arrive:

• Strings, text areas and picklists become text.
• Dates become dates or text.
• Currency, integer and long fields become numbers or text.
• Percent becomes a number where 1% equals 1.
• Rich text arrives unformatted.

Plan your Asana custom fields around that before you build rules.

How to set it up, step by step

The walkthrough uses the most common case: a handoff task when an opportunity is closed won. Because rules live in Asana, most steps happen in an Asana project, not in Salesforce Setup. Asana’s help center has the current screens.

1. Agree on the handoffSales and delivery leads agree which stage starts the work, what the delivery team needs from the deal, and whether sales needs anything back. Write it as a one-page mapping.
2. Check plan and permissionsConfirm your Asana plan includes the integration. In Salesforce, give the rule builder the permissions Asana lists: Customize Application, Run Flows, Manage Flows, Modify Metadata Through Metadata API Functions and Enable System Mode Flow Activation. Ideally, grant them through a permission set rather than a full admin profile.
3. Clean the deal dataMake the fields you will map required at the right stage (amount, close date, products, handoff notes). Empty fields create empty tasks.
4. Build an intake projectOne Asana project receives handoffs. Add the custom fields you mapped: number for amount, date for close date, text for picklist values.
5. Authorize SalesforceFrom the project’s Customize menu, add a rule, choose the Salesforce trigger from the external triggers tab and sign in to Salesforce. If you can, connect to a Salesforce sandbox first.
6. Rule 1: create the taskTrigger: Record is created or updated, object Opportunity, Stage set to Closed Won. Action: Create a task (not the keep-in-sync preset), with the task name, assignee and fields from Salesforce variables. Asana says not to add extra “Check if” conditions to this rule.
7. Rule 2: keep fields currentTrigger: Record is created or updated, object Opportunity, no stage condition. Action: set the mapped Asana fields from the Salesforce fields. This rule only updates tasks already linked to a record.
8. Turn tasks into projectsThe delivery lead converts the handoff task into a project from your onboarding template. To skip the manual step, use an iPaaS or the Asana API endpoint that creates a project from a template.
9. Test real scenariosA deal closed won, the amount changed after closing, and a deal reopened and closed again. Then a deal with a missing field and a user without access to the record. Check what landed in Asana and what didn’t.
10. Pilot, then roll outRun one team for two weeks, fix the mapping, then add rules for other stages or teams and tell sales what they will and won’t see.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Pitfalls and how to fix them

When to go beyond the native rules

An iPaaS makes sense when you need a few steps the native rules lack. Typical examples are creating onboarding projects with deal-specific logic, or writing a status and a project link back to the opportunity.

Zapier and Make fit a handful of flows; Workato fits teams that already run it for other systems. If you want tasks and records matched in both directions without building flows, a sync tool such as Unito sells exactly that.

Custom work starts to pay off when:

• Closed-won should create a project from a template with roles and dates filled in, sometimes several projects per deal by product.
• Sales wants rollups back in Salesforce: milestones, percent complete, go-live date and risk flags per account.
• You hand off to several teams or Asana workspaces with routing rules.
• Per-task or per-item pricing grows faster than a one-time build.

A typical custom build is a small middleware service. On the Salesforce side, a Platform Event or Change Data Capture on the opportunity starts the flow, and a dedicated integration user writes status back. Salesforce includes a limited number of Salesforce Integration user licenses in supported editions.

On the Asana side, the REST API has an endpoint that instantiates a project from a project template as an asynchronous job, and Asana webhooks report task and project changes. Asana’s developer documentation sets standard rate limits per token: 150 requests a minute on free domains and 1,500 on paid ones, plus limits on concurrent requests.

Store a link table of opportunity IDs and Asana project IDs, and make every write idempotent so retries don’t create duplicates.

Creating one project per closed deal is a one-way job; rollups of milestones and go-live dates back into Salesforce make it a two-way sync. Our API integration cost guide covers what sits behind each range. For the wider picture of Salesforce connectors, limits and patterns, see the Salesforce integration guide. If delivery runs on boards rather than projects, the Salesforce monday.com integration guide covers that tool, and engineering handoffs are covered in the Jira Salesforce integration guide.

Go-live checklist

Before the first real closed-won deal fires a rule, run through this list. It covers the handoff agreement, both rules and removing what is left of the old AppExchange app.

FAQ

Where Gilzor fits

Asana’s rules cover the trip from Salesforce into Asana; getting progress back to sales is where most of the planning goes. Gilzor is a software development company in Poland and Cyprus that builds and maintains Salesforce integrations.

We can map the sales-to-delivery handoff with your teams, set up Asana’s Salesforce rules or an iPaaS, or build a custom integration on the Asana and Salesforce APIs that creates projects and reports progress back. Support after launch is part of it; our Salesforce integration services page shows how the work is scoped.