# Bug with Rows Updated webhook

**URL:** https://community.baserow.io/t/bug-with-rows-updated-webhook/12457
**Category:** Technical Help
**Created:** [May 27, 2026, 2:16pm UTC](https://community.baserow.io/t/bug-with-rows-updated-webhook/12457 "2026-05-27T14:16:28Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![monachus](https://community.baserow.io/user_avatar/community.baserow.io/monachus/32/3904_2.png) [@monachus](https://community.baserow.io/u/monachus)
#### Post date: [May 27, 2026, 2:16pm UTC](https://community.baserow.io/t/bug-with-rows-updated-webhook/12457/1 "2026-05-27T14:16:28Z")

</div>

### Are you using our SaaS platform ([Baserow.io](http://Baserow.io)) or self-hosting Baserow?

Self-hosted

### If you are self-hosting, what version of Baserow are you running?

2.2.2 (why does this field have to be 10-characters or longer when your version numbers are not?)

### If you are self-hosting, which installation method do you use to run Baserow?

Docker 29.1.1

### What are the exact steps to reproduce this issue?

1. create a webhook to fire on `Rows are updated` and set it to monitor a boolean field
2. change that boolean field from `false` to `true` in baserow via n8n (webhook fires)
3. update the boolean field again (setting `true` to `true`)
4. webhook triggers with “Rows are updated” even though no data changed

I would expect that “Rows are updated” means “data in the row has changed from A to B.” Poking a field with the exact same value (setting `true` to `true`) is not an update and should not trigger the webhook.

I know that I can compare old\_items and new\_items, but i shouldn’t have to do that. This isn’t an update.

### Attach screenshots, videos, or logs that demonstrate the issue.

 ![SCR-20260527-gwvm.png](https://community.baserow.io/uploads/default/original/2X/f/f4d2e4a37a958b8927127327dc2ef6cc108614c3.png) ![SCR-20260527-gxwi.png](https://community.baserow.io/uploads/default/original/2X/d/d425ba048abaa1bb4ccdf96afa89c18aa56b3d44.png)

---

<div class="post-metadata">

### Author: ![olgatrykush](https://community.baserow.io/user_avatar/community.baserow.io/olgatrykush/32/219_2.png) [@olgatrykush](https://community.baserow.io/u/olgatrykush)
#### Post date: [May 28, 2026, 9:56am UTC](https://community.baserow.io/t/bug-with-rows-updated-webhook/12457/2 "2026-05-28T09:56:51Z")

</div>

Hey @monachus 👋

> [@monachus](#):
>
> 2.2.2 (why does this field have to be 10-characters or longer when your version numbers are not?)

Thanks for pointing this out! I’ve changed the minimum length to 5 characters.

I’ve also forwarded your request to the dev team to take a look. 🙂

---

<div class="post-metadata">

### Author: ![olgatrykush](https://community.baserow.io/user_avatar/community.baserow.io/olgatrykush/32/219_2.png) [@olgatrykush](https://community.baserow.io/u/olgatrykush)
#### Post date: [May 29, 2026, 11:07am UTC](https://community.baserow.io/t/bug-with-rows-updated-webhook/12457/3 "2026-05-29T11:07:48Z")

</div>

Hey @monachus, I checked with the development team and this is the current behavior rather than a bug. The “Rows updated” webhook is triggered whenever an update operation is performed, even if the submitted values are identical to the existing values.

We agree that triggering webhooks when no actual data changes can be confusing, so we’ve created an issue to track potential improvements:

> <https://github.com/baserow/baserow/issues/5434>
>
> \### Feature description
> 
> Currently, row\_updated webhooks and automations are tri…ggered whenever an update operation is performed, even if the submitted values are identical to the existing values.
> 
> \### Examples
> 
> \- Create a webhook for "Rows updated".
> \- Set a boolean field "true".
> \- Update the same field with true → true.
> \- The webhook is triggered, despite no actual data change.
> 
> Expected behavior
> Only trigger row\_updated webhooks and automations when at least one field value actually changes.
> 
> Notes
> \- This is known behavior, not a bug.
> \- Changing it may be a breaking change because existing workflows could rely on the current behavior.
> \- Consider introducing this as an optional setting or part of a future redesign.

For now, if you need to detect real changes, you’ll need to compare `old_items` and `items` in the webhook payload.
