Every job Copify was built to do.

1. 1Connect both stores on the Connections page and configure the pipeline AU → NZ.
2. 2Turn on Products, Collections and Files in the sync scope; leave Orders and Customers off so the regions keep separate books.
3. 3In Product field rules, set Price to Price Markup for the FX and freight difference, and set Handle to Suffix `-nz` if you need distinct URLs.
4. 4Set Status to Override so new products land as drafts until the local team reviews them.

One catalogue to merchandise. NZ stays current on every product, image and collection rule, at local pricing, without a spreadsheet round-trip.

1. 1Create a pipeline from the master store to each brand store.
2. 2Sync Products and Metafields; set Vendor to Override per pipeline so each storefront shows its own brand name.
3. 3Set Tags to Merge so brand-specific merchandising tags survive every sync instead of being overwritten.
4. 4Map metafield namespaces per brand in the Metafield Mapping editor, and use Sync Schema to create missing definitions on each destination.

Shared product truth with per-brand presentation. A range update reaches every storefront while each brand keeps its own identity and curation.

1. 1Connect the new store and create a pipeline from the main store.
2. 2Sync only the collections and products in scope, with Status set to Override so nothing goes live before you are ready.
3. 3Trigger an on-demand sync to stand the catalogue up in one pass.
4. 4Back up the store before teardown so the campaign data is retained after the store closes.

A campaign store stands up in an afternoon rather than a sprint, and its data survives the store being switched off.

1. 1Curate a clearance collection on the main store — smart collection rules sync too, so membership stays automatic.
2. 2Pipe that collection to the outlet store on an hourly schedule.
3. 3Apply Price Markup below 1.0 to express the standing discount, and Suffix the handle so the two listings never collide in search.

The outlet store restocks itself from a rule you set once, at the right price, without anyone re-keying products.

1. 1On Deployments, pick the source store and theme and the destination store and theme, then Compare.
2. 2Review the side-by-side diff of every changed Liquid, CSS, JS and JSON asset.
3. 3Untick anything you do not want promoted — only checked files are written, unchanged files are never touched.
4. 4Deploy, or Request Approval if your account requires sign-off.

File-level control over what reaches production, with a diff you can read before it happens and a deployment history afterwards.

1. 1Create a pipeline production → staging with Products, Collections, Pages, Blogs and Metafields in scope.
2. 2Leave Customers and Orders out of scope so no real customer data lands in a non-production environment.
3. 3Run it on a daily schedule, or trigger an on-demand sync before each test cycle.

Staging behaves like the real store — real catalogue depth, real collection rules, real metafields — without copying customer records into it.

1. 1Nothing to arrange up front for themes: every deployment takes a pre-deploy snapshot first, and a deploy is aborted outright if that snapshot cannot be taken — so a rollback path always exists.
2. 2Open the deployment on the Deployments page and roll it back. The snapshot is restored, and files the deploy added are removed.
3. 3Rollback sits behind the same approver permission as approving a deployment, so it is not a button anyone can hit.
4. 4For content rather than theme files, restore the relevant backup, and use Sync History filtered by store and status to see which operations ran and when.

Theme releases are reversible by design rather than by discipline — the snapshot is a precondition of deploying at all, not something you have to remember to take.

1. 1Require approval for deployments, and set the Is Approver flag only on the people who should hold the gate.
2. 2Move everyone who does not need destructive access to the User role — sync, backups and history, no destructive operations.
3. 3Schedule daily backups of Products and Customers for the freeze window.
4. 4Watch Sync History for anything unexpected during the period.

Production changes require a named approver, everything is snapshotted daily, and the log answers who changed what.

1. 1Generate a personalised install URL in the Partner Portal's Install Link tab and send it to the merchant.
2. 2Or, for an existing connection, use the ⋮ menu on a store to generate a 10-character pairing code for the client to redeem.
3. 3The client completes standard Shopify OAuth; the store links to your partner account and a pipeline is created automatically.

Client stores connect under their own credentials, attributed to your partner account, with no shared passwords anywhere.

1. 1Sign in to the Partner Portal with your portal key.
2. 2The Overview tab shows stores installed, active pipelines, sync operations over 30 days and errors over 7 days.
3. 3The Stores tab breaks the same figures down per store, including last sync time and an errors badge.
4. 4Drill into Sync History on any store, or run a store comparison to find records that have drifted.

