Skip to main content

I have a zap that is working mostly great for a custom SQL Query to Asana tasks. Where I am having a problem is determining what is used as the trigger for a new row for when there is more than one task created in my SQL table. 

With the New or Updated Row zap step, you can indicate the trigger column, but for the custom query I want to pull data in from multiple tables. I essentially have an opportunity table and an opptask table, pulling in data from each. I’m pulling in a uniqueid column from opptask as well as the primary key columns (oppnum, tasknum) and I have an ORDER BY on CreateDate which is datetime. To rule out the question, this happens even if the createdate is a separate day entirely. 

When we create the first opp task it goes through the zap with no issue. But when we create an additonal task on the same opp, It does not even recognize as a new record. If I go into the edit mode and refresh new records in my SQL step, I do see the additonal task that will not trigger the zap when it’s published. Here is my query in case this helps:

SELECT ot.RowPointer --uniqueid
,TRIM(o.opp_id) AS opp_id --pkcolumn1
,ot.opp_task_num --pkcolumn2
  ,CASE ot.priority
WHEN 'H'
THEN '748674326485893'
WHEN 'L'
THEN '748674326485895'
ELSE '748674326485894'
END AS TaskPriority
,ot.opp_task_type
,ot.due_date
,COALESCE(o.prospect_id, o.cust_num) AS Account
,CASE c.cust_num
WHEN NULL
THEN 'Prospect'
ELSE 'Customer'
END AS AcctType
,COALESCE(p.company, ca.name) AS AcctName
,o.description
,o.Uf_Application
,o.Uf_Notes
,u1.emailaddress
,u1.userdesc
,u1.user_code
,u1.Uf_AsanaID AS AssignerAsanaID
,u2.userdesc AS AssignedTo
,u2.emailaddress AS AssigneeEmail
,u2.Uf_AsanaID AS AssigneeAsanaID
,ot.Uf_OppTaskCostType
,CASE
WHEN p.Uf_ProspectType LIKE '1%'
OR c.cust_type LIKE '1%'
THEN 'Window & Door Quotes'
WHEN p.Uf_ProspectType LIKE '6%'
OR c.cust_type LIKE '6%'
THEN 'Online Quotes'
ELSE 'OEM Quotes'
END AS Project
,CASE
WHEN EXISTS (
SELECT TOP 1 *
FROM LC_DT_MAP_mst
WHERE mod = 'Opportunities'
AND value_1 = o.opp_id
)
THEN 'Docs Attached'
ELSE 'No Docs'
END AS DocsExist
,ot.createdate
FROM opportunity_task_mst ot
INNER JOIN opportunity_mst o ON o.opp_id = ot.opp_id
LEFT JOIN customer_mst c ON c.cust_num = o.cust_num
AND c.cust_seq = 0
LEFT JOIN custaddr_mst ca ON ca.cust_num = o.cust_num
AND ca.cust_seq = 0
LEFT JOIN prospect_mst p ON p.prospect_id = o.prospect_id
INNER JOIN LAM_Users u1 ON u1.username = ot.createdby
INNER JOIN LAM_Users u2 ON u2.username = ot.OWNER
ORDER BY ot.createdate DESC

 

Hi @lamatekinc! 👋

It’s odd that it’s able to pull in the new opportunity tasks as new test records but not when the Zap runs live. All the SQL Server triggers are polling, rather than instant triggers so I wonder if there may just be a delay in it seeing the new row. 🤔

Polling triggers can take any where from 1 - 15 mins to trigger a Zap depending on the type of Zapier plan you’re on. So if, after creating the opportunity task, less than the allotted polling time for your plan had passed before you switched to edit mode and loaded in a new test record then that might explain why it didn’t trigger but you were able to pull it in as a new test record. Do you think that could be the case here? 

If so, can you try creating a new opportunity, then wait a bit longer this time to and let me know if it’s then able to trigger the Zap?

Looking forward to hearing from you on this!


Hi @lamatekinc! 👋

It’s odd that it’s able to pull in the new opportunity tasks as new test records but not when the Zap runs live. All the SQL Server triggers are polling, rather than instant triggers so I wonder if there may just be a delay in it seeing the new row. 🤔

Polling triggers can take any where from 1 - 15 mins to trigger a Zap depending on the type of Zapier plan you’re on. So if, after creating the opportunity task, less than the allotted polling time for your plan had passed before you switched to edit mode and loaded in a new test record then that might explain why it didn’t trigger but you were able to pull it in as a new test record. Do you think that could be the case here? 

If so, can you try creating a new opportunity, then wait a bit longer this time to and let me know if it’s then able to trigger the Zap?

Looking forward to hearing from you on this!

Hi Sam. Thank you for your response. I did allow for time to poll for this Zap and I’m not seeing the new record be picked up even after an hour. I will see other zap runs successfully in this time. Even if I do a published zap run manually it won’t pick up the record of this type. It only picks up the first opportunity task for each opportunity. It’s as if it’s using the column opp_id as a dedupe column. 


Thanks for getting back to me, @lamatekinc🙂

In that case I wonder if modifying the query to concatenate the opp_id and opp_task_num values together, to create a separate unique identifier for each task, might help to prevent it using the opp_idd as the dedupe column. For example, can you try something like this at the start of the query instead:

SELECT CONCAT(TRIM(o.opp_id), '_', ot.opp_task_num) AS opp_task_id,

Keen to help get this sorted so please let me know if that works any better! 🤞


Hi @SamB, thanks for the suggestion. I did want to avoid this solution since I’m using the Opp ID in the Asana task zap to directly link to the opp in our ERP but I will figure something else out. It seems it was looking at Opp ID as the unique identifier so by tagging the task number on it seems to address this issue. I can workaround the Opp ID problem. Appreciate the feedback. 

I can mark your post as the answer, but I do think there’s something not working quite right with this zap type. 

It seems to me that by specifying the opportunity_task table as the base table from which the others join, by starting the query with the unique id from that table, and by ordering by the table’s createdate that should be enough to satisfy the zap, especially when the record can be pulled from the test step. 


Reply