Hey all!
After using Baserow for many months in different areas of the company and often using the webhooks we think it would be nice to be able to apply a filter per webhook. That is, that the webhook only fires when a specific field changes, when a field includes a word, when a field is not empty, etc…
Thank you for your time reading this and for developing a really good solution that helps a lot of companies.
Thank you for your kind words about Baserow, Guillermo.
I noted your feature idea and it’ll be discussed with the team 
Without a shadow of a doubt, this functionality would be more sensational than spending a day at the beach after hours of focused work… kkkk 
Jokes aside, its implementation is really interesting, as it would save a lot of time because we don’t have to resort to another one automatically in n8n for example to do it.
Noted 
Thanks for your feedback @alessandrobarros and welcome to the Baserow community 
Hello @guiolmar and @alessandrobarros 
I have some great news for you! The team has agreed that adding filters on webhooks would be an extremely useful addition. To simplify its technical implementation, we are going to allow webhooks for specific views only.
Hi, I am just looking for a feature like this. Has this been implemented already?
I would like to change the status of a column and trigger an webhook in make.com. How can I do this?
Hello @artoflogic , first of all, welcome to the Baserow community!
This feature is not available yet. I’ll check with the team on its priority and will get back to you on this.
@frederikdc could you please help with this request?
Currently, what am doing is that I fire the webhook to all automation, then one every automation inside makes has a filter and compares if its the right action, and if yes triggers the workflow.
In my view, the webhook inside Baserow is incomplete. You would need to allow more fine-tuned conditions when exactly the webhook is triggered. Updating any row in a table, is simply too wide a criteria.
It would be great if you could provide that. Would love to use this everywhere afterward.
There is at the moment no functionality that checks which field has triggered the webhook. So the only option is indeed to compare against the previous value to see if the field has been modified.
Yes, I am doing this and it works. Nevertheless, you should provide filters when to trigger the Webhook in side Baserow. There is no reason not to do this.
Hello Baserow Community,
I’m writing to express my strong support for the proposed enhancement of adding conditional triggers to webhooks. As someone who frequently updates a status field in my database, I find the need for a webhook to only fire for a specific status of one field—representing less than 1% of the updates of the table rows—crucial for efficiency.
By implementing conditional triggers, we can precisely control when webhooks activate, significantly reducing unnecessary data processing and enhancing workflow management. This feature would be particularly valuable for those of us managing databases where only specific updates are critical to trigger further actions.
Thank you to those who proposed this. I fully support its implementation and look forward to seeing how it can improve our Baserow experiences.
Thanks for explaining your use case, @cecizu. We’ll take it into account!
Hey @guiolmar @artoflogic @alessandrobarros @cecizu
Just wanted to share a small update on this request. We’re definitely going to implement the feature to be able to add filters on webhooks, but as we plan to start working on the workflow builder as a new product in Baserow, this feature will already be a part of that module. Plus, with the new product, you’ll be able to build even more advanced automations. More details can be found here:
But if we see that it’s a blocking feature for many users, we will revisit the request to try to squeeze it into the pipeline. We hope for your understanding! 
Hi @olgatrykush ,
Thanks for replying.
I am not sure what the problem is. All you have to do is add one additional condition in the filter that the webhook is only triggered if a specified COLUMN is updated. This is not a big thing to program. Its one dropdown field and one if condition to to add.
The problem is that your webhooks are triggered too often, and this leads Make.com blocking your API calls and deactivating the webhooks in Baserow. This is very cumbersome and buggy at the moment as then we have to spend time debugging this only to find out that the webhooks in Baserow were deactivated. If we could trigger the webhooks more selectively, we would not be blocked by Make.com all the time.
We are using Make.com for automation and they offer lots of features and integrations. You should first try to make the Make integration work flawlessly as this offers the most value and builds a use case for using Baserow. Without this integration available, we wouldn’t use Baserow to be frank. The more automations we can use in Make.com the bigger the need for more database rows in Baserow.
Your automation builder sounds like a nice idea, but the current standard for automation is Make.com. We are happy to test your automation builder at a later stage but we need a solution now, not in 2 months. Thank you.
Thanks for the feedback @artoflogic, I’ve shared it with the team to check.
Hi @artoflogic,
First, thank you for your interest in Baserow. I understand that you’re being blocked by the fact that Make is deactivating the webhook when it’s triggered too often. Have you already been in contact with Make about maybe increasing the limit for you, or perhaps you can consider using the “Watch Created Rows” trigger to reduce the individual requests made to Make?
An alternative solution could be for you to write a small proxy in between the Baserow webhook and Make that checks if the old value matches the new value. This could even be done by another automation tool like n8n for example.
I realize that it sometimes looks easy to build a specific feature, even if it looks like just adding a dropdown. In this case, it might actually be more work than it looks. We would probably not just want to add a dropdown because the next question that comes is about use case where it’s about multiple columns updated instead of just one.
We would need to store this state in the backend, we would need to write automated tests to make sure it doesn’t break in the future, we would have to implement a system about what happens when a field is deleted, make the change so that we compare old and new value, which for more complicated data structures might not be as simple as it looks. All that code must be reviewed by another developer. It easily takes two days or so.
We would welcome an open-source contribution for this feature if you’re looking to expedite the process. I’ll make sure the code is reviewed with priority in that case.
Best, Bram
CEO Baserow
Hi @bram,
Thanks for replying.
I am not interested in “Watch Created Rows” as then I cannot capture all the workflows I have in mind in a single table… I am interested in working with existing rows and run several automation that trigger actions on the existing table, create rows or update rows on other tables and build a fully integrated and inter-linked database system
What you mention are workarounds that only add complexity and additional risk for us. I don’t want to complicate things. I can ask to increase the limit at Make but I am intending to create and link so many tables in Baserow, I will just run into the next limit because every update will trigger 10-20 webhooks in Make.com if I cannot filter the update column by criteria. I think Airtable has this feature, Baserow should have that as well.
You are complicating things. I don’t think you have to worry about filtering updating for multiple columns. Zero need for that. We really need a simple column filter because we need a single criterion to trigger an action. That probably works for 80% of your users, and the 20% probably who want to create headaches with multiple-column updates will have to wait a little bit. It is really very simple to do, and it would really solve a big headache for us.
Otherwise, Baserow we really like it, and we like to make the best use of it. I am going to teach my whole team how to use Baserow. So I count on you to keep adding useful features that make my life easier and not more difficult. Thank you
Hi @artoflogic,
I can understand your reasoning to why you would like to keep things simple. I know the codebase of Baserow very well, and this will not be a quick thing to change. We always have to keep in mind the potential use cases of other users, and would need to allow selecting more than one field.
Would you be open to upgrading your Baserow workspace to a yearly advanced plan for your whole team? I’ve discussed it with our team, and we would be willing to prioritize this feature in that case.
Hi @bram , I have subscribed to a monthly Premium Plan to show you that we are interested. We are testing all this first before we spend more money. Hope that catches your attention. Cheers
Hi @artoflogic, I appreciate that you subscribed to the premium plan, but a couple of users on a monthly premium plan is not enough. If you’re for example with 10 users, it’s a 50 USD commitment. That is not enough for us to prioritize this feature.