Every job Copify was built to do.

1. 1Install Copify on both stores, then pair them on Connections with Connect a Store: one store generates a 10-character connection code and the other enters it within 15 minutes.
2. 2Set up a data flow AU → NZ with Products, Inventory, Collections and Metafields & values turned on. Leave Customers and Orders off so the regions keep separate books.
3. 3New data flows are created paused. Enable it and run Sync now to seed the new storefront in one pass.
4. 4Give each data type its own schedule — Hourly for products and stock, Daily or Weekly for collections that rarely change.
5. 5Prices are copied as they are and never converted, Shopify Files are not synced, and a product deleted on AU stays on NZ until you remove it there.

One catalogue to merchandise. NZ picks up product, stock and collection changes on the schedule you set, without a spreadsheet round-trip.

1. 1Set up a data flow from the master store to each brand store — one flow per pair of stores.
2. 2Turn on Products, Collections and Metafields & values, then use the product filters under What syncs to limit each flow to the collections or tags that brand carries.
3. 3In the Metafield Mapper, set each definition to Sync 1:1, Map to Different Key or Ignore, so each brand's theme finds its custom data where it expects it.
4. 4Click Sync Schema to Destination to create the missing metafield definitions on each brand store, then run Sync now to seed it.

Shared product truth with per-brand curation. A range update reaches every brand that carries it, while each brand keeps its own custom data layout.

1. 1Curate a clearance collection on the main store. An automated collection keeps its own membership up to date.
2. 2Set up a data flow to the outlet store with Products on, and under What syncs limit it to the clearance collection. The count shows how many products currently match.
3. 3Schedule Products Hourly, or Every 30 min if stock moves fast. Each run compares records with what was last sent, so only products that changed are written.
4. 4Products that leave clearance are not removed from the outlet — Copify never propagates deletions — so archive those there yourself.
5. 5Check Sync history on Analytics to confirm each run landed.

The outlet store fills itself from a collection you set once, without anyone re-keying products.

1. 1Start a New Deployment, pick the store, and choose Market customisations under What do you want to deploy.
2. 2Pick the source and destination themes and the market to copy from — each market shows how many customised pages it has.
3. 3Choose the markets to apply it to, then Everything customised, or Only certain pages if you only want the homepage.
4. 4Review changes before anything is written: every page is marked New or Updated, with the settings that change.
5. 5Under Advanced options, also copy colours, fonts and app blocks or translated text, and keep markets linked automatically. Page changes can be undone from Deployments & Requests; translated text cannot.

A market's presentation becomes something you author once and distribute, rather than a fortnight repeated per country — and it works within one store, not only between two.

1. 1On Deployments, start a New Deployment: pick the source and destination stores, choose Theme & data, select both themes, then Compare & Continue.
2. 2Review each changed file in a diff — a visual view for JSON settings files, code for the rest.
3. 3When writing into an existing theme, untick anything you do not want promoted; identical files are dropped automatically. Safe Mode instead copies the whole theme into a new unpublished draft.
4. 4Read the pre-flight check, then Deploy — or Send for approval if you do not hold the Approve Deployments permission.

File-level control over what reaches production, a diff you can read before it happens, and a pre-deploy snapshot to roll back to afterwards.

1. 1Compare source and destination in the deployment wizard: each file shows as new, changed or removed, and you can open a diff on any of them.
2. 2When overwriting an existing theme, include only the files you mean to promote. Skip a single setting to keep the destination's value on every future deploy.
3. 3Leave Safe Mode on to deploy into a new unpublished theme. Switching it off is what puts you on a live theme, and the wizard warns you before you continue.
4. 4Read the pre-flight check before you confirm. It separates critical issues, warnings and info — including that products, pages and other records are matched by handle and updated in place.
5. 5Deploy, or Send for approval. Either way a pre-deploy snapshot is taken first, so the theme files it overwrites can be rolled back.

Collisions are surfaced and decided in the wizard — file by file, with a diff, a safe-by-default target and a pre-flight warning — rather than discovered on the live store afterwards.

1. 1Compare source and destination as usual. Market customisation files are theme files, so they appear in the review list with everything else.
2. 2Untick them to ship only the shared templates, or skip individual settings so the destination's values are kept on every future deploy.
3. 3Or leave Safe Mode on, so the release lands in a new draft theme and the live one is untouched until you publish.
4. 4To move market work on purpose, use Market customisations instead — it previews each page as New or Updated per market before writing.
5. 5The pre-deploy snapshot covers market files like any other theme file, so they roll back with the release.

