A client submits an intake form in your app. The next step is usually operational: create a project, update a CRM, or notify the person doing the work. Use Fillo's n8n community node to start that workflow from an accepted response.

Import a working review queue

Download the n8n workflow JSON and its Postgres setup SQL. The workflow saves one review item per response, accepts later edits, and records delivery IDs in the same database transaction. It contains no credentials, pinned responses, or live form IDs.

Install n8n-nodes-fillo in an n8n instance that permits community packages. This export was tested with n8n 2.40.5, n8n-nodes-fillo 0.1.0, and Postgres 18.
Run the setup SQL once in your destination database. Use a dedicated database role with access to the fillo_intake schema, its two tables, and accept_response; don't connect n8n as a database administrator.
Import the workflow JSON. Open Fillo Trigger, select your Fillo API credential, and choose the published intake form. Open Save intake atomically and select your Postgres credential.
Publish the workflow, submit one fictional response, and inspect fillo_intake.review_queue. Both Response Created and Response Updated are enabled in this export.

The queue keeps answers, protected file references, and a review_status initially set to new. Your team can change that status; a response edit preserves it. Newer updated_at values replace the answer snapshot. Older or equal timestamps do not overwrite it. processed_occurrences records each delivery occurrence once, including a stale event that was safely ignored.

The Postgres node makes up to three attempts to write the response. The Fillo trigger acknowledges receipt immediately, before this write completes, so a later database failure does not cause Fillo to resend automatically. Enable failure monitoring for this workflow. After fixing the destination, retry the failed execution in n8n. The database transaction ensures that a failed write has not consumed the occurrence ID.

Successful execution data is not retained by this export; failed execution data is retained for recovery and can contain answers. Set execution pruning and database retention to suit the information you collect. Keep the occurrence journal for at least your intended replay window. The export stops at the durable queue: it does not send notifications, create projects, or download files. Give any additional side effect its own idempotency and recovery handling.

Build the intake form

Start with the Vite client-intake example. Publish the form, connect storage if it collects files, and verify one response in Fillo before adding automation. Stable field IDs make the mapping predictable when labels change.

Connect the trigger

Install n8n-nodes-fillo using your n8n instance's community-node installation flow. Your instance must permit community packages.
Create a Fillo API credential with a workspace API token. Keep this credential in n8n, never in browser code or workflow exports.
Add Fillo Trigger, select the published form, and choose Response Created.
Listen for a test event, then submit an authorized response to the form.
Inspect response_id, occurrence_id, event, answers, and files in the trigger output.

The n8n integration reference covers installation and the supported trigger and action operations. A sample response is useful for mapping fields; it is not evidence that a live delivery worked.

Map the work item

For another destination, add an Edit Fields (Set) node. Map response_id to an external response ID field and map the relevant values under answers to your destination's project title, contact email, and requested outcome. Inspect the actual output before choosing expressions: answer shapes depend on field kind.

Use response_id as the destination's upsert key. A second execution for the same response should update or find the existing work item, not create another client project. If you also subscribe to Response Updated, preserve that behavior and inspect the event value before sending a new-submission notification.

Handle retries before adding notifications

Fillo delivery is at least once. occurrence_id is stable across retries of one event; response_id identifies the response across its create and update events.

For a durable workflow, use your destination's idempotency key or a database with a unique constraint. Upsert the work item by response ID, record successfully processed occurrence IDs, and skip already completed occurrences. Mark an occurrence complete only after the required downstream work succeeds. A non-atomic “look up, then insert” check alone can race under simultaneous executions.

The community trigger exposes the body, not delivery headers. Don't build deduplication around a header that isn't present in its output. If cryptographic request verification is a requirement, use the signed webhook path and verify the raw body before any downstream side effect.

Fetch uploaded files

files[].url is protected. Use an HTTP Request node with the Fillo API credential to download a file, then pass the resulting binary data to a destination that accepts it. Forwarding the URL alone to an unauthenticated service won't grant access.

Keep the download inside the workflow and apply your own retention rules to any copies. Fillo's original file stays with the configured storage provider; n8n's execution data is a separate copy with its own lifecycle.

Prove the workflow before activating it

Submit one response and find exactly one destination record.
Replay its delivery and verify that the destination doesn't duplicate it.
If updates are enabled, edit the response and verify the same destination record is updated.
Break a test destination credential, inspect the failed execution, restore access, and retry it in n8n without asking the client to resubmit. A successful Fillo webhook delivery alone does not prove the database write succeeded.
Export only a sanitized workflow: remove credentials, pinned execution data, real email addresses, and private file URLs before sharing it.

Build the form with an agent, then wire the trigger to your team's destination.

Support intake example: Try an intake flow before connecting a destination.
Agent setup to first response: Verify the full publish and submit loop.

Route client intake through n8n