Asana integration the project creates itself
A won deal in the CRM, a new order or a form submission creates a project in Asana from your own template: sections, the list of steps, due dates counted from the start date and one owner on every task. Data from the source system sits in custom fields, and closing a task sends the status back to where the work came from. Nobody copies the step list off the last project.
- 1 assigneeis all the assignee field on an Asana task takes, so the assignment rule has to name one person or the task ends up with nobody accountable. Asana developer documentation
- 2 to 6 weeksfrom workshop to a working integration, tested on the projects you actually ran over the last few months
- 14 daysis the usual gap between the workshop and the first automation running, most often a project created after a won deal
The problem
Why does the Asana project appear two days after the contract is signed?
A rep closes a deal and writes on Slack that there is a new client. Somebody opens Asana, hunts down a similar project from last time, duplicates it and retypes the task names. Due dates go in from memory, because the start date sits in the contract and the contract sits in the CRM. Three tasks end up with no owner, and one keeps the old assignee, a person who stopped working with that client months ago.
Asana is not the problem here. The problem is the manual bridge between the system where the work starts and the system where the work gets done. That bridge is always the same person, the same list of twenty steps and the same memory that a client on a service contract also needs a check task a month later.
The cost shows up in two places. The first is delay: the project starts a day or two after signature, and the task due dates are counted from the day somebody typed them in, not from the start date in the contract. The second is ownership. The Asana developer documentation describes a single assignee field on a task, so a task has exactly one person accountable or nobody at all. A project put together in a hurry leaves some tasks with no owner, and nobody notices until a due date has passed.
- The project for a new client starts a day or two after the contract is signed
- Due dates counted from the day they were typed in, not from the project start date
- Tasks with no owner, because one field got skipped while copying
- Client data stays in the CRM and the team asks for it on Slack
- The same kind of project looks different under two account managers
Why now
What changed, so that an Asana project can be created by machine?
The systems where work starts now report an event a second after it happens: a won deal in HubSpot or Pipedrive, a new order in Shopify or BaseLinker, a submission from a form on the website, a new hire in the HR system. Nobody has to wait for a person to look into the CRM and retype it into Asana.
On the Asana side, a project template can be run through the API with a date supplied, and the task due dates are counted from it. The automation does not recreate twenty tasks one by one, it fires your template and Asana lays out the due dates and the dependencies between steps itself. The template stays in Asana and you change it yourselves, with no ticket raised with us.
The third change is the AI agent. An automation will create the project, but it will not answer the question of which tasks across client projects are overdue and whose they are. BOND, our company AI agent, answers that from your own data in 5 to 10 seconds, without opening Asana and without anybody building a report.
What changes
What does a team working in Asana get?
The project exists a minute after the deal is won
An event from the CRM runs the project template together with its sections and its list of steps. The account manager sees a finished plan sooner than they could have duplicated the previous project.
The same template every time, whoever sold the deal and whoever happens to have a free hour
Due dates counted from the start date
The automation passes the start date from the source system and Asana lays out the task due dates against it. A project that begins next month has a correct calendar from its first minute.
Start date taken from the deal record or from the order, due dates recalculated as the project is created
Every task has one person accountable
The assignment rule names a single owner, because that is what the assignee field in Asana takes. The rest of the team goes on as followers, so they see the changes and are not on the hook for the date.
Assignment by role on the project, with holiday cover taken from the calendar
CRM data in custom fields, not in a comment
Deal number, value, account manager, the date from the contract and the client identifier go into the custom fields on the task. The team stops asking for them on Slack, and a report can be built from them without anyone counting by hand.
Custom fields filled in at creation and updated when the record in the CRM changes
Closing a task sends the status back
Marking a task complete pushes the status to the CRM or to the order, and writes the date and the person into the spreadsheet and the warehouse. Delivery history stops being reconstructed from what the team remembers.
Task completion recorded in the CRM, in Google Sheets and in BigQuery on the same day
Overdue work is visible in the morning
A review of overdue tasks goes out as one Slack message at 8:00, split by owner and by project. The manager does not click through projects to assemble it.
One digest a day instead of a notification from every single task
Proof
Do you work this way yourselves?
Yes, and we will say straight away what the number does not show. We have no Asana measurement from a client that we are allowed to publish. What we have is our own rollout in our founders' agency, where an event in one system creates a record in the task system and notifies the right person with nobody in the middle. Same mechanics, same tools.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency of around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
An AI agent wired into the task system, the CRM, Slack, the forms on the website and the data warehouse. First commit on 1 March 2026, and 23 people use it today.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- A record in the task system was created by a person after reading the request, and that person decided who to assign it to. What reached the system was whatever somebody remembered to retype.
- After
- The agent picks the requests up: it creates the record, checks for a duplicate and notifies the right person on Slack. A human comes in only for the substance of the case.
29,854 operations with no human involved in 30 days, out of 64,903 operations in total
And in your company
What if our Asana looks different?
Four sentences we hear on the first call, and how we answer them.
One warning up front: an automation will not fix a template that does not exist. That is why we start from one kind of project and one entry point, and add the next ones once the first has run a full month in production.
We have Asana, but every team uses it their own way.
Then the first result of the workshop is not a technical one: one kind of project gets one template, written down together with its exceptions. Only a template that looks the same every time can be fired by machine. Without that, an automation spreads today's mess faster than a person could.
Asana has rules and templates built in, so why add anything?
If the work starts and ends in Asana, its own rules are enough and that is what we will tell you. An outside automation pays for itself when the starting event sits in the CRM, in the shop or in the HR system, when data from that system has to land on the task, and when closing the task has to send a status back there.
We need more statuses than done and not done.
Asana keeps the stage in a custom field rather than in the task lifecycle, and with three or four stages that works without friction. Once there are a dozen or more stages, plus sprints and estimates, we will say plainly that Jira is a better home for that work, and we will not push it into Asana.
Our team is not technical and worries the automation will make a mess.
For the first two weeks the automation creates projects in a separate test project, alongside the way you work today, so you see its decisions with nothing at risk. The template stays in Asana and the person running the team changes it, with no code and no ticket raised with us. The automation reads the template at the moment it runs, so a change applies from the next project on.
- Tasks and projects
- Asana: projects, sections, project templates, custom fields, dependencies between tasks
- CRM
- HubSpot, Pipedrive, Salesforce, Zoho
- Sales and orders
- Shopify, WooCommerce, Magento, BigCommerce, BaseLinker
- Time tracking and data
- Harvest, Toggl, Google Sheets, BigQuery, SQL databases
- Team work
- Slack, Microsoft Teams, Google Workspace, Microsoft 365, Notion
- Automation layer
- Make, n8n, Zapier, custom API integrations
An event in another system and what it creates in Asana
The entry points that most often start work in Asana, and what goes back to the source system once the task is closed. We settle the starting scope in the workshop, because two entry points handled properly beat six handled halfway.
| Event at the entry point | What appears in Asana | What goes back to the source system |
|---|---|---|
| Deal won in the CRM | an onboarding project from the template, sections and steps with due dates from the start date | a link to the project and the start date on the deal record |
| New B2B order | a delivery task with an owner from the assignment rule | delivery status and dispatch date on the order |
| Submission from a form on the website | a task in the service project, the text of the request in custom fields | case number and a confirmation to the sender |
| New hire in the HR system | an onboarding project with steps for the first 30 days | the date the step list was closed, in the personnel record |
| Order status change in the ERP | a check task in the section for that stage | confirmation of the check, with person and time |
| Task completed in Asana | the next step in the dependency chain starts with its own due date | stage status in the CRM plus an entry in the spreadsheet and in BigQuery |
| Task overdue | a flag in a custom field and a reminder for the owner | an entry in the 8:00 Slack review |
A first rollout usually covers the first two rows. We add the rest once those have run in production for a full month.
How we work
Four steps from copying projects to a template in production
Every step ends with something you can judge before you decide on the next one.
Workshop
We take three of your recent projects of the same kind and break them down into steps. We check what repeats, what is an exception, who creates the project today and how long the road from signature to first task actually takes. We also write down the kinds of work that must never be created by machine in Asana.
Template and field map
One project template per kind of work, with sections, dependencies and due dates counted from the start date. Plus a field map: what moves from the source system into the custom fields on the task, and which rule names the owner. We pick the tool: Make, n8n or an integration through the API.
Rollout in parallel
The automation creates projects in a test project, alongside the way you work today. For the first days we compare its decisions with the team's: is the owner right, does the due date make sense, what is missing from the template. We fix the template against real events, not imagined ones.
Switch over, training and measurement
Once it checks out, the automation creates projects in the real workspace, with error monitoring and an alert when a step fails. The person running the team learns to change the template and the rules on their own. At 30 and 90 days we look at what can be counted: how many projects the automation created, how many tasks started with no owner, how many due dates had to be fixed by hand.
Before and after
How the day changes for the person running projects
Before
- Creates the project by duplicating the last one and retyping task names
- Types due dates in from memory, because the start date is in a contract in the CRM
- Chases the rep for the value, the scope and the client contact
- Finds out about a task with no owner once the due date has passed
After
- The project from the template is waiting before they open Asana
- Due dates sit against the start date taken from the deal record
- Client data is in the custom fields on the task, with nobody to ask
- A task with no owner never gets created, because the rule always names someone
The first project from a template is visible on switch-over day. We judge how well owners and due dates land after 30 days, and the effect on project start time after 90.
For the person signing this off
What the head of operations gets out of it
You stop being the company's memory of what a proper project start looks like. Today that knowledge sits in two people's heads and in one project somebody once did well. After the rollout it sits in a template that runs identically for every client, including the weeks when both of those people are on holiday.
The second thing matters more in front of the board. You know how many projects start on time, how many tasks ran past their due date and at which stage the team gets stuck, because all of it is in custom fields and in the warehouse. That is an argument in a conversation about a new hire or about the scope of a client contract, and today you do not have it.
- A project template written down and versioned, not dependent on one person
- Every task from the automation has an owner, so there is no work belonging to nobody
- The automation runs in parallel, and current work carries on until testing is done
- You change the template and the rules yourselves, with no ticket and no waiting
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week, and runs from 1 to 7 weeks. An Asana integration usually needs one week, because the process is narrow: from an event in the source system to a finished project. We quote the rollout after the workshop, once it is clear how many entry points and kinds of project are in play and what state your templates are in today.
You pay for the automation platform and the Asana licence directly to the vendor, with no margin from us. When n8n sits on your own server, that cost is zero. If the AI agent option is on the table, the language model is a provider cost too, roughly EUR 0.005 to 0.07 per query.
Process workshop
EUR 3,500 net
per week, and one kind of project usually needs one week
A self-contained piece of work. It ends with a project template, a field map and a rollout plan you could execute without us.
- A breakdown of three of your recent projects into repeatable steps
- A project template with sections, dependencies and due dates from the start date
- A map of custom fields and the rule that names the task owner
- A tool recommendation: rules inside Asana, Make, n8n or the API
- Most popular
Workshop and integration rollout
Quoted after the workshop
scope follows from the number of entry points and kinds of project
The option most companies choose. A working integration 2 to 6 weeks after the workshop, tested on your own real events.
- Everything in the workshop
- An automation in Make, n8n or through the API, wired to Asana and the source system
- Project creation from the template, owner from the rule, custom fields carrying the data
- Status sent back to the source system once the task is closed
- Rollout in parallel, switch-over with monitoring and training for the team
Asana and an AI agent
Quoted after the workshop
for teams that ask about the state of projects every day
Everything in the rollout plus BOND, which answers questions about projects and due dates in a plain sentence.
- Everything in the integration rollout
- An AI agent wired into Asana, the CRM and the data warehouse
- An overdue review on Slack and an alert on a task with no owner
- Access for the team and the manager, in English and in Polish
The workshop ends with a document that stands on its own: the project template, the field map and the rollout plan. If it turns out that rules and templates inside Asana are enough, we say so and show you how to set them up. The matter then ends at the workshop, rather than at a rollout you do not need.
Frequently asked questions
What is an Asana integration in practice?
It is Asana wired into the systems where work starts: the CRM, the shop, a form, the HR system or the ERP. An event in that system creates a project from a template in Asana, or a single task, with an owner, a due date and the data in custom fields. Closing the task goes back to the source system as a status and a date.
How long does an Asana integration take?
One week of workshop and 2 to 6 weeks of rollout, depending on the number of entry points and kinds of project. The first working automation usually exists 14 days after the workshop. For the first two weeks the automation runs in a test project, alongside the way the team works today.
Can a project really be created from a template automatically?
Yes, and that is the heart of this integration. We run the project template through the API and supply the start date, then Asana lays out the task due dates against it along with the dependencies between steps. The template stays in Asana, so you change it yourselves, and the automation reads the current version every time it runs.
Who owns a task the automation created?
Always one person, because that is what the assignee field on an Asana task takes. We settle the assignment rule in the workshop: by role on the project, by account manager from the CRM or by team workload, with holiday cover pulled from the calendar. Everyone else joins the task as a follower and sees the changes without being on the hook for the date.
Where does the automation put the data from the CRM?
In the custom fields on the task and the project: deal number, value, account manager, the date from the contract, the client identifier, logged time from Harvest or Toggl. Custom fields can be filtered and counted, which is not true of a comment. Which fields we create is a workshop decision, because Asana limits how many a project can hold.
What happens when somebody closes a task in Asana?
The automation picks up the completion event and does three things: it updates the status in the source system, it writes the date and the person into the spreadsheet and the warehouse, and if the task had a successor in the dependency chain it starts the next step with its own due date. Delivery history then exists as data rather than as team memory.
Is Asana enough if we do technical work with sprints?
We will say it plainly: with sprints, estimates and a dozen statuses, Jira is the better home, and Asana stays where the non-technical teams work. Asana shines on repeatable work: a project template, dependencies between steps, one owner per task. You can also run both and wire them together, so a technical task has its counterpart in the client project.
Do we need Make or n8n when Asana has its own rules?
Not always. If all the work starts and ends in Asana, its own rules are enough and that is what we will tell you. An outside automation makes sense when the starting event sits in the CRM, in the shop or in the ERP, when data from that system has to land on the task, and when closing the task has to go back there as a status.
Let us look at how a project starts in your company today
The free consultation takes 30 minutes. You tell us what projects you run in Asana and what happens between signing the contract and the first task. We show you what can be fired from a template straight away, and what needs Asana itself tidied up first. You do not have to share any systems at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If anyone in your company created a project this week by duplicating the last one, that is exactly the problem. A plan copied by hand always loses one step and one owner, and it comes back a month later as overdue work. A template fired by machine has no way to forget, and you get back the day that goes into retyping today.