Forum Discussion
Copy Job Interface
The checkbox in the table/query selection pane is not a runtime toggle, it is a configuration selector. When you uncheck a query, Fabric treats it as “not part of the job” and removes it from the activity definition rather than just skipping execution. The “Exclude” option, on the other hand, is evaluated at runtime but still assumes the query exists in the config.
Once a custom SQL query is removed this way, dont think there is a native recovery unless you have versioning in place (for ex, git integration or a saved JSON/export of the pipeline). Without that, you will need to recreate those queries manually.
For dev, the practical approach is to avoid using the checkbox as a control mechanism. Instead, split workloads into smaller logical copy activities (for ex, per domain or batch of tables), parameterise the table/query list and drive execution via parameters, or use filters/flags in a metadata table to control which tables run. Another simple workaround is to duplicate the pipeline for testing and prune it there, keeping the original intact. In short, treat copy Job configuration as static and control execution dynamically rather than editing the selection each time.
Super UserHi rafalencar1997 ,
Based on the current behavior, it appears that the table selection checkboxes are treated as part of the Copy Job definition rather than as a runtime execution option. As a result, deselecting a table and saving the job removes that table (and its custom SQL) from the configuration instead of simply skipping it during execution.
For ingestion scenarios involving 100+ tables, I'd recommend considering a metadata-driven Data Pipeline (Lookup → ForEach → Copy Activity) instead of a single Copy Job. This allows you to enable or disable tables through metadata, version the configuration in Git, and add logging, retries, validation, and environment-specific behavior without modifying the pipeline itself.
If you're using Git integration with your Fabric workspace, it's also worth checking whether a previous version of the artifact can be restored. Otherwise, there doesn't appear to be a native recovery mechanism once a custom SQL definition has been removed.
I also think this would make a good product enhancement—a "Skip for this run" or "Disable" option that preserves the configuration during development and testing would be much more intuitive.
If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let me know. Thanks a lot!