Regional storefront work survives a theme release instead of being collateral damage, and you decide whether it moves.

1. 1Set up a data flow production → staging with Products, Collections, Pages, Blog posts, Metafields & values and Metaobjects on.
2. 2Leave Customers and Orders off. If staging is a Shopify development store, Copify warns before customer data would be copied there.
3. 3Schedule it Daily, or run Sync now before each test cycle.

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

1. 1Nothing to arrange up front: every deployment takes a pre-deploy snapshot, and a deploy is stopped rather than run if that snapshot cannot be saved.
2. 2Open the deployment in Deployments & Requests, or on the Theme Deployments & Rollback tab of Backups, and click Rollback. Theme files are restored and files the deploy added are removed.
3. 3Rollback needs the Approve Deployments permission, so it is not a button anyone can press.
4. 4For content, use Version History & Rollback on Backups to put single records back, or restore a backup. Sync history on Analytics shows what 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. 1On Settings → Users, keep the Approve Deployments permission to the people who should hold the gate. Store Owners and Administrators have full access, so keep those roles to a few.
2. 2Make everyone else a Standard User with only the permissions they need. Without Approve Deployments, their deployments become Send for approval.
3. 3Schedule daily backups for the freeze window across the types backups cover: Products, Collections, Pages, Blog Posts, URL Redirects, Metafield Definitions, Navigation Menus and Metaobjects.
4. 4Watch Sync history on Analytics for anything unexpected during the period.

Production deployments wait for a named approver, everything is backed up daily, and the log answers who changed what.

1. 1Keep a reference store as the template, install Copify on each new client store, and pair the two with a connection code.
2. 2Use Deployments to send the theme across in Safe Mode, plus the Pages, Blog Posts, Navigation Menus, URL Redirects and Metafield Definitions you pick record by record.
3. 3For the catalogue structure, set up a data flow with Collections, Pages and Metafields & values, click Sync Schema to Destination, and run Sync now.

New builds start from your standard rather than a blank store, and improvements to the template reach the next client instead of being re-typed.

1. 1Decide which store owns trade accounts and make it the source of a data flow. Sync runs one way, and you can flip the direction later.
2. 2Turn on Customers under Advanced. Customers are matched by email address, so the same buyer is recognised on both stores.
3. 3Set Customers to Live so an edit on the source reaches the other store as it happens. Scheduled runs cover customers updated in the last 60 days.
4. 4Filter Sync history by Customers to confirm what was written and when.

Trade accounts follow the store that owns them, so an address change made there reaches the other store instead of being re-keyed.

1. 1Install Copify on the new store and pair it with the established one using a connection code.
2. 2Set up a data flow and turn on every data type you want carried over. Customers and orders cover the last 60 days, and Shopify Files are not copied.
3. 3Run Sync now to seed it in one pass, and click Sync Schema to Destination for metafield definitions.
4. 4Send the theme across with Deployments, in Safe Mode as a new draft theme.
5. 5Afterwards, keep the data flow on a schedule for ongoing sync, or pause it and let the stores diverge.

A new store that starts from the existing catalogue and content, 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 columns before you start.
2. 2Upload the CSV (up to 50 MB and 100,000 rows), pick the destination store, and map the columns — Auto-detect matches headers for you.
3. 3Rows merge by default — update the record where it is found, create it where it is not — and a command column can override that per row.
4. 4Start the import and carry on working. It runs in the background, and the Imports Queue shows progress with success, failed and skipped counts.
5. 5If the supplier publishes a feed, save the mapping and add a schedule that pulls the CSV or .xlsx from its URL.

A results file lists every row with what happened to it and the error where one failed, so bad rows are fixed and re-run rather than hunted for.

1. 1Export historical orders from the legacy system to CSV.
2. 2On Import Data, choose Orders and the destination store, and map the order number — orders are matched by ID or name.
3. 3Orders default to create-only rather than merge, so re-running the file never rewrites orders already imported.
4. 4Start the import; it runs in the background, and the results file shows any row that failed and why.

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

1. 1Upload the file and map the columns — Auto-detect maps matching headers for you.
2. 2Click Check file before running anything. It reads the whole file against your mapping and writes nothing: how many rows become how many records, what will happen to each, and which key they are matched by.
3. 3Check the columns it lists as unmapped. That is where a mis-map hides.
4. 4Work through the errors and warnings, including SKUs and barcodes damaged by a spreadsheet round trip, and any encoding or separator problems.
5. 5If nothing in the file can identify existing records, Copify asks whether to create every row as new or skip them all, rather than guessing.

