Scoping a run
By default a run targets every resource enabled on the migration. Resource scope lets you narrow a single run to a specific subset — useful when you only need to re-pull one resource type, push a mapping fix for one resource, or load a resource that was added after the initial migration ran.
Setting the scope
In the Start run modal, the second chip in the sentence reads “all resources” when the run is unscoped. Click it to open the scope picker and deselect any resource types you want to exclude. The label updates to reflect your selection (“products, customers” or “1 resource”, etc.).
Only resources enabled on the migration appear in the picker. Resources that were never turned on in the wizard are not listed.
When to scope a run
Mapping fix on one resource. You edited the products mapping but everything else is fine. Scope to products, run transform, then load. Customers and orders don’t re-transform and don’t get re-pushed.
Adding a new resource type after launch. You did not enable orders in the original migration, but now you need them. Enable the resource on the migration (Edit migration → resources), then start a scoped run: extract + transform + load scoped to orders only. Existing products, customers, and collections stay untouched.
Isolating an error. One resource is failing on load. Scope the next run to that resource so the run log is clean and the error is easy to find in the run items.
Incremental delta runs. If you re-extract everything but only need to push one resource’s changes to Shopify, scope the load phase to that resource.
Scope and phases
Scope applies to all phases you select. A full (extract + transform + load) run scoped to products only extracts from the source for products, transforms them, and loads them — customers and orders are not touched at any phase.
The only-dirty flag and resource scope are independent settings. You can scope to one resource and still use only-dirty to skip records that have not changed since the last load.
Scope and billing
Only records that are actually loaded are billed. Scoping a run to one resource type means the other resource types produce no chargeable events for that run. See Monitoring → Run costs for how the cost summary is calculated per resource.
What scope does not do
Scope does not prevent Graftport from reading mapping configuration or run history for out-of-scope resources — it only prevents the extract, transform, and load phases from executing on them. All migration-level settings (credentials, enabled resources, conflict strategy) remain unchanged by a scoped run.