Overview

The iVendNext Trigger Node listens to your iVendNext tenant and starts a workflow the instant a chosen event occurs. Where the Action Node waits to be told what to do, the Trigger Node is proactive — it fires the moment a sale is made, an order is submitted, a stock figure changes, or any other nominated event takes place.

This article explains how the Trigger Node works, what events it can respond to, how to configure it, and how to combine it with the Action Node to build complete, event-driven automations.

---

What the Trigger Node Is For

Retail operations generate events continuously. A new order arrives; a supplier confirms a shipment; a customer record is updated; a stock level drops. In a manual world, someone monitors these events and acts on them. In an automated world, the Trigger Node monitors them instead — and reacts instantly, without delay and without the possibility of being overlooked.

The Trigger Node is always the first node in an event-driven workflow. It does not run when the workflow is manually triggered or when a schedule fires; it runs when iVendNext tells it that something has happened. That distinction — reactive rather than scheduled — is what makes it the right tool for real-time automations.

How It Works

When you add a Trigger Node to a workflow and activate it, the node registers a private notification inside your iVendNext tenant. This notification tells iVendNext to send a message to the workflow whenever the specified event occurs on the specified Document Type.

From that point on, whenever the event fires — without any polling, without any delay — iVendNext passes the document to the workflow. The Trigger Node receives it, and the rest of the workflow springs into action. Deactivate the workflow and, if the Auto Delete setting is enabled, the notification is cleanly removed from iVendNext.

No permanent connection between iVendNext and n8n is maintained. The notification mechanism is lightweight and event-driven at the iVendNext side, which means the Trigger Node imposes no ongoing load on either system during quiet periods.

The Seven Events

The Trigger Node can respond to any of seven event types. You choose the events that matter for your automation:

After Insert fires when a new document is created. This is the event to use when you want to react to something being added — a new order, a new customer, a new item. Use it for post-sale notifications, customer onboarding sequences, or new-stock alerts.

After Save fires whenever a document is saved, regardless of whether it is new or existing. It is a broad event that catches every modification. Use it when you need to react to any change on a document, and the specifics of what changed are less important than the fact that it changed.

On Update fires when an existing document is changed. Unlike After Save, which fires on every save including new documents, On Update fires only when a record that already existed is modified.

On Submit fires when a document is submitted — formally confirmed and moved to a read-only state in iVendNext. For transactional documents like Sales Orders and Purchase Invoices, submission is the moment of business significance: it is when an order is confirmed, when an invoice is finalised. Use On Submit for post-submission flows: push the confirmed order to a carrier, update a customer's account in a CRM, or trigger a payment follow-up.

On Cancel fires when a submitted document is cancelled — rolled back from its confirmed state. Use it for compensating actions: notify a carrier that a shipment is no longer needed, reverse a customer communication, or flag the cancellation for review.

Value Changed fires when a specific watched field changes its value. This is more targeted than After Save — it fires only when the field you are watching actually changes, not on every save. Use it to detect a price change, a status transition, or any field that represents a meaningful state shift in your business.

On Change / On Trash / Custom Method covers additional lifecycle moments for more advanced scenarios. These allow the Trigger Node to respond to document deletion and to custom methods defined in your iVendNext instance.

Configuration Settings

DocType is the Document Type to watch. The dropdown is loaded live from your tenant. Select the type whose events you want to listen for.

Trigger Name is a label for this specific listener inside iVendNext. It must be unique — if you have two triggers on the same DocType, give each a distinct name so they can be identified independently. A descriptive name like New Sale → ShipStation is easier to manage than a generic one.

Event is the event or events to react to. You select from the seven options described above. You can choose multiple events on a single Trigger Node if the automation should react to several moments in a document's lifecycle.

Auto Delete controls whether the listener registered in iVendNext is removed when you deactivate the workflow. With Auto Delete on, deactivating the workflow cleans up its notification automatically. Leaving it off keeps the notification in place across edits — useful when you are modifying the workflow and do not want the registration removed and re-created each time.

Respond Immediately (in Additional Options) tells iVendNext to receive an immediate acknowledgement when it delivers an event to the workflow, rather than waiting for the workflow to finish running before the acknowledgement is sent. This setting is recommended for all production triggers. Without it, iVendNext holds the connection open while the workflow runs, which can cause delays in the source system if the workflow takes time to complete.

What the Trigger Node Delivers

When the event fires, the Trigger Node outputs the full document that triggered it. The next node in the workflow can access any field from that document using n8n expressions. For a Sales Order trigger, the data includes the order name, customer, transaction date, grand total, status, and the full line-item table. For a Customer trigger, it includes the customer name, address, contact details, and any custom fields.

This means the first step after the Trigger Node already has rich data to work with. If the automation only needs data from the triggering document, the Action Node may not even be needed. If more data is required — for example, fetching the full customer record when a Sales Order arrives — the Action Node picks up where the trigger left off.

Combining Trigger and Action Nodes

The standard pattern for event-driven automations is: Trigger Node detects the event → one or more Action Nodes fetch or write related data → the workflow delivers the result.

A workflow that sends an order confirmation email might use a Trigger Node on Sales Order / On Submit, then an Action Node to Get the Customer record (to retrieve the email address), then an email node that composes and sends the message. The trigger provides the order; the action provides the customer; the email node delivers the outcome.

A workflow that synchronises stock to a webstore might use a Trigger Node on a stock balance DocType / After Save, then an HTTP Request node to push the updated stock level to the store's API. No additional Action Node is needed because the trigger delivers the stock data directly.

The flexibility of this pattern — varying the number and type of Action Nodes between the trigger and the outcome — is what allows the same fundamental connector to support a wide range of retail automation scenarios.

Trigger Reliability and Error Handling

If a trigger fires while the workflow is inactive, the event is not queued — it is missed. For automations where every event must be processed, the workflow must remain active. If there is a need to process events that occurred during a window when the workflow was inactive, a scheduled Get Many job on the Action Node can serve as a catch-up mechanism.

If a triggered workflow encounters an error partway through, the execution log in n8n records exactly what happened and at which node. Combined with the Continue on Fail setting on Action Nodes, automations can be designed to handle partial failures gracefully — routing problem records to a review branch rather than dropping them.