Native Shopify Rollouts operations

Verified against official sources on 2026-10-19. Recheck provider capabilities and the selected store before each run; a historical documentation check does not establish current account access. Use host-provided repository, Shopify and authenticated browser capabilities. StoreSkills supplies no runtime or credentials.

Verify eligibility, artifacts and operations

Rollouts require Basic or higher; experiments require Grow or higher. Verify actual plan, Markets > Rollouts and relevant theme permissions, eligible markets, current-theme compatibility and conflicting rollouts. Vintage themes are unsupported. Shopify restricts Liquid-template changes inside rollouts; verify that the prepared replacement-theme experiment is supported rather than assuming arbitrary code edits are eligible.

Use the drafting workflow to resolve store identity, hypothesis, control/source revision and one reviewed unpublished treatment. Record the native control copy if Shopify creates one; the current live theme, source baseline and experiment control are not interchangeable identities. Reconcile merchant changes and inspect both experiences. Do not edit a scheduled or active treatment/control to fix a draft; prepare a new reviewed artifact if needed.

The public 2026-10 API documents rollout/rollouts reads and the read_rollouts scope, with underlying resource permissions. It can expose configured and effective allocation, schedule and resource changes. Missing scopes or filtered results do not prove there are no rollouts. Do not infer a create/stop mutation from queries, webhook names or private admin traffic. Use a currently documented supported API/CLI operation only after verifying it; otherwise use the authenticated native admin path below. If required create, read or stop capabilities cannot be established for the selected store, return the exact limitation before promising automated operation.

Establish the concrete owner policy

Default to one active meaningful experiment per store. Read current experiments before creation or scheduling. Permit overlap only under an explicit owner-approved exception documenting independent audiences/surfaces, uncontaminated assignment and independent measurement. A draft upload alone does not expose visitors.

Before creating or scheduling, have the store, artifact IDs/revisions, affected audience/routes, agreed primary metric and denominator, guardrails, sufficient-evidence/decision criteria, allocation and control/treatment split, start/end times in the store timezone, intended end behavior, and stop/rollback limits. Use explicit or standing owner authorization when it covers this scope; do not ask again for the same permitted action. Otherwise finish the brief, previews and proposed configuration before requesting the missing authorization.

Drafting defaults to a handoff. An instruction to run a prepared experiment can continue here, but CLI login or read-only report access alone does not authorize exposure. The chosen measurement source must support actual assigned cohorts. Missing measurement cannot be replaced with local preview results, invented uplift or a before/after comparison.

Create or resume through native admin

Read existing rollouts and this task's host artifacts before creating anything. Reuse a recorded draft only after matching store, rollout ID, themes, revisions, ownership and configuration. An existing name alone is insufficient.

For an authorized new experiment, open Markets > Rollouts, select Create rollout and Experiment, then add the online-store change replacing the current theme with the reviewed treatment. Verify the actual control and treatment previews. Add only that theme change; do not include discounts, catalogs or checkout configuration changes.

Set the eligible-visitor allocation and experiment control/treatment split separately; they are different quantities. Set the approved schedule using the store timezone shown by Shopify. The documented 50/50 split and 90-day duration are defaults, not a measurement recommendation. Review conflicts, effective reach, exact themes, dates and the displayed end behavior before the final save. Do not resolve conflicts by altering someone else's rollout.

A saved rollout with changes and a start date can become Scheduled and later affect visitors. Save only within the selected authorization. For a bounded experiment, use the approved rollback end behavior, never permanent application by default. Read back the real rollout ID/link, native state, control/treatment IDs, configured/effective allocation, split, eligible markets, schedule/timezone and end behavior. Retain the brief, Git diff and screenshots/readback with those artifacts in the host.

After timeout/interrupted save, inspect provider identity, resource changes and timing before retrying. Retain verified partial results; ambiguous ownership/outcomes stop dependent writes with a precise handoff. Resume from actual state without recreating/rescheduling completed steps.

Observe, stop or cancel within policy

Read the native status and available controls. Draft/Scheduled, Active, Paused and Ended have different operations; a save or successful upload is not evidence of active exposure. Keep actual assigned cohorts and platform metric definitions with the readout. Reuse the funnel cohort workflow from $report-shopify-funnel (references/workflows/cohorts.md); the host owns any requested monitoring schedule.

When the owner's stop condition or explicit instruction applies, use the supported native action for that state. Active experiments offer Pause or End; End requires choosing rollback or permanent application. Use rollback only when the policy authorizes that stop, and never choose permanent application in this operating stage. For a Scheduled experiment, cancelling through Archive needs applicable owner authorization. Do not delete artifacts or archive unrelated/conflicting rollouts automatically. If no safe authorized action is available, return the actual state and required decision.

Read back the resulting native state and visitor experience after stopping/cancelling; do not label Paused as Ended or assume an ambiguous action rolled back. Preserve experiment links, artifacts and measurement to support later evaluation. Permanent application requires a separate evidence-backed decision and appropriate release authorization. Use $promote-shopify-winner only when installed; it is currently unpublished in Glue. Otherwise preserve the readout and artifact identity as a pending evaluation/release handoff for the owner, without declaring a winner or applying changes.

Handoff and limitations

Return actual store/rollout links/state, control/treatment IDs/revisions, requested/effective exposure, audience, timing, readback and decision/monitoring criteria. Retain prepared artifacts and name missing permissions, eligibility, browser or measurement. Never fabricate IDs/launch success or hide missing native acceptance behind static checks.

Permanent Rollouts application cannot be natively undone. A recovery copy is useful but does not make it reversible. Theme experiments expose platform-defined metrics; preserve their actual session/visitor denominators and reporting coverage rather than forcing them into unsupported rate keys.

Official sources

• Requirements and considerations: plan, permissions and compatibility.
• Creating a rollout: native configuration, allocation, split, schedule and end behavior.
• Managing rollouts: state-specific controls, conflicts and permanent-application limits.
• Rollout analytics: native measurement and actual reach.
• Rollouts API announcement: documented public reads and scopes.
• Rollout object, API 2026-10: target-bound resource identity and allocation.
• Theme CLI commands: verify supported theme operations separately from Rollouts.

Losing treatments and cleanup handoff

When actual evidence supports a loss or a supplied stop condition applies, use only the owner-authorized rollback/stop path above and read back visitor experience and provider state. An inconclusive result is not a loss. List obsolete run-owned themes, branches and variations with their exact identity and active/scheduled rollout references. Keep brief, results and recoverable evidence. Deletion/archive of those artifacts requires applicable authorization and verified absence from active/scheduled use; never delete automatically or confuse stopping exposure with removing files. Offer the precise cleanup handoff when authorization or capability is unavailable.