Power Automate

When a Pipeline Breaks Because You Hard-Coded a SharePoint Template ID

Alex Weaver

— 2 min read

Here’s one that got me recently.

Quick preface: this is real.
This is absolutely schoolboy error territory.
I should know better.
I do know better (honest).

Yes, I know 🤣

The Setup

We were using Azure DevOps to deploy a Power App solution from Dev into Test.
Everything deployed cleanly. No errors. No warnings.

Then suddenly…
some of our cloud flows that populate Word templates stored in SharePoint just stopped working in Test.

They worked perfectly in Dev.
They had been working in Test.
And now they didn’t.

The Symptom

The failing flows all had something in common:

  • they used Word templates
  • the templates lived in SharePoint
  • the action configuration looked correct in the designer

At first glance, nothing was obviously wrong.

🔍 STEP 1: Check The Code

This is one i have slowly learnt to lean on more and more during my Power Platform journey. We opened the affected actions and used Peek code.

Even though the action UI showed a document library + template path, under the hood it had been converted into a hard-coded Template ID. As soon as i saw it i knew what i had done wrong and what was going to fix it.

💥 What Actually Broke

Here’s the fun part.

Originally, the Test environment connections were owned by a service account that had access to both Dev and Test SharePoint sites.

So when the flow ran in Test, it was quietly pulling the Word template from Dev.

No one noticed.
Everything “worked”.

Later on, those connections were recreated properly using a Test-only service account (as they should be).

At that point:

  • the flow was still referencing the Dev template ID
  • the Test service account couldn’t access Dev SharePoint
  • the flow started failing immediately

The pipeline hadn’t broken anything, it had just exposed a glaring issue in our solution.

✅ STEP 3: The Correct Way (Environment Variables)

The fix was straightforward once we accepted responsibility!

Instead of letting the action store a template ID, we:

  1. Created Environment Variables for:
    • SharePoint site URL
    • Document library
    • Template path / name
  2. Updated the flow actions to build the reference dynamically using those variables
  3. Set environment-specific values for each environment

🧠 Final Thoughts

This wasn’t a Power Platform bug.
This wasn’t an Azure DevOps issue.
This was a classic case of:

“I should know better”

Once those permissions were fixed, the real problem showed itself.

If you’re moving flows between environments and touching SharePoint templates, take a moment to check Peek code and make sure you’re not accidentally shipping hard-coded IDs.

And with a bit of luck…

this should still work 😉

Read more