Import problems surface in a report you read, not in the store afterwards — and the fix is a column mapping rather than a clean-up.

1. 1On Backups, click Create Backup for the store and entity type you are about to touch.
2. 2Add a note such as "Before price update" so the backup is easy to find later.
3. 3Run your bulk change.
4. 4If it goes wrong, click Restore. The preview checks your live store and shows how many items would be overwritten, how many deleted ones recreated, and how many cannot be restored.
5. 5Restore everything, or select only the records you need back. Products deleted since the backup cannot be recreated — a restore only updates products that still exist.

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

1. 1On Backups, click Add Schedule under Scheduled Backups for each store and entity type.
2. 2Choose Daily, Weekly (Sundays), Biweekly or Monthly (1st of month), and the hour and minute it runs.
3. 3Each schedule shows its last and next run, and can be disabled without deleting it.
4. 4Open Retention Rules to see how many backups per type your plan keeps, 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. 1Deploy themes through Deployments rather than by uploading a ZIP. Every deployment saves the destination’s current theme files first, and the deploy is stopped if that snapshot cannot be saved.
2. 2Copify keeps the last ten snapshots for each pair of stores and prunes older ones automatically.
3. 3Browse them in Deployments & Requests, or on the Theme Deployments & Rollback tab of Backups, which lists what a rollback would revert.
4. 4Roll back from the entry you want: theme files are restored and files the deploy added are removed. It needs the Approve Deployments permission.

A short, dependable history of theme states you can return to, created as a by-product of deploying rather than as a habit somebody has to remember.

1. 1Open the most recent backup of that entity type from before the change and click Restore.
2. 2The preview checks your live store and reports how many items would be overwritten, how many deleted items recreated and how many cannot be restored.
3. 3Search, filter and sort that list to find the records you care about instead of reading all of them.
4. 4Restore the lot, or include or exclude records so only what broke goes back. Deleted products and blogs cannot be recreated — those are restored only if they still exist.
5. 5The restore runs in the background and its details land in Sync history. Take a fresh backup once the store is right again.

A bad night stops being permanent. You see what recovery would do before committing to it, and put back only what broke.

1. 1Back up the types beyond the catalogue: Metaobjects, Metafield Definitions, Navigation Menus, URL Redirects, Pages and Blog Posts, as well as Products and Collections.
2. 2Give each its own schedule — structural data that changes monthly does not need the catalogue's cadence.
3. 3Know the boundary so it is a decision rather than a surprise: customers, orders and themes are not backup types. Theme state is captured by the pre-deploy snapshot on every deployment instead.

The store's structure is covered, not just its products — so a recovery puts the storefront back together rather than leaving you to rebuild the scaffolding by hand.

1. 1On Backups, pick a completed backup of the source store. Restore only goes back to the store a backup came from, so the CSV is the route to anywhere else.
2. 2Download it as CSV — its headers match the importer.
3. 3On Import Data, choose the same data type and the other store, and upload the file. Matching headers are auto-mapped and required fields are flagged before the run.
4. 4Rows merge by default — updating a record where it already exists and creating it where it does not. Follow the run in the Imports Queue and download the results file at the end.

A backup doubles as a transfer file: download it from one store, re-import it into another through Copify’s importer, with a row-level report of what landed.

1. 1Create backups of the entity types that matter to the business.
2. 2Download any completed backup as JSON or CSV — the records as they stood when the backup ran.
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. 1Open Retention Rules on Backups — how many backups per type your plan keeps, and how many days each is held.
2. 2Set schedules so a recovery point exists for every entity type that matters, at a cadence that fills the window rather than leaving gaps in it.
3. 3Older backups are removed automatically as newer ones land and as they reach their expiry date, so the window stays the size your plan sets.
4. 4Where the business needs longer than a plan allows, retention can be arranged per store rather than by moving the whole account onto a different plan.
5. 5For anything that has to outlive the window, download the backup and keep the file wherever your policy requires.

A recovery window you can state as a number and point at, instead of a habit you hope somebody kept up.

1. 1Make the store that owns the stock the source of a data flow. Sync runs one way, and Copify flags real-time inventory running in both directions as a loop.
2. 2Set Inventory to Live in Data flow settings. Live runs on Shopify webhooks, so a change is sent as it happens.
3. 3Live has no schedule behind it, so keep Products on Hourly or Every 15 min as a regular sweep.
4. 4Filter Sync history by the Real-time trigger and Failure status to catch anything that did not land.

