Rule Propogation

Overview

Rule Propagation lets you push merchandising rules, such as Promotions, Collections, Segments, Badges, Banners, Redirects, Searchable Fields, and Merch Facets, from one site to one or more destination sites. You no longer need to manually recreate a rule on every site where it should apply.

Propagation handles dependencies for you. If a rule references a Collection, Segment, or Field Property that does not exist on the destination site yet, Rule Propagation creates it as part of the same run. If it already exists, Rule Propagation reuses it, so you do not lose historical performance data for rules that have not actually changed.

Prerequisites

You need a Merchandiser, Admin, or Super Admin role to use Rule Propagation.
The destination sites must already exist in your account. Rule Propagation does not create sites.
If you plan to use a Site Group instead of individual sites, confirm its membership first, or create one if it does not exist yet. See Site Groups below.
Decide whether you need Skip or Override mode before you start. Refer to Conflict Resolution Modes if you are unsure which one you need.

Site Groups

A Site Group is a named set of sites you can select as a single propagation destination, instead of picking each site individually, useful for sending the same rule to every site that shares a region, language, or festival. Only an Unbxd user, or an account Owner or Super Admin, can create one, from Account Settings > Site Group. A site can belong to more than one group, and groups are currently used only for Rule Propagation.

Step 1: Select Rules to Propagate

On any rule listing page (for example, the Promotions page), a checkbox column appears on the left of each row. A master checkbox at the top of the column selects every eligible row on that page only; it does not reach rules on other pages.

Global Rule rows are included in the master checkbox for most rule types. The exceptions are Segments and Merch Facets, where Global rule propagation is not allowed.
Expired and Stopped rows can still be checked and included in your selection. They are not blocked at selection; instead, they are dropped at propagation time and reported as excluded in the status report. This also covers a rule that expires between the time you select it and the time the job actually runs: it is re-checked at propagation time and dropped if it has expired.

Active, Upcoming, and Draft rules can all be selected, individually or through the master checkbox. Unchecking a selected row drops that rule from your batch.

Once one or more rows are checked, a floating action bar slides up from the bottom of the page showing your selected count, a Select All option, and a Propagate button.

Select All selects every eligible rule across the entire site, not just the current page. This is the option to use for a full, site-wide propagation.
Click Propagate to open the propagation screen with your selected rules pre-loaded. The bar disappears again if you clear your selection.

Step 2: Choose Destination and Conflict Mode

Click Propagate to open the destination and conflict screen. Its header names the entity you are propagating, with a short description of what propagation means for that entity type.

Destination

Choose one of two ways, separated by an "OR" divider; selecting one blocks the other.

Select Sites. A multiselect dropdown lists every available site, grouped by region, with its environment badge (PROD, DEV, or STAGE) and language chip. You can select sites from multiple regions in the same run. Your source site appears disabled in this list, so it cannot be picked by mistake.
Select Site Group. A multi-select dropdown of your existing Site Groups; you can choose more than one group at once. Each selected group shows a View Sites button you can click to reveal its member sites as chips, so you see concretely what you are about to affect rather than trusting a group name. If a selected group contains your source site, the source site is dropped from that group's destination set automatically.

If no destination sites are configured at all, the dropdown shows an empty state linking to Manage > Sites.

Conflict mode

Mode	What it does
Skip (default)	Only creates rules that do not already exist on the destination. Everything else is left untouched.
Override	Creates missing rules and rebuilds any that differ from source. Rules that already match are left untouched, so their performance history stays intact.

Skip is the default because it is non-destructive. Switching to Override is a deliberate choice, not an accident waiting to overwrite a production site. Full matching behavior for each mode is covered in Conflict Resolution Modes.

If a propagation is already running for the same rule type, this screen shows a blocking message with an X button to dismiss it, instead of opening normally. Each rule type has its own independent lock, so a running Promotions propagation does not stop you from starting a Collections one at the same time.

Click Review & Propagate to move to the confirmation screen; it stays disabled until a destination is resolved.

Step 3: Review the Confirmation Screen

This screen is read-only. It answers one question: if you proceed right now, what will happen, site by site? Nothing here is editable beyond navigation links to where an actual fix lives, and the two footer actions.

Summary header

Selected Rules: the entity type and count you selected, for example "Promotion with 10 rules," plus any dependency entity counts worth surfacing at this level.
Source site: the sitekey you are propagating from.
Destination sites: how many destination sites are in the run, and how many were excluded (see below).
Conflict: the mode you chose on the previous screen, with an (i) icon explaining what it means.
Dependencies: every dependency type actually involved, with its count in brackets, for example "Segments (2)." Only dependency types that are actually part of this run are shown.
Total Entities: the combined total of every rule and every dependency being propagated, across all destination sites.

Destination table

A Site Group destination is broken down into its individual member sites here; you see one row per site, not one row per group. Each row shows:

