Forum Discussion
CopyJob → Snowflake: Database name is hard‑coded in activity JSON and cannot be parameterised
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.
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.