Stock changes reach the other store in near real time rather than at the next run, narrowing the window in which two storefronts disagree.

1. 1In Data flow settings, click Configure metafields → to open the Metafield Mapper.
2. 2Each definition is marked In Both Stores, Source Only or Dest Only.
3. 3Set each to Sync 1:1, Map to Different Key with the namespace and key the destination uses, or Ignore.
4. 4Click Sync Schema to Destination to create missing definitions on the destination.

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

1. 1Rely on incremental sync: each record is compared against what was last sent to the destination.
2. 2Unchanged records are skipped rather than rewritten, and a skipped record does not count as a synced one.
3. 3Before you save, Data flow settings shows the count the run will actually write — zero when nothing has changed.
4. 4Tune each data type's schedule — the days it runs, an Active From and Active To window, and Hourly, Every 30 min or Every 15 min only where it matters.

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

1. 1On Import Data, open the Export tab, pick the store and data type, and download a CSV. It uses the same columns the importer reads, so it goes back without remapping.
2. 2Edit the column you came for and leave the rest of the file alone.
3. 3Re-import. An update only touches the fields your file supplies — Copify merges your changes over what the store already holds, so missing columns are not blanked.
4. 4Set a row's command to REPLACE only where you want the file to be the whole truth for that record.
5. 5Back up the entity type before a large change, so the pre-edit state is a restore point rather than a memory.

A spreadsheet round trip that changes what you edited and nothing else — the difference between a bulk edit and an accidental data loss.

1. 1Add a command column to your file. Each row says what to do with its own record — NEW, MERGE, UPDATE, REPLACE, DELETE or IGNORE — so one file can add, change and remove in one pass.
2. 2Control the lists inside a record separately: tags, variants, images and addresses each take their own command, so you can add tags without replacing the existing set, or replace a variant list wholesale.
3. 3Rows with no command merge by default, and orders default to create-only so a re-run never rewrites history.
4. 4Click Check file first and read What will happen — how many rows fall under each command — before any of it runs.

One file expresses the whole change — additions, edits and removals — instead of three passes and a manual clean-up between them.

1. 1Staff join by opening Copify from the Shopify admin and registering, then use Request access to ask for what they need.
2. 2On Settings → Users, set the role: Store Owner and Administrator have full access, while a Standard User has only the permissions ticked for them.
3. 3For this contractor, tick View Dataflows, Run Dataflows and View History, and leave Manage Connections and Billing unticked.
4. 4Change permissions at any time, or delete the user to remove their access.

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

1. 1On Settings → Users, give the Approve Deployments permission only to the people who hold sign-off. Store Owners and Administrators have it already.
2. 2Anyone with Manage Deployments but not Approve Deployments gets Send for approval instead of Deploy, with a note for the approver.
3. 3Approvers find the request on the Approvals tab, review the changes, then Approve & Deploy or reject it with a reason.
4. 4Requests move through Pending approval, Approved, Rejected, Deployed and Rolled back, and the trail stays in Deployments & Requests.
5. 5The same permission governs rollback, so the gate covers undoing a release as well as making one.

Theme releases follow a review gate that mirrors code review — a named approver, the changes they signed off, and the reason attached to anything turned down.

1. 1On Settings, under Slack Notifications, click Connect Workspace, then Add Channel.
2. 2Choose the triggers worth interrupting for — Sync Failed, Backup Failed, Deployment Failed, Deployment Rejected, Deployment Rolled Back and Pipeline Disconnected — or keep the completions as well.
3. 3Set Delivery Frequency to Immediate, Hourly Digest or Daily Summary.
4. 4Set Pipeline Scope to one data flow or all of them, so a client's channel only hears about their own store.
5. 5Leave Notify even when nothing changed off so a quiet flow stays quiet, and set Quiet Hours to hold non-critical alerts overnight.

Failures arrive where the team already is, at a volume nobody mutes, instead of sitting in a log until somebody thinks to look.

1. 1Open Sync history on Analytics and filter by status, source or target store, entity type, trigger or date.
2. 2Each entry shows the time, both stores, the entity type and ID, the status, what triggered it — including who ran a manual sync — and the message and details.
3. 3Open the record in Version History & Rollback on Backups to compare its versions field by field, and roll it back if needed.
4. 4Check Deployments & Requests when the change came from a deployment rather than a sync, and use Export CSV to keep the record.

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