Feature Request: Manual "Save" button or batch update trigger for Webhooks (n8n automation)

[n2ojim]

Scope & Context

Example:

We are working on integrating Twenty with external automation workflows (like n8n or Make) via Webhooks to automatically generate or update specific fields based on user inputs. The ticket is about managing how and when data updates trigger webhooks when a user edits a record (e.g., Companies, People, or Custom Objects).

Current behavior

Currently, Twenty relies on an instant auto-save mechanism. Every time a user modifies a single field, the record is immediately saved to the database, and a record.updated webhook is dispatched instantly. If a user needs to update 3 different fields to provide the necessary context for an n8n automation, 3 separate webhooks are fired sequentially. The external automation is triggered on the very first field change, receiving incomplete data because the user hasn't finished filling out the other fields yet. This results in failed automations and unnecessary compute/credit usage on external tools.

Example:

We want to generate a custom ID based on 3 fields for a real estate agency : Type, type of contract, city + incremental number (VILLA-RENT-PARIS-0001).

Expected behavior

Users should be able to modify multiple fields and ensure the external webhook receives the full, completed state of the record in a single batch. We need a way to commit changes globally or trigger the webhook manually. This could be resolved in a few ways:

1. Manual Save Mode: A toggle or mode where auto-save is paused. The user edits all necessary fields, then clicks a manual "Save" button to commit all changes at once.
2. Custom Action Button: A dedicated button on the record view (e.g., "Run n8n Automation") that manually fires a webhook containing the current complete state of the record, rather than relying on the record.updated trigger.
3. Webhook Batching/Debouncing: A backend logic that groups multiple consecutive field updates on the same record within a short time window into a single webhook payload.

Technical inputs

Depending on the chosen path, here are some technical suggestions:

• For the Custom Action Button (Preferred CRM approach): Add a custom component in the record header. Create a new webhook event type (e.g., record.custom_action) that passes the entire record object when clicked.

• For the Manual Save Mode: Introduce an isEditing local state in the frontend. When active, hold the updateRecord mutations in an array/object instead of firing them onChange. When the user clicks "Save", dispatch a single bulk GraphQL/REST update.

• For Webhook Debouncing: Implement a debouncer (e.g., 2-3 seconds) in the backend webhook dispatcher service (nestjs queues) to aggregate update events on the same recordId before firing the external HTTP request.

[alibildir]

We've been hitting the same issue in production — every field blur fires record.updated, which floods downstream automations. Tracking the discussion here, I want to propose a fourth solution that addresses the root cause directly in the workflow builder rather than per-app workarounds.

Proposal — "Required fields" picker in trigger config

Extend the existing Record is updated trigger with a multi-select picker labelled "Required fields". The picker lists every field on the object (including app-extended ones), and the workflow is only dispatched when all selected fields are non-empty at the moment of evaluation. Empty fields → silent skip with a counter log, no error surfaced to the UI.

┌─ Trigger: Record is updated ──────────────────┐
│ Record type: [ Task ▼ ]                                    
│ Fields (optional): [ Title, Status ▼ ]                           
│ Required fields: [ Assignee ▼ ]   ← NEW             
│                                                                                
│  ▸ Workflow fires only if Assignee is set                         
│   (logic executed server-side at dispatch)                       
└──────────────────────────────────────────────┘

Why this works better than the three listed options

Listed option	Cost	Replaces with
Manual Save Mode	UX rewrite of the entire record editor + bulk update API	— (still valuable as a separate feature)
Custom Action Button	New component + new event type + admin must remember to click	Covered — required-fields acts as a debounce guard, button stays available for explicit firing
Webhook debouncing server-side	Reasonable middle ground but invisible to admins and hides bugs	Roughly equivalent — only auto-save events that pass the guard get through

The new picker reuses the existing trigger config UI, requires zero changes for users who don't enable it (backward compatible), and gives admins explicit control per workflow.

Design questions worth pinning down before PR work

1. Scope of the first PR: only Record is updated, or also created/deleted?
2. Behavior on partial save: today, every PATCH fires the trigger. With required-fields, an empty save is skipped; once the user finally fills the missing field, the next save will pass the guard and the workflow runs. Do we want anything more aggressive (e.g. delayed dispatch)?
3. Where to store the list: dedicated column on the workflow trigger row (required_field_metadata_ids uuid[]), or part of the existing JSON config?
4. Multi-step workflows: should required-fields be per-step, or only on the trigger step?
5. App-extended objects: apps add fields via defineField; the picker must include them too — appears automatically as long as the backend reads from fieldMetadata for the chosen object.

Rough implementation map:

• Backend packages/twenty-server/src/engine/core-modules/workflow/ — add required-field guard to the dispatcher, before action execution.
• Frontend packages/twenty-front/src/modules/workflow/components/workflow-trigger/ — multi-select picker bound to the trigger record.
• Migration: nullable column on workflow_trigger (or wherever the trigger config lives).
• Docs: update workflows guide with the new option and reference this discussion.

Happy to send a PR if maintainers agree with the direction, and I can scope the first PR down to just Record is updated + single trigger step if useful.

[BOHEUS]

@alibildir it's already implemented

[BOHEUS]

@n2ojim now it's possible to which fields updates workflow should listen in order to be triggered

[alibildir]

Thanks for pointing that out — I clearly missed that the existing "Fields (optional)" picker combined with Conditions already covers the trigger side. My bad on the framing.

The only remaining gap I see is ergonomic rather than functional: when a record has several required fields, admins currently have to add one Field is not empty condition per field. That scales poorly (e.g., a record with 8 required fields → 8 manually maintained condition rows), and it's easy to forget which fields are included when revisiting the workflow months later.

Would a small UX-only PR that consolidates N identical field is not empty conditions into a single multi-select picker (semantics untouched — still gates dispatch the same way) be welcome? Happy to scope it tight: backend-only support first, frontend picker in a follow-up, scoped to Record is updated only.

If maintainers prefer to keep the current UX, that's fair and I'll close this out.