Client problems surface as a red error count on your dashboard rather than as an inbound complaint.

1. 1Keep a reference store as the template.
2. 2Use Deployments to push the theme from the template to the new client's store, reviewing the diff on the way in.
3. 3Pipe Pages, Blogs and Metafields from the template, and use Sync Schema to create the metafield definitions on the new store.

New builds start from your standard in minutes, and improvements to the template propagate to the next client rather than being re-typed.

1. 1Pipeline retail → wholesale with Products and Collections in scope.
2. 2Set Price to Price Markup at your trade multiplier, and Compare At Price to Skip so retail RRP never leaks in.
3. 3Set Tags to Merge so wholesale-only tags such as MOQ or lead-time survive each sync.

Trade pricing derives from retail automatically. One price change on retail flows to wholesale at the correct multiplier.

1. 1Build a smart collection on retail whose rules define the trade-eligible range.
2. 2Sync collections to the wholesale store — a classic rule set carries over with its conditions and match-any/match-all flag, so membership stays automatic on both sides.
3. 3Collections using Shopify's newer multi-source model (several sources, exclusions or sub-collections) are refused with a reason rather than silently flattened into a static product list — worth checking before you rely on one for trade scope.
4. 4Use Status field rules to keep anything outside the range unpublished on the trade store.

Trade availability is governed by a rule rather than a maintained list, and it updates itself as the range changes.

1. 1Add Customers to the pipeline scope; customers match on email address.
2. 2Set Addresses and Phone to Sync, and Marketing Consent to Skip so consent captured on one store is never overwritten by the other.
3. 3Set Tags to Merge so account-tier tags applied on either store are preserved.

Contact and address details converge across stores while consent state stays exactly where the customer set it.

1. 1Export products, customers and orders from the legacy platform to CSV or Excel.
2. 2Upload on the Import page — a virtual, CSV-backed store is created automatically to hold the data.
3. 3Map columns to Shopify fields; matching headers are auto-mapped and required fields are flagged before the run.
4. 4Import to the destination store, then re-import deltas up to cutover, using Skip conflict handling to avoid clobbering live edits.

The new store fills up while the old one keeps trading, and cutover is a DNS change rather than a data event.

1. 1Connect the empty store and create a pipeline from the established one.
2. 2Turn on every entity type you want carried over, then run an on-demand sync to seed it in one pass.
3. 3Deploy the theme across with Deployments, and Sync Schema for metafield definitions.
4. 4Decide afterwards whether the pipeline stays live for ongoing sync or is a one-time seed.

A new store that starts complete, with the option to keep it in step or let it diverge from that point on.

1. 1Download the template CSV to check the expected column format before you start.
2. 2Upload the CSV or Excel (.xlsx) file and review the extracted preview rows.
3. 3Map columns, pick the destination store, and choose Overwrite or Skip for records that already exist.
4. 4Start the import and navigate away — it runs in the background with live progress, stage and success/fail/skip counts.

A summary of rows imported, skipped and failed, plus a downloadable error report so bad rows can be fixed and re-run rather than hunted for.

1. 1Export historical orders from the legacy system and import them via the Orders tab on the Import page.
2. 2Map order name or number — that is the match key Copify uses for orders.
3. 3Use field rules to control Financial Status and Fulfilment Status so imported history is not misread as open work.

Order history survives the move, so support and reporting do not start from zero on cutover day.

1. 1On Backups, create a backup of the store and entity type you are about to touch.
2. 2Add a note describing the change so the snapshot is identifiable later.
3. 3Run your bulk change.
4. 4If it goes wrong, restore the backup — noting that restore overwrites existing records and cannot itself be undone.

Bulk changes stop being one-way doors. The pre-change state is a JSON snapshot you can download or restore.

1. 1Open Schedules on the Backups page and add a schedule per store and entity type.
2. 2Choose Daily, Weekly, Biweekly or Monthly, and set the hour and minute in UTC.
3. 3Enable the schedule; the card shows last and next run times.
4. 4Check your plan's retention — how many backups per entity type are kept, and for how long.

Recovery points exist before you need them, on a cadence you set once, with the oldest rotating out as new ones land.

1. 1Take or select a completed backup of the source store's entity type.
2. 2Restore it to the target store rather than the original.
3. 3Back up the target first if it holds anything you want to keep — restore overwrites.

