Forum Discussion
CopyJob → Snowflake: Database name is hard‑coded in activity JSON and cannot be parameterised
- 4 months ago
Great catch this is a real pain point when building environment-agnostic pipelines with Snowflake as a destination. You're right that the database name gets hard-coded in the CopyJob activity JSON, making it impossible to parameterize across Dev → SIT → UAT.
Why this happens:
The Snowflake connection in Fabric only stores server, username, password, and warehouse. The database and schema are set at the activity level inside the CopyJob JSON definition, not in the connection object. Since CopyJob doesn't support dynamic content for these fields, you're stuck with whatever value was selected at design time.
Workarounds until Microsoft adds native support:
1. Use a Data Pipeline with Copy Activity instead of CopyJob
Copy Activity in Data Factory pipelines supports parameterization. You can create pipeline parameters for the database and schema, then use dynamic content:
@pipeline().parameters.SnowflakeDatabase
This way, you configure different parameter values per deployment stage using Deployment Rules.2. Use a Notebook with Snowflake Spark connector
If you need full control, bypass CopyJob entirely and use PySpark with the Snowflake connector:
You can then set spark.snowflake.database differently per environment using %%configure or environment variables.
3. Use Deployment Rules to swap connections
As a partial workaround, create separate Snowflake connections per environment (e.g., Snowflake_DEV, Snowflake_SIT, Snowflake_UAT) where each connection points to a different default database. Then configure Deployment Rules in your deployment pipeline to swap the connection at each stage.
This doesn't solve the hard-coded database issue directly, but it ensures the right database is used per environment.
Recommendation:
I'd suggest submitting this as a Feature Request on https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas exposing database/schema as parameterizable fields in CopyJob would benefit everyone building multi-environment pipelines with Snowflake. I'd upvote it!
Reference: https://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/create-rules?tabs=new-ui
Hope this helps! Let me know which approach works best for your setup.
Hey MashfiqueFahim
I believe this is a limitation in Fabric today.
What’s happening:
- Snowflake connection in Fabric doesn’t include Database / Schema
- When you pick a database in CopyJob, Fabric hard‑codes it inside the activity JSON
That hardcoded value can’t be parameterised, can’t be changed after deployment and is NOT updated by deployment pipelines.
So when you deploy Dev → SIT → UAT, the connection swaps correctly, but the CopyJob still writes to the Dev database. This breaks environment "agnostic" pipelines and CI/CD.
Some workarounds in my opinion:
1. Use a Notebook + Snowflake Spark connector
(+) Full control over database per environment
(-) Heavier than CopyJob, but reliable
https://learn.microsoft.com/fabric/data-engineering/spark-connectors-snowflake
2. Separate connections per environment
(+) Helps reduce risk
(-) Still doesn’t truly fix the hard‑coded database issue
https://learn.microsoft.com/fabric/data-factory/create-snowflake-connection
Suggest you raise this as a Fabric Ideas request, this will affect pretty much every enterprise Snowflake setup.
Link here: https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas