GitHub Actions Deploying a solution with Flows as SPN

(2) Share

Report

Posted on by Lucas001

2,567 Super User 2026 Season 1

Hi all,

I am using GitHub Actions to deploy a solution and so far it works as expected.
The only issue I am facing is that user aware connectors must be owned by a Service Account (SA) top be able to get files, send mails etc.

I am using a Service Principle to deploy the solution, with that the flow and all connections are now owned by the SPN, which is good for governance etc but I the flow with that setup is turned off.

Makes sense as my SPN cannot have Connections to Outlook, SharePoint and Excel, I also don't want to go into all flows and connect them again.

What I am trying to do is use GitHub Actions + PowerShell to share the flow and update the connection references automatically, that unfortunately fails.
Any better way to do that or recommendations on how to handle flows in these cases?

Categories:

Building flows

I have the same question (0)

All responses (3)

Answers (1)

Sort by

Verified answer

11manish 3,333 on at

Like
a
(2)

Report
Copy link

Link copied!

It seems that the issue occurs because service principals cannot own or authenticate user-based connectors like Outlook, SharePoint, or Excel.

As a result, flows deployed via SPN are turned off due to invalid connections.

The recommended approach is to use a licensed service account to create and own connections and connection references in each environment, then map those connection references during solution deployment using deployment settings files.

Fully automating connection reassignment via scripts is not reliably supported, so the correct pattern is to separate deployment (SPN) from runtime authentication (service account).

Was this reply helpful? Yes No
Suggested answer

Valantis 6,735 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi @Lucas001,

The SPN can't own OAuth connections so flows come in turned off. The correct solution is the deployment settings file approach.

Microsoft docs confirm you can pre-populate connection references and environment variables for automated deployments by passing a deployment settings JSON file to the import-solution action. You create the connections in the target environment under your Service Account beforehand, grab the connection IDs, and put them in the deploymentSettings.json file referencing each connection reference logical name. The import-solution action then maps them automatically and turns the flows on.

In your GitHub Actions YAML:

- name: Import Solution
uses: microsoft/powerplatform-actions/import-solution@v1
with:
environment-url: ${{ vars.TARGET_URL }}
app-id: ${{ secrets.CLIENT_ID }}
client-secret: ${{ secrets.CLIENT_SECRET }}
tenant-id: ${{ secrets.TENANT_ID }}
solution-file: solution.zip
deployment-settings-file: deploymentSettings.json

The deploymentSettings.json structure:

{
"ConnectionReferences": [
{
"LogicalName": "your_connectionreference_logicalname",
"ConnectionId": "connection-id-from-target-env",
"ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_sharepointonline"
}
]
}

To automate generating this file you can use pac solution create-settings to generate the template from your solution, then replace the connection IDs via PowerShell in the pipeline before import.

The connection IDs themselves you get by pre-creating the connections in the target environment under the Service Account once, then querying them via the Power Platform API or pulling them from the environment in a pipeline step.

Ref: https://learn.microsoft.com/en-us/power-platform/alm/conn-ref-env-variables-build-tools

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
Lucas001 2,567 Super User 2026 Season 1 on at

Like
a
(3)

Report
Copy link

Link copied!

Hi @11manish,@Valantis,

thanks to both of you. I really just missed some settings for the settings.json after that the deployment as SPN with connections mapped to the SA once being created before worked well.

Was this reply helpful? Yes No