How settings work across campaigns and touchpoints

OmniLab configuration follows four patterns. Each object, such as opt-in, notifications, dates, rewards, or forms, behaves according to one of them. Understanding these patterns up front makes most Platform settings much easier to predict.

Pattern A - Three-state

Pattern A gives you three mutually exclusive states:

• Disabled: the feature is off.
• Campaign Level: one configuration applies to the whole campaign.
• Touchpoint Level: each touchpoint is configured separately.

The default state is Disabled. When you move to Touchpoint Level, there is no fallback to the campaign setting. Each touchpoint needs its own complete configuration.

You see this pattern most clearly in:

• Opt-in
• Participation Form
• Notifications

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

Pattern B - Campaign default with bounded touchpoint override

Pattern B starts with a campaign-wide default. Touchpoints inherit that default, but they can override it inside a safe boundary defined by the campaign.

The clearest example is dates. Campaign dates define the overall operating window, and a touchpoint can override its own dates only inside that campaign range. A touchpoint cannot run before the campaign starts or after the campaign ends.

Use this pattern when you want one campaign timeline with controlled exceptions, not a fully separate configuration model per touchpoint.

Pattern C - Campaign-only

Pattern C is configured once at campaign level and does not allow a touchpoint override.

In the current Platform model, the main example is the Acquisition form. The reason is consistency: subscription and consent collection should stay coherent across the whole campaign instead of changing from touchpoint to touchpoint.

If a setting follows Pattern C, there is no "should I do this per touchpoint?" decision to make. The answer is already campaign-level by design.

Pattern D - Library plus link

Pattern D separates creation from usage. You create an object once at campaign level, then link it to the touchpoints that should use it.

This pattern is used for reusable campaign objects such as:

• Rewards
• participation form schemas
• assets used by campaign experiences
• validation code pools
• Gamification badges

When you update the library object, every linked touchpoint sees the updated version. Some objects, especially rewards, can still be limited to specific touchpoints or to specific items inside a campaign experience through restriction rules.

Decision guide

Use this quick guide when you are unsure which model you are looking at:

• If the choice is off, campaign-wide, or per touchpoint, you are in Pattern A.
• If the campaign sets the default and touchpoints can override it only inside campaign limits, you are in Pattern B.
• If the feature must stay consistent for the entire campaign, you are in Pattern C.
• If you create something once and then attach it where needed, you are in Pattern D.

Patterns cannot be mixed inside a single object. An object follows one model at a time.

Mental model summary

Related