Rule Propogation

On any merchandising 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 the page. Two kinds of rows are excluded from it:

• Global Rule rows. Propagating a Global Rule affects your whole site, so you must select it manually. Doing so shows a warning: "You have chosen the Global Rule for Propagation. It will impact your whole site!" Dismiss it with the cross icon, which also removes the Global Rule from your selection.
• Expired rows. Their checkbox is disabled and greyed out, with a tooltip explaining that expired rules cannot be propagated.

Active, Upcoming, Draft, and Stopped rules can all be selected, individually or through the master checkbox. To propagate a single rule without selecting anything else, use Propagate this rule from the row's 3-dot menu.

Once one or more rows are checked, a floating action bar slides up from the bottom of the page showing your selected count. Click it to open the propagation modal with those rules pre-loaded. The bar disappears again if you clear your selection.

Click the propagation icon to open the Propagate rules modal.

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 with its environment badge (PROD, DEV, or STAGE) and language chip. You can mix sites across different regions in the same run, for example choosing some sites in the US region and some in the UK region together. An All Sites shortcut sits at the top. Selected sites appear as removable chips below the dropdown.
• Select Site Group. A single-select dropdown of your existing Site Groups. Selecting one expands it inline to show its actual member sites as chips, so you see concretely what you are about to affect rather than trusting a group name.

If the source site ends up inside your selected destination, through a manual pick, "All Sites," or a Site Group, it is automatically removed, with a note above the chips: "[Source site] was removed, you can't propagate to your own source." This is never silent. If no destination sites are configured at all, the dropdown shows an empty state linking to Manage > Sites.

Conflict mode

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.

• Click Continue to move to the confirmation screen; it stays disabled until a destination is resolved.
• Click Cancel, or close the modal, to discard your selections. There is no draft state.

Review the confirmation screen. Follow the steps below to do so:

At the top, the screen summarizes your source site, how many destination sites are in the run, and a total entities count, which sums every rule and every dependency being propagated across all destination sites in one number.

Some of your originally selected destination sites may be excluded from the run entirely, with a count and reason shown for each, for example a feature mismatch between the source site and that destination. Excluded sites are called out separately from the per-site Ready and Blocked statuses described below, since an excluded site is dropped from the run rather than attempted and flagged.

1. Site identity: name, environment badge, language chip.
2. Dependency summary: a plain count of Collections and Segments involved, for example "Collections: 7 · Segments: 5."
3. Outcome: the result you are scanning for, for example "Promotions: 9 ready, 1 might fail."
4. Status pill: Ready (green) means nothing will fail or block. Blocked (red) means a dependency it needs is unavailable.

A rule that will fail for a reason unrelated to a blocked dependency (for example, a field type mismatch) shows that reason in its nested detail without preventing you from proceeding. For a Blocked site, the expanded detail links to where the dependency can be resolved; there is no in-flow fix here. Fixing it elsewhere and returning updates the row to Ready automatically on your next visit.

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

Click Proceed with propagation to start the job, or ← Back to return to Step 2 with your selections preserved. Changing your destination and returning regenerates this screen fully.

A collapsible summary bar at the top of this screen gives you the run-level view; expand any site row for its own pipeline.

Each site row shows its identity on the left, followed by three connected chips in order: Collections → Segments → Promotions. Each chip shows the entity name, and once that step finishes, a status and fraction (for example "20/20" or "3/8"). No numbers show while a step is pending or running.

Field Properties also appears to run as part of the dependency stage alongside Collections and Segments. Confirm with Engineering whether it renders as its own visible chip in the shipped UI, since this guide currently describes three chips only.

Promotions stays Pending until Collections and Segments both reach a terminal state (Success, Partial Success, or Failed) regardless of how clean that outcome was. It then moves to In Progress and resolves on its own. A run can show Partial Success even when only one item out of many failed, for example 10 promotions on one site where eight are skipped, one is created, and one fails. Multiple sites animate one after another rather than all at once.

A View detailed report → link appears for each site once its job starts, even before it finishes. There is no retry action on this screen; retrying happens from the detailed report.

Find this under Activity History, in your profile section, once a propagation run has started.

From the detailed report, you can:

• See every rule and dependency labeled as Created, Ignored, Replaced (config), Replaced (status), Skipped, or Failed. Dependency-specific outcomes are explained in How dependencies are resolved.
• Filter by who created the rule, entity type, date, status (All, Success, Failed, Skipped), and destination site.
• Click Retry failed to re-enter the confirmation flow with only the failed items. Dependencies recalculate fresh, and a new job starts once you confirm.
• Export the report.
• Request a report for one specific site, sent to your registered email address.
• Click Email Report for a full, consolidated report across every destination site, also sent to your registered email address.