Fluxyn Docs
Core concepts

Triggers

Triggers are the entry points into a flow. They decide when execution should begin.

Triggers are how Fluxyn knows that something worth reacting to has happened.

Some triggers listen to explicit event names. Others listen to browser behavior such as clicks, route changes, visibility, or timers. In both cases, the job of the trigger is simple: decide whether this event should start the flow.

The Trigger Strategy

The cleanest event architectures separate two questions:

  • What happened?
  • What do we want to do about it?

The trigger handles the first question. The rest of the flow handles the second.

Implicit vs. Explicit Triggers

Fluxyn supports two main styles of triggering.

Explicit Event Pushes

If your site already pushes events into window.dataLayer, Fluxyn can listen to those names directly.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "add_to_cart",
  product_sku: "XYZ-123",
  value: 49.99
});

This is the best fit for the Event Trigger node.

Use explicit event pushes when:

  • the product already emits meaningful business events
  • you want stable event names that many flows can reuse
  • you want the site to stay in control of when an event exists

Implicit System Handlers

Fluxyn can also attach built-in listeners at the application level.

Examples include:

  • click tracking
  • history changes in single-page apps
  • element visibility
  • scroll depth
  • JavaScript errors
  • timers

Some built-in event names also use the fx. namespace, such as fx.init, and can be listened to with an Event Trigger when that is the right modeling choice.

Choosing the Right Trigger

Use:

  • Event Trigger when your site already pushes a business event
  • Click Trigger when you need selector-based click tracking
  • History Change when you care about SPA route changes
  • Element Visibility when something must be seen, not just clicked
  • Timer Trigger when the page needs recurring checks
  • JS Error Trigger when you want runtime failures to become trackable events

Why This Matters

Good trigger design makes the rest of the flow smaller, more reliable, and easier to debug. A vague trigger causes noise. A precise trigger gives the rest of the flow clean input and keeps your runtime work focused on events that actually matter.

On this page