Application Settings

Application settings control which websites can use an application and how the browser runtime behaves once it loads.

What lives here

For the current web application flow, the important settings are:

• name and slug
• platform
• allowed origins
• trigger settings
• runtime settings

Name and slug

• The name is the human-readable label used in Studio.
• The slug is the stable identifier created when the application is created.
• In the current UI, the slug cannot be changed later.

Platform

Web is the primary implemented platform today.

The UI also shows mobile and server-side options, but those are still positioned as future-facing compared with the current browser runtime path.

Allowed origins

Allowed origins restrict which domains can send events to this application.

Use them when:

• one application should only run on specific domains
• you want to prevent accidental cross-site usage

Notes:

• leave the list empty to allow all origins
• wildcards like *.example.com are supported in the UI copy
• this controls application usage, not flow logic

Trigger settings

Trigger settings define the built-in browser listeners the runtime should prepare for this application.

Current trigger areas in the product:

• scroll depth
• click tracking
• element visibility
• history change
• timer
• JS error tracking

What they do:

• they configure built-in browser signals like tf.click or tf.scroll
• they do not replace flows
• you still need trigger nodes in your flow if you want to react to those events

Examples:

• a click trigger node listens for tf.click
• a history trigger node listens for tf.history_change
• a timer trigger node listens for tf.timer

Runtime settings

Runtime settings are application-level control-plane settings for event processing.

Current settings:

• Runtime Blockers
• Bypass Events
• Blocked Event Queue Cap

Use these when the runtime should wait for some readiness signal before normal events run.

Runtime blockers

Blockers are named holds such as consent or app_ready.

While blockers are active:

• bypass events still run
• normal events queue in memory
• eventless page-state pushes still merge immediately

Bypass events

Bypass events are event names that should still run while blockers are active.

Common examples:

• consent-ready events
• app-ready events
• internal control-plane events

Blocked event queue cap

This limits how many blocked events are kept in memory before newer blocked events are dropped.

A simple rule of thumb

• If your page can process events immediately, keep runtime settings simple.
• If another system must be ready first, use blockers and bypass events.
• If you do not need a built-in browser listener, do not rely on its trigger family in your published flows.

Related guides

• Runtime behavior
• Runtime blockers and bypass events