--- title: Shopify Rollouts published: true index: 10 --- # 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](../workflows/ab-test.md) 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](https://help.shopify.com/en/manual/markets/rollouts/requirements-and-considerations): plan, permissions and compatibility. - [Creating a rollout](https://help.shopify.com/en/manual/markets/rollouts/create-a-rollout): native configuration, allocation, split, schedule and end behavior. - [Managing rollouts](https://help.shopify.com/en/manual/markets/rollouts/managing-rollouts): state-specific controls, conflicts and permanent-application limits. - [Rollout analytics](https://help.shopify.com/en/manual/markets/rollouts/analytics): native measurement and actual reach. - [Rollouts API announcement](https://shopify.dev/changelog/posts/read_rollouts): documented public reads and scopes. - [Rollout object, API 2026-10](https://shopify.dev/docs/api/admin-graphql/2026-10/objects/Rollout): target-bound resource identity and allocation. - [Theme CLI commands](https://shopify.dev/docs/api/shopify-cli/theme): 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.