Fluxyn Docs
Tutorials

Runtime Blockers and Bypass Events

Pause normal event processing until your page is ready, then release the queue on purpose.

Use runtime blockers when your page should not process normal events immediately.

Common reasons include:

  • consent has not loaded yet
  • another vendor has not finished booting
  • your own business logic decides when tracking can start

Consent and blocker

Let a bypass event update consent and release the runtime blockers.

Configured properties

Update Blocker

Utility

action
action
release
targetBlockers
targetBlockers
[
  "consent"
]

How the pattern works

  1. Configure Runtime Blockers in the application settings.
  2. Configure Bypass Events for the control-plane events that should still run while blocked.
  3. Let normal event pushes queue.
  4. Use a bypass-event flow to update consent or other readiness state.
  5. Use Update Blocker to release the blocker.

Important behavior

  • Eventless dataLayer.push({ ... }) updates still merge into page state while blocked.
  • Event pushes with an event key queue unless they are bypass events.
  • Queued events replay in order once all blockers are released.

What to watch out for

  • Keep bypass events small and intentional.
  • Do not use a blocker unless you really need ordered delayed processing.
  • If your queue fills up, later blocked events will be dropped until space becomes available again.

Use Consent Categories

Keep Fluxyn informed about consent so gated logic behaves correctly.

Create and Use a Custom Node

Build a reusable node for vendor logic or repeated multi-step behavior.

On this page

How the pattern worksImportant behaviorWhat to watch out forRelated guides