Forum Discussion
Fabric CI/CD: Data Pipeline fails with RequestValidationFailed (SQL Connection) when deployed via SP
Hi all,
I’m deploying Fabric items from DEV → TEST using a Service Principal (SPN) via REST API / PowerShell (Azure DevOps CI/CD).
Notebooks deploy successfully
Data Pipelines fail when they reference a SQL Server connection (Lookup activity)
Error:
- Backend ErrorImport failure: RequestValidationFailed. User does not have access to the connection used in the Pipeline. Please verify the user's permissions
Verified
SPN is Admin on Deployment Pipeline and both workspaces
SPN has User access to SQL connections in both workspaces
Manual UI deployment (personal account) works
Questions
Is connection mapping (Deployment Rules) mandatory for Data Pipelines when deploying via SPN, even if connection names already exist in the target workspace?
- Are there additional authorization or binding steps required for SPNs to use SQL connections during cross-workspace deployments?
- What is the recommended way to automate the swap of SQL connection strings (Server/Database name) during deployment?
Any guidance or examples would be greatly appreciated.
Hi CloudVasu
Q: Is connection mapping (Deployment Rules) mandatory for Data Pipelines when deploying via SPN, even if connection names already exist in the target workspace?
A: No, Deployment Rules are not valid for Data Factory pipelines, they cover semantic models. If you name your connection exactly the same in the target workspace, there will be no rules required.
Q: Are there additional authorization or binding steps required for SPNs to use SQL connections during cross-workspace deployments?
A: Connections are valid within tenant scope - your SPN should be granted either a read or an use permission on the connectiuon object it will run against, both in source as well in the target. If you don't do this, the deployment will fail at validation.
Q: What is the recommended way to automate the swap of SQL connection strings (Server/Database name) during deployment?
A: You can use a variable library and parameterize your pipeline, including the connection selection. The correct way is to store 1 value set per env. Dynamic content can bind to the variable library.
Hope that makes sense - please appreciate by leaving a Kudos or accept it as a Solution to help others.
14 Replies
Hi,
If the deployed pipeline still points to a connection object the service principal cannot “use” in the target workspace, you get RequestValidationFailed, even when a same-named SQL connection exists in TEST. Fabric does not treat “same name” as “same connection.”Is connection mapping (deployment rules) mandatory for data pipelines when deploying via SPN?
For pipelines that call SQL connections, deployment rules are not a reliable fix today because the deploy operation keeps the connection linkage during copy. Fabric’s deployment process keeps connections between copied items and then applies deployment rules to supported properties, but a pipeline’s connection usage often remains tied to the original connection object rather than rebinding by name.
Practical takeaway: assume you must rebind or recreate connections in the target, not depend on name matching.
Extra authorization or binding steps for SPNs to use SQL connections
Yes. There are two separate permission layers:
A. Fabric connection permission
Grant the SPN explicit permission on the connection under Manage connections and gateways. Community threads show this error commonly occurs when the identity deploying or running the pipeline lacks connection access, even if the workspace role is Admin.B. Data source permission
If the connection uses service principal authentication, the SPN also needs permissions at the data source level (Azure SQL DB permissions, storage roles, etc.). Microsoft’s SPN guidance for Data Factory calls this out: create the SPN, then grant it access to the underlying data source.If your SQL connection relies on a gateway or similar mapping, note that Fabric calls out that gateway-to-data-source mapping is not automatically set during deployment and requires configuration in the target item settings.
Recommended way to automate swapping SQL connection strings during deployment
Today, the most dependable approach is “environment-specific connections + post-deploy rebinding”:
Option A: Precreate env connections and rebind after deploy (recommended)
Create an SQL connection in each workspace (DEV, TEST, PROD) using the correct server and database, and store credentials in the target workspace connection.
Ensure the SPN has permission to use each target connection (Manage connections and gateways).
After deploying the pipeline, update the pipeline to point to the target workspace connection (not the DEV connection). This is typically done via item update APIs or your CI/CD tool’s parameter/replace mechanism, depending on how your pipeline definition stores the reference.
Option B: Avoid “connection library variables” inside pipelines if you rely on automated deploys
There are active reports of deployments failing when pipelines include connection configuration patterns that do not validate or rebind cleanly through automation tooling.A quick diagnostic you can run
In the TEST workspace, open the deployed pipeline. If you see a warning like “You cannot access one or more connections used in this pipeline… ask the owner to grant permissions,” you are dealing with connection permission or ownership mismatch, not workspace role.
In Manage connections and gateways, confirm the SPN is listed with permission on the specific connection object used by the pipeline.
Confirm the SQL authentication method. If it is SPN-based, confirm the SPN has the required rights in Azure SQL DB and any network constraints are satisfied.
Hi MJParikh,
Thanks a lot for the detailed explanation,really helpful!
I ended up re-creating the SQL connection in the target workspace and gave the SPN Use permission, and after waiting a bit for propagation, the deployment worked.
I also set up a Variable Library per environment to parameterize the pipeline, which is now working as expected.Appreciate the practical tips on post-deploy rebinding and checking data source permissions,that cleared up a lot of confusion.
Hello, I am having the same issue with you in regards to the SQL connection... I have my SPN added as a user to the connection (also tried with owner) and I get the same error message as you every time. I have created a new connection to use which doesnt help. How long did you have to wait for your permissions to propagate?
Hi CloudVasu
Q: Is connection mapping (Deployment Rules) mandatory for Data Pipelines when deploying via SPN, even if connection names already exist in the target workspace?
A: No, Deployment Rules are not valid for Data Factory pipelines, they cover semantic models. If you name your connection exactly the same in the target workspace, there will be no rules required.
Q: Are there additional authorization or binding steps required for SPNs to use SQL connections during cross-workspace deployments?
A: Connections are valid within tenant scope - your SPN should be granted either a read or an use permission on the connectiuon object it will run against, both in source as well in the target. If you don't do this, the deployment will fail at validation.
Q: What is the recommended way to automate the swap of SQL connection strings (Server/Database name) during deployment?
A: You can use a variable library and parameterize your pipeline, including the connection selection. The correct way is to store 1 value set per env. Dynamic content can bind to the variable library.
Hope that makes sense - please appreciate by leaving a Kudos or accept it as a Solution to help others.
Q: Are there additional authorization or binding steps required for SPNs to use SQL connections during cross-workspace deployments?
A: Connections are valid within tenant scope - your SPN should be granted either a read or an use permission on the connectiuon object it will run against, both in source as well in the target. If you don't do this, the deployment will fail at validation.
In my case, after granting access, it did not work immediately. I removed and re-added the SPN to the SQL connection, waited for propagation, and then the deployment worked successfully.
Q: What is the recommended way to automate the swap of SQL connection strings (Server/Database name) during deployment?
A: You can use a variable library and parameterize your pipeline, including the connection selection. The correct way is to store 1 value set per env. Dynamic content can bind to the variable library.
The recommended approach is to use a Variable Library and parameterize the pipeline, including connection selection.
Maintain one set of variables per environment, and bind them using dynamic content during deployment.I followed the official documentation below, and the deployment is now working as expected:
https://learn.microsoft.com/en-us/fabric/cicd/variable-library/variable-library-cicdThank you for the detailed explanation. This helped me resolve the issue and the deployment is now working as expected
It usually only takes a few minutes, but it’s been a couple of hours now. verify that your Service Principal details are correct
Hi CloudVasu ,
Thank you for reaching out to the Microsoft Community Forum.
Hi MJParikh and deborshi_nag , Thank you for your prompt responses.
Hi CloudVasu , could you please try the proposed solutions shared by MJParikh and deborshi_nag ? Let us know if you’re still facing the same issue we’ll be happy to assist you further.
Regards,
Dinesh
Hi CloudVasu ,
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.
Regards,
Dinesh