Destination Site: site name, full sitekey, environment badge, language chip, and region chip.
Rules & Dependencies: a hierarchical view, with the main rule at the top and its dependent entities nested underneath it.
Count: per-entity counts for the rule and its dependencies.
Overall Status: a single forecast pill per site. Ready (green) means nothing will fail or block. Blocked (red) means a dependency it needs is unavailable; the expanded row links to where that can be resolved, since there is no in-flow fix here.

A single disclaimer banner always appears, covering the fact that Collection and Segment matches are by name only, not content.

Why a site might be excluded

Some of your originally selected destination sites may be dropped from the run entirely, before anything executes. An excluded site is not counted in the entity, dependency, or site totals above, and is listed separately with the specific reason:

Cause	Message shown
Destination site's schema does not match the source site	"This site's schema doesn't match the source site, so it's been excluded from this propagation."
A required feature, such as A/B testing, is not enabled on the destination	"A/B testing isn't enabled on this destination site, so rules can't be propagated here. Enable A/B test in this destination site to propagate rules from source site." If more than one feature is missing, they are all named: "These features aren't enabled on this destination site: A/B testing, …"
Destination site's field properties schema could not be read	"This site is dropped from propagation as its field properties schema lookup couldn't be read."
Destination site not found	"This site couldn't be found, so it won't receive any rules."
You are not authorized to access the source site	"You don't have access to the source site, so no rules can be propagated from it." This is shown once, as a single blocking error, rather than repeated per destination, since it affects every destination identically.

If every selected destination site fails this check, no propagation is created. All summary counts show 0, the reason is shown for each site, and a pop-up tells you all sites failed and asks you to cancel this propagation; Review & Propagate is disabled.

Footer actions

Clicking ← Back opens a confirmation prompt. If you confirm you want to stop, you are returned to the rule listing page; your selections from Steps 1 and 2 are not preserved.

Clicking through to propagate starts a job that cannot be reverted once it runs. A clear warning to this effect appears near this action.

Step 4: Track Propagation Status

This screen opens automatically once you proceed, and reports on the run as it happens and after it finishes.

Summary bar (collapsible)

A condensed header describing the run's parameters: rule type and count, source sitekey, destination count, conflict strategy used, and total entity count, for example "81 entities." This bar stays static throughout the run; it describes the job's configuration, not its progress.

Progress banner

Run state: "Propagation in Progress" while running, then one of "Propagation Complete" (green), "Propagation Partially Complete" (amber), or "Propagation Failed" (red).
Start timestamp, in UTC.
An overall progress bar and percentage, filling as entities are processed across all sites.
An entities-processed counter, for example "0 / 81 Entities Processed (Across 9 Sites)."

Destination table

One row per destination site, with its dependent entity types nested as expandable sub-rows underneath the primary rule. Columns: Destination Site (name, full sitekey, environment badge, language chip, region chip), Rules & Dependencies (hierarchical, dependencies nested under the primary rule), Status (per-entity icon), Created, Skipped, Failed, Total, and one rolled-up Overall Status per site.

Sites run one at a time, not in parallel. While one site is In Progress, every other site shows as Queued. Within a site, dependencies resolve in a fixed order before the primary rule is attempted: Field Properties, then Collections, then Segments, and only then the primary rule type.

Counts that have not yet been produced show as a dash (–), never a zero, so "not yet run" is never mistaken for "ran and produced nothing." A dependency type with zero entities for a given site does not render a row at all, rather than showing a row of zeros.

Status definitions

State	Meaning
Queued	Has not started yet. All non-executing sites sit here while another site runs.
In Progress	Actively running; counts may be partial or zero-to-date.
Success	Every entity in this scope completed successfully.
Partial Success	Some entities succeeded, some failed, within the same scope.
Failed	Every entity in this scope failed.
Aborted	The entity was not considered for propagation at all in this run.

Outcome counts, per entity type per site:

Created: did not exist on the destination, newly created.
Skipped: already existed and was intentionally left untouched, either because Skip mode was chosen, or because Override mode found no meaningful difference (checksum match). This preserves the destination's existing performance history.
Failed: could not be propagated; the reason is surfaced in this report.
Total: the sum of Created, Skipped, and Failed for that entity type on that site.

A site's Overall Status reflects its worst outcome: any Failed entity rolls the whole site up to Failed; a mix with at least one success rolls up to Partial Success; all successes roll up to Success. A site whose dependencies all succeeded but whose primary rule failed still rolls up to Failed; dependency success never offsets a primary rule failure.

Edge cases

Navigating away mid-run does not stop the job. It keeps running in the background, and returning to this screen shows its current live state.
If a site's dependencies fail entirely, the primary rule row still attempts execution independently and reports its own outcome.
If every entity on every site fails, the run banner shows "Propagation Failed" at 100% complete. Completion and success are separate concepts here: the job finished, it just didn't succeed.

Once the run reaches a terminal state, an Email Report action appears, sending the full report to your registered email address.

Step 5: Propagation Logs

Find this under Activity Log, in your profile section. The page itself is titled Propagation Logs: "View a complete history of all site propagation operations. Track status, identify failures, and monitor propagation activity."

