How settings work across campaigns and touchpoints

See where each setting applies so you can predict how most Platform options behave.

Predict how almost any OmniLab setting behaves by spotting which of four simple behaviours it follows. Once you recognise the behaviour, you know whether to set it once, per touchpoint, or build it once and reuse it.

Why this matters

You do not need to memorize every settings page. Once you know how a setting behaves, the screen becomes easier to read and the scope decision becomes obvious.

Off, campaign-wide, or per touchpoint

Some settings give you three choices, and only one applies at a time:

  • Disabled: the setting is off. Use this when the feature is not needed.
  • Campaign Level: one configuration applies to the whole campaign. Use this when you want the same setup everywhere.
  • Touchpoint Level: each touchpoint is configured separately. Use this when touchpoints need different setups.

The default is Disabled. When you switch to Touchpoint Level, there is no fallback to the campaign setting — each touchpoint needs its own complete configuration.

You see this behaviour most clearly in:

The labels are not always identical. In Opt-in, this appears as a scope choice. In Notifications, the same idea appears as Global versus by Touchpoint.

Campaign default, with touchpoint exceptions inside limits

Some settings start with a campaign-wide default. Touchpoints inherit that default but can override it, only inside a boundary the campaign sets.

The clearest example is dates. Campaign dates define the overall operating window. A touchpoint can set its own dates, but only inside that window — it cannot run before the campaign starts or after it ends.

Use this when you want one campaign timeline with a few controlled exceptions, rather than a fully separate timeline per touchpoint.

Campaign-only, with no touchpoint override

Some settings are configured once for the whole campaign and cannot be overridden per touchpoint.

The main example is the Acquisition form. The reason is consistency: subscription and consent collection should stay the same across the whole campaign, not change from one touchpoint to the next.

When a setting works this way, there is no "should I do this per touchpoint?" decision to make. It is campaign-wide by design.

Some things are created once at campaign level, then linked to the touchpoints that should use them. This separates creating the item from using it.

This applies to reusable campaign items such as:

When you update the shared item, every linked touchpoint sees the update. Some items, especially rewards, can still be limited to specific touchpoints or to specific parts of a campaign experience through restriction rules.

Which behaviour am I looking at?

Use this quick guide when you are unsure:

  • If the choice is off, campaign-wide, or per touchpoint, it is the first behaviour above.
  • If the campaign sets a default that touchpoints can override only inside campaign limits, it is the second.
  • If the setting must stay the same for the whole campaign, it is the third.
  • If you create something once and then attach it where needed, it is the fourth.

A setting follows one behaviour at a time — they are not mixed inside a single setting.

Quick reference

SettingHow it behavesDefault stateWhere you'll find it
Opt-inOff, campaign-wide, or per touchpointDisabledSettingsTerms & Conditions Settings
Participation FormOff, campaign-wide, or per touchpointDisabledSettingsParticipation Form
NotificationsOff, campaign-wide, or per touchpointDisabled per notification typeNotifications
DatesCampaign default with touchpoint exceptionsCampaign dates apply everywhereSettingsCampaign Dates Settings
Acquisition formCampaign-onlyOff until enabledFormsAcquisition form
RewardsBuild once, then linkNot usable until created and linkedRewards
BadgesBuild once, then linkNot usable until created and linkedTouchpointsGamification

Was this helpful?

Optional comments help us improve this page for future authors and readers.

On this page