Skip to content

Events

Events are the starting point of every ECA model. An event represents something that happens on your Drupal site -- a trigger that tells ECA to begin processing. Without at least one event, an ECA model has nothing to respond to.

What is an event?

In Drupal, events are signals dispatched by the system whenever something noteworthy occurs. ECA listens for these signals and, when one matches a model's configuration, starts processing the associated conditions and actions.

Think of events as the "when" in the sentence: "When this happens, check these conditions, then do these actions."

Common event categories

ECA provides events across many categories. Here are some of the most frequently used:

Content events
Triggered when content entities are created, updated, deleted, or viewed. Examples include Presave content entity and Insert content entity. For details on entity lifecycle ordering, see Entity events.
User events
Triggered by user-related activities such as logging in, logging out, or account creation.
Form events
Triggered during form operations -- building, validating, or submitting a form. See Build form for an example.
Cron events
Triggered at scheduled intervals when Drupal's cron runs, useful for periodic tasks.
Custom events
Events you define yourself, triggered explicitly from within an ECA model using the Trigger custom event action. See Custom events for details.
Request/response events
Triggered during the HTTP request lifecycle, allowing you to intercept and modify requests or responses. See Choosing the right request and response events.

Discovering available events

The full list of events available on your site depends on which modules are installed. Browse the Plugins section for a comprehensive reference of all events, organised by module.

How events work in ECA

When Drupal dispatches an event, ECA checks whether any enabled models are listening for that event. If a match is found, ECA begins processing:

  1. The event fires and ECA receives it.
  2. ECA identifies all models subscribed to that event.
  3. For each matching model, ECA follows the connections from the event to its successors -- evaluating conditions and executing actions.

A single event can be used in multiple models, and a single model can listen for multiple events.

Tokens provided by events

Most events automatically make certain tokens available for use in subsequent conditions and actions. For example:

  • Entity events provide the related entity as entity and also under its type name (e.g. node, user).
  • Form events provide the form as form and current_form.
  • The tokens user and current_user (the current user entity) are always available regardless of the event type.

Refer to each event's documentation page for details on which tokens it provides.

Adding an event to a model

Every ECA model needs at least one event. How you add one depends on which modeler you use:

Workflow Modeler

  1. Open or create a model at Configuration > Workflow > ECA.
  2. From the toolbar or canvas, add an Event node.
  3. Select the event type from the categorised list.
  4. Configure the event's settings in the side panel (e.g. which content type, which form ID).
  5. Connect the event to conditions or actions using edges.

BPMN.iO

  1. Open or create a BPMN.iO model.
  2. Click the Start Event circle on the canvas (or drag one from the palette).
  3. Use the wrench icon to change the event type, then select the ECA event from the configuration panel on the right.
  4. Configure the event's settings in the properties panel.
  5. Draw sequence flows from the event to subsequent tasks or gateways.

Classic Modeler

  1. Open or create a model using the Classic Modeler.
  2. Use the form interface to add an event by selecting from the available event types.
  3. Fill in the configuration fields.
  4. Connect the event to conditions and actions using the form-based interface.

Tips for working with events

  • Be specific: Choose the most specific event for your use case. For example, use a content type-specific event rather than a generic "any entity" event to avoid unnecessary processing.
  • Mind the execution order: If multiple models listen for the same event, they all run. Use conditions to guard against unintended side-effects.
  • Check token availability: Before referencing a token in a condition or action, ensure the event (or a preceding action) makes that token available. See Debugging for techniques to inspect available tokens at runtime.
  • Performance: Every event subscription adds a small overhead. Disable models you are not actively using.