Backups double as a transfer mechanism, not just a rollback, so a snapshot can seed any connected store.

1. 1Create backups of the entity types that matter to the business.
2. 2Download any completed backup as JSON — the full entity data exactly as fetched from the Shopify API at backup time.
3. 3Store the file wherever your retention policy requires.

A portable, timestamped export of your own records, independent of any single vendor's account.

1. 1Enable Real-Time on Products in Pipeline Settings — Copify registers Shopify webhooks on the source store.
2. 2Leave scheduled sync running as well; the two operate independently and the schedule catches anything webhooks miss.
3. 3Set the pipeline's entity schedule to Live for the tightest loop, or Hourly within an active-hours window.
4. 4Watch Sync History for webhook failures, which are logged there.

Changes propagate within seconds, with a scheduled sweep behind them as a safety net rather than the primary mechanism.

1. 1Open Field Rules for Products in Pipeline Settings.
2. 2Set Description to Skip so the destination's own copy is never overwritten.
3. 3Set Title and Images to Sync so the things that must match still do.
4. 4Skipped fields also stop those edits being detected as conflicts later.

Central control over the fields that must be consistent, local ownership of the fields that should not be — enforced per field, not per product.

1. 1In Product field rules, set SKU to Prefix with your region code — for example `AU-`.
2. 2Set URL Handle to Suffix with the market — for example `-au`.
3. 3Both rules apply on write, so the source store keeps its own clean values.

Store-specific identifiers are generated on the way in, without maintaining a second set of SKUs by hand.

1. 1Open Configure Metafields inside the pipeline modal.
2. 2Review which definitions exist on source, destination, or both.
3. 3Create mapping rules — sync as-is, map to a different namespace and key, or ignore entirely.
4. 4Use Sync Schema to create missing definitions on the destination in one click.

Custom data arrives where the destination theme actually reads it, instead of in a namespace nothing queries.

1. 1Open the Comparison tab on the History page and select the two stores.
2. 2Read the per-entity-type summary: matched, drifted, and missing on either side.
3. 3Resolve genuine divergence through Conflicts, or set field rules to Skip for fields the destination should legitimately own.

Divergence becomes a number you can look at, and each drifted record has a decision path rather than being discovered by a customer.

1. 1Rely on incremental sync: Copify hashes each entity's content with SHA-256 and compares it to the stored hash from the last run.
2. 2Unchanged entities are skipped with no API calls to the destination — and skipped records are not counted against usage.
3. 3Tune per-entity schedules — Daily on selected weekdays, or 15-minute, 30-minute and hourly modes inside an active-hours window — so low-churn entities do not run constantly.

Sync work is proportional to what actually changed, so a large catalogue costs what its churn costs rather than its size.

1. 1On the Users page, add the person and choose a role: Owner (full access including billing), Admin (full access except billing and owner management), or User (sync, backups and history — no destructive operations).
2. 2Beyond the role, assign individual permissions where you need finer control — connections, deployments, backups, import, users, billing, settings and API keys each split into view and manage, with deployment approval as its own grant.
3. 3Update a role or permission set at any time; removing a user revokes access immediately.

Access matches responsibility, and the destructive operations sit behind a role rather than behind trust.

1. 1Set the Is Approver flag on the users who should hold sign-off, on the Users page.
2. 2With approval required, developers click Request Approval instead of Deploy.
3. 3Approvers review the pending request and either approve — the deployment proceeds — or reject with a reason.
4. 4Track state through pending, approved, rejected and deployed. The same approver grant also controls who can roll a deployment back.

A review gate on production that mirrors code review, with the rejection reason recorded alongside the request.

1. 1Open History and filter by store, entity type or status.
2. 2Each entry carries the entity type and ID, success or failure, timestamp, message and details, and the source and destination store.
3. 3Cross-reference against a store comparison when you need the current state rather than the event log.

Every sync operation is on the record, so incidents are traced rather than reconstructed.

1. 1Review pending conflicts on the Conflicts page — each shows both versions side by side with the detection date.
2. 2Resolve with Source Wins, Destination Wins, Newest Wins (most recent updatedAt), or a manual resolution where you supply the values that should win.
3. 3Ignore conflicts on records you no longer sync.
4. 4Prevent recurrence: set contested fields to Skip, and enable Real-Time to shrink the window in which divergence can happen.

Contention is a queue with four explicit resolutions, not a silent overwrite discovered later.