Hello,
I would like to create a zap from an Trigger event update of the Notion database but this does not exist for the Beta version.
Is it planned to have this functionality and if so when?
The latter is really important to all of your users.
Thanks in advance.
Add my vote as well + I’d like to have an ETA… It’s been requested for a while now.
All I want is to send email when a property is updated
Could you add my vote as well and add me to the list of those who should be notified? Thank you!
Add me too please! I don't need to say it again - Zapierr is useless for Notion without this trigger. And an ETA would be only be polite given the demand
Another upvote here, as mentioned before. Becoming blocked by this missing Notion trigger in my usage of Zapier.
How can this take so long? Please add me to the list as well.
+9
Hey friends, apologies for the belated update. We appreciate your patience!
I double checked and it does look like this trigger is available for the Notion app.
Keep us in the loop with any questions you may have!
Hey friends, apologies for the belated update. We appreciate your patience!
I double checked and it does look like this trigger is available for the Notion app.
Keep us in the loop with any questions you may have!
Thanks. It’s definitely a step in the right direction.
I’m afraid, we need the solution to be a bit more detailed. Let me make an example to illustrate this:
tl;dr: Just “Database item update” is not specific enough. We need to be able to exactly select *what property* is updated inside a database item.
+9
Thanks for the feedback! And you’re right I can imagine that being a common scenario.
I wonder for these use cases where we need to be more granular if a Filter by Zapier step would work? A very similar workflow came up yesterday and they were using a filter to only trigger on a specific property:
Let us know if you think that could work! 🙂
Thanks for the feedback! And you’re right I can imagine that being a common scenario.
I wonder for these use cases where we need to be more granular if a Filter by Zapier step would work? A very similar workflow came up yesterday and they were using a filter to only trigger on a specific property:
Let us know if you think that could work! 🙂
Hallelujah. This is actually a great workaround (though uses one more step). Will be testing extensively. Thank you for the update, I never thought I’d actually see the day.
I wonder for these use cases where we need to be more granular if a Filter by Zapier step would work? A very similar workflow came up yesterday and they were using a filter to only trigger on a specific property:
Let us know if you think that could work! 🙂
It won’t work in general case. To determine which fields were changed you need to know their values before the update. But Updated Database Item event doesn’t give you the previous values, just the current ones.
I wonder for these use cases where we need to be more granular if a Filter by Zapier step would work? A very similar workflow came up yesterday and they were using a filter to only trigger on a specific property:
Let us know if you think that could work! 🙂
It won’t work in general case. To determine which fields were changed you need to know their values before the update. But Updated Database Item event doesn’t give you the previous values, just the current ones.
I wrote a Zap and tested it today using the filter method and Notion’s Status field. One weird thing I discovered is that the “Status” property type doesn’t show in the properties when pushed to Zapier. As a workaround, I added a Formula field with “prop(“Status”)” to duplicate the status as text into the formula field. This comes across fine via API.
So my flow is: User changes status → Notion formula field auto-updates → Zap is triggered on status update → Whatever I want Zapier to do (in my case, Discord notification)
In testing it seems to work fine (around 1.5min delay, but usable)
+14
Notion Zap triggers are “scheduled” (via API polling) and are not instant (via webhooks).
Scheduled app triggers can take from 1-15 minutes to trigger depending on your Zapier plan.
Notion Zap triggers are “scheduled” (via API polling) and are not instant (via webhooks).
Scheduled app triggers can take from 1-15 minutes to trigger depending on your Zapier plan.
Yep, they even have a notification for that when building the Zap. I have absolutely zero issues with that kinda delay. Just like we talked about on Twitter, it’s how Make has been doing things. Glad Zapier was able to implement!
I wonder for these use cases where we need to be more granular if a Filter by Zapier step would work? A very similar workflow came up yesterday and they were using a filter to only trigger on a specific property:
Let us know if you think that could work! 🙂
It won’t work in general case. To determine which fields were changed you need to know their values before the update. But Updated Database Item event doesn’t give you the previous values, just the current ones.
After further testing the limitations, Basil is correct. For example, I tried creating a “change log” of what users edited what things in a Notion database. While I can create “User X changed something about entry Y”, it is currently not possible to specify what specifically was changed.
For example, if I want to know what sales rep closed a deal, I can create a Zap with the trigger “Updated Database Item” and the filter to only trigger if “Deal Stage = Closed”. However, if a sales rep were to go back and change any field for a deal that is already in the stage “Closed”, the Zap will also run. It’s not actually looking for a change in Deal Stage, just checking to see if the field matches the filter. So unfortunately I will end up with a lot of erroneous “Closed Deals” that are really just deals being updated in other ways.
On the other hand, I have found that this works well for empty fields that require a date input to log when a specific change was made.
One of Notion’s shortcomings is that it cannot timestamp when changes occur at the field level. Using the above example of closed deals, I created a new date field in Notion called “Closed Date”. In my Zap, I have the trigger set to “Updated Database Item” followed by two filters.
Filter #1: if “Deal Stage = Closed”
Filter #2: If “Closed Date = Does not exist”
This way, the Zap will trigger the first time the Deal Stage is changed to closed, but will not continue updating the closed date on consecutive edits to that deal.
The real killer update from Notion would be the ability to have field-level update triggers. However, this is a step in the right direction as now I can capture dates of changes that I wasn’t able to capture before.
I wonder for these use cases where we need to be more granular if a Filter by Zapier step would work? A very similar workflow came up yesterday and they were using a filter to only trigger on a specific property:
Let us know if you think that could work! 🙂
It won’t work in general case. To determine which fields were changed you need to know their values before the update. But Updated Database Item event doesn’t give you the previous values, just the current ones.
After further testing the limitations, Basil is correct. For example, I tried creating a “change log” of what users edited what things in a Notion database. While I can create “User X changed something about entry Y”, it is currently not possible to specify what specifically was changed.
For example, if I want to know what sales rep closed a deal, I can create a Zap with the trigger “Updated Database Item” and the filter to only trigger if “Deal Stage = Closed”. However, if a sales rep were to go back and change any field for a deal that is already in the stage “Closed”, the Zap will also run. It’s not actually looking for a change in Deal Stage, just checking to see if the field matches the filter. So unfortunately I will end up with a lot of erroneous “Closed Deals” that are really just deals being updated in other ways.
On the other hand, I have found that this works well for empty fields that require a date input to log when a specific change was made.
One of Notion’s shortcomings is that it cannot timestamp when changes occur at the field level. Using the above example of closed deals, I created a new date field in Notion called “Closed Date”. In my Zap, I have the trigger set to “Updated Database Item” followed by two filters.
Filter #1: if “Deal Stage = Closed”
Filter #2: If “Closed Date = Does not exist”
This way, the Zap will trigger the first time the Deal Stage is changed to closed, but will not continue updating the closed date on consecutive edits to that deal.
The real killer update from Notion would be the ability to have field-level update triggers. However, this is a step in the right direction as now I can capture dates of changes that I wasn’t able to capture before.
Don’t listen to the last part of what I said. Come to find out, Filter #2 is not working as described on Zapier’s page about using filters. It turns out “Closed Date = Does not exist” is literally looking to see whether or not that field exists, not whether or not it has data in it. See the recent comments on this thread.
As a result, my actions on Zapier have been significantly eaten through as fields were updated that should not have passed the second filter.
Screenshots for reference. The first screenshot shows that there is data in the “Closed Date” field. The third screenshot shows that the filter for “does not exist” is still passing despite there being data.
+14
You shouldn’t need 2 Filters.
1 Filter with 2 conditions will work.
That will also save 1 Task.
Also, the value would be Closed Date start, instead of Closed Date, as start is a property of Closed Date that has the actual value.
So the Filter was actually working as expected, because there is no value for Closed Date, thus Closed Date does not exist.
You shouldn’t need 2 Filters.
1 Filter with 2 conditions will work.
That will also save 1 Task.
Also, the value would be Closed Date start, instead of Closed Date, as start is a property of Closed Date that has the actual value.
So the Filter was actually working as expected, because there is no value for Closed Date, thus Closed Date does not exist.
“Closed date start” is not an option when selecting fields for filtering.
You shouldn’t need 2 Filters.
1 Filter with 2 conditions will work.
That will also save 1 Task.
Also, the value would be Closed Date start, instead of Closed Date, as start is a property of Closed Date that has the actual value.
So the Filter was actually working as expected, because there is no value for Closed Date, thus Closed Date does not exist.
“Closed date start” is not an option when selecting fields for filtering.
Apologies, I did find it after all. You have to search by “Start”. Thanks also for the recommendation on two filter statements in one step. I’ll do some more testing this afternoon and hopefully it will work.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