A filter control sits at the top right.

Table columns

Entity: the entity type and scope propagated, for example "Search Promotion Rules" or "Browse Field Properties," with the count of rules selected and the total rules available (the total only applies to Searchable Fields).
Destination Sitekeys: every destination sitekey in that run, listed as individual chips.
Status: Success, Partial success, Failed, or Analysis failed.
Initiated By: the email of the user who started the run, with the start timestamp in UTC underneath.
Actions: a View icon that opens the same report shown at the end of the propagation flow (Step 4), retained here for later reference.

Runs are listed newest first by start time. A run where every destination site failed analysis is still recorded here, with a total rules count of zero, so you can see the attempt was made and why it did not proceed. Renaming a Site Group afterward does not change historical entries; logs record the actual destination sitekeys resolved at the time of the run, not the group used to select them.

Conflict Resolution Modes

Rules are matched between source and destination using the Query and the Campaign (rule) Name together. Internal rule IDs are never used for matching, since they are not shared across sites or regions.

Skip Mode

Condition on destination	Action
Query not present	Create the query and its rule
Query and rule name both exist	Leave the destination untouched
Query exists, rule name does not	Create the new rule under the existing query

Override Mode

Condition on destination	Action
Query and rule name match, status differs	Delete and recreate from source
Query and rule name match, status same, checksum matches	Leave untouched; analytics preserved
Query and rule name match, status same, checksum differs	Delete and recreate from source
Query exists, rule name is different	Create a new rule; existing destination-only rules are never deleted

The config checksum used in Override mode covers only the rule's configuration: boost, bury, pin, slot, and filter conditions, variant locking, segment reference, collection reference, and the similar-query list. It excludes rule name, status, and dates, so a rule whose live/draft state or schedule changed, but whose configuration did not, is not needlessly deleted and recreated.

Rule Propagation applies one Override or Skip flag to the whole run; you cannot choose Override for one dependency and Skip for another. If you need individual control over a specific Collection, Segment, or Field Property, propagate that rule type independently from its own page.

Resolve Dependencies

Dependencies resolve in a fixed order before the primary rule type is attempted: Field Properties, then Collections, then Segments, then the primary rule. See Step 4: Track Propagation Status for how outcomes are counted (Created, Skipped, Failed, Total) and how a site's overall status rolls up.

A few specifics by dependency type:

Segments are created as empty shells with no configuration. If one was created for you, you still need to configure and upload its data on the destination separately.
Field Property changes are append-only. Existing flags are never removed, and properties unrelated to your selected rules are never touched. If a needed field does not exist at all on a destination, or exists with a mismatched type, this cannot be auto-created or auto-corrected; the rule using it fails, and a feed re-upload and reindex is required on the destination.
A Collection with the same name as source, but different products, is reused as-is; name match is treated as a match, with no deep content validation. The same applies to a Segment with the same name but a different definition. You can manually update either independently if needed.
Resolution is isolated per item and per destination. If one Collection fails to clone on a given destination, only the rules depending on it are marked failed there; everything else in the run, on that destination or others, completes normally.

Rule Types and Conflict Resolution

Rule Type	Conflict Resolution	Notes
Promotions	Override / Skip
Segments	Override / Skip	Global rule propagation is not allowed
Merch Facets		Global rule propagation is not allowed. The scope summary in the PRD lists this as Override/Skip, but the dedicated Facet Propagation section says Override is disabled and only Skip is available. See reviewer notes.
Searchable Fields		Propagated in bulk; you cannot select individual rules. The scope summary in the PRD lists this as Skip Only, but the dedicated Searchable Field Propagation section says Skip is disabled and only Override is available. See reviewer notes.
Field Properties	Append-only as a dependency; full Override / Skip when propagated independently	The PRD's own dedicated section for this is unfinished; see reviewer notes.
Collections	Full Override / Skip when propagated independently
Badges	Full Override / Skip when propagated independently
Banners	Override / Skip
Redirects	Override / Skip

Algorithm rules and Reports are not covered by Rule Propagation.

Site Cloning vs Rule Propagation

Site Cloning is functionally a subset of Rule Propagation: a bulk propagation run in Override mode. Use it when you need a wholesale copy of one site's configuration onto another. Use Rule Propagation when you need granular control over which individual rules move, and in which mode.

Edge Cases

Situation	What happens
A rule is renamed on the source before propagating	Treated as a new rule. The old-named rule on the destination is left in place, creating a duplicate by design, not an error.
A selected Site Group's only member is the source site	The destination list shows the disabled source site; Review & Propagate stays disabled with an explanation that the group resolved to no valid destinations.
An Expired or Stopped rule is included in your selection	It is not blocked at selection. It is dropped at propagation time and reported as excluded in the status report.
A propagation is already running for the same rule type	Starting a new one for that rule type is blocked. A different rule type is unaffected; each has its own independent lock.
A landing page references a Collection that was dropped for having no matching products	The landing page is also dropped, with the same reason shown.