Scripts (custom JavaScript injection)

Configure, test, and publish Global organisation scripts that run in Pages and can read organisation-level variables.

In this article, you'll manage the custom JavaScript that OmniLab can load in Pages from the Global organisation. Admins configure and govern these scripts centrally, while developers should write and review the code itself.

Technical authoring lives elsewhere

Need the implementation guide for the code itself? See Writing organisation scripts. This page focuses only on the admin workflow for adding, enabling, and governing scripts.

Prerequisites

You have admin access to the Global organisation.
The script code has been validated by the right technical owner.
You have a staging or test environment available.
You know how to disable the script quickly if it causes issues.

How scripts behave

Scripts are configured only in the Global organisation, but they can still read values from the current organisation. That means one global script can adapt to each organisation by reading window.omnilab?.group?.configuration?.variables.

Script changes are applied to Pages only after the campaign is published again. If you save a script and do not republish the campaign, the live campaign continues to use the previous script version.

Field reference

Field	Values or example	Why it matters
Name	`Google Tag Manager loader`	Helps admins identify the purpose of the script quickly
Script Context	`All`, `Non iframe only`, `Iframe only`	Limits where the script should run
Trigger Event	`Visit`, `Registration`	Controls when the script is executed
Is Active?	`Yes` or `No`	Lets you disable a script without deleting it
Script Code	Custom JavaScript	Holds the script body that Pages will execute

Configure a script

Open the Scripts tab

Switch to the Global organisation, open General Settings, then select Scripts.

Scripts list in Enterprise Settings

Add a new script entry

Click Add Script, then complete the script form:

Name
Script Context
Trigger Event
Is Active?
Script Code

Script editor showing name, context, trigger, active flag, and code area

Save the configuration and choose the right scope

Choose the Script Context that matches where the script should run:

Script Context	Use it when
`All`	The same script should run in both iframe and non-iframe Pages
`Non iframe only`	The script should run only in standalone Pages, outside embedded iframe delivery
`Iframe only`	The script should run only when Pages is embedded in an iframe

The Trigger Event controls when OmniLab fires the script. Use Visit for page-load style tracking or setup that should happen as soon as Pages opens. Use Registration when the script should fire only after a registration step completes and visitor data is more likely to be available.

Publish the campaign before testing

After changing a script, publish the campaign you want to test. Saving the script configuration alone is not enough for live Pages to pick up the latest version.

Publishing matters

If you change a script and only save the Global organisation settings, the campaign will not receive that change yet. Publish the affected campaign again; otherwise the live experience keeps using the previous script version.

Test before enabling broadly

Enable the script in a safe environment first, then open representative Pages experiences for that organisation and verify that navigation, forms, consent, analytics, and CTA flows still work.

Enable, disable, edit, or remove as needed

Once validated, keep the script enabled only where it is required. If behaviour changes, update the script or disable it until the issue is understood.

Using organisation-level variables in scripts

One global script can still behave differently per organisation by reading values exposed on the OmniLab page object.

Most organisation-level variables use this shared prefix in the script:

Shared prefix for organisation-level variables

window.omnilab?.group?.configuration?.variables?.

Add one of these variable names after that prefix:

What you want to read	Variable name in script	Example result
Country	`country`	`France`
Local language override	`centerLanguage`	`French`
Locale code	`locale`	`fr_FR`
Region	`region`	`Europe`

Add a fallback in the script when you need one, for example centerLanguage || 'English' or locale || 'en_US'.

For example:

Common organisation variable expressions

window.omnilab?.group?.configuration?.variables?.country
window.omnilab?.group?.configuration?.variables?.centerLanguage || 'English'
window.omnilab?.group?.configuration?.variables?.locale || 'en_US'
window.omnilab?.group?.configuration?.variables?.region

Other useful values live outside the organisation variables object:

Other useful script paths

window.omnilab?.group?.uniqueKey
window.location.pathname

What you want to read	Example result
Current organisation key	`paris-centre`
Current page path	`/summer-experience`

Example scripts

Google Tag Manager base loader

Use this when your team wants GTM available before firing additional events.

Google Tag Manager loader

<script>
(function (w, d, s, l, i) {
  w[l] = w[l] || [];
  w[l].push({
    'gtm.start': new Date().getTime(),
    event: 'gtm.js',
  });
  var f = d.getElementsByTagName(s)[0],
    j = d.createElement(s),
    dl = l != 'dataLayer' ? '&l=' + l : '';
  j.async = true;
  j.src = 'https://www.googletagmanager.com/gtm.js?id=' + i + dl;
  f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'GTM-AB12C3D');
</script>

Page-view event with organisation variables

This pattern pushes a view event and enriches it with organisation-level variables.

Page-view dataLayer push

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'view_page',
  country: window.omnilab?.group?.configuration?.variables?.country,
  region: window.omnilab?.group?.configuration?.variables?.region,
  language:
    window.omnilab?.group?.configuration?.variables?.centerLanguage || 'English',
  locale:
    window.omnilab?.group?.configuration?.variables?.locale || 'en_US',
  page: window.location.pathname,
  page_type: 'Experience',
  organisation_key: window.omnilab?.group?.uniqueKey?.toUpperCase(),
  surface: 'Pages',
});
</script>

Registration event with `dataLayer.push`

Use this when you want to emit a conversion-style event after registration.

Registration dataLayer push

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'registration_complete',
  organisation_key: window.omnilab?.group?.uniqueKey?.toUpperCase(),
  country: window.omnilab?.group?.configuration?.variables?.country,
  locale:
    window.omnilab?.group?.configuration?.variables?.locale || 'en_US',
  page: window.location.pathname,
  registration_status: 'complete',
});
</script>

Keep analytics payloads generic

Prefer organisation, locale, page, and event context unless your measurement design truly requires more. If a destination expects transformed or filtered values, apply that logic inside your script before pushing it.

Meta Pixel registration trigger

Use this pattern when the base Meta Pixel is already present and you only need to fire an event from OmniLab Pages.

Meta Pixel registration event

<script>
if (typeof window.fbq === 'function') {
  window.fbq('track', 'CompleteRegistration', {
    organisation_key: window.omnilab?.group?.uniqueKey,
    country: window.omnilab?.group?.configuration?.variables?.country,
    locale:
      window.omnilab?.group?.configuration?.variables?.locale || 'en_US',
    page: window.location.pathname,
  });
}
</script>

Operational checklist

Verify the script does not block page load or user actions.
Check consent, form submission, reward flows, and redirects on real campaign paths.
Review DOM access and data collection carefully.
Keep version notes so you can trace what changed if something breaks.

Untested scripts can break Pages or leak data

Because these scripts run in the consumer-facing Pages context, a bad script can affect every campaign in the organisation. Always test before enabling in production.