Unanswered

Set-SPOSiteScript : Action 1 (triggerFlow) is invalid. Parameter url has an invalid value.

(0) Share

Report

Posted on by Nanda_N

While adding site script into site design in PowerShell, I'm getting this error message(attached). Observed that this issue is happening only when I use the flow(When an HTTP event is received trigger) created in Developer(Environment Type). However the same flow I can add it into Site script from Default environment without any issue.

When I compare the two HTTP URLs( Default and Developer Environment Type) there is a change in url.

Default Env. Type HTTP URL :

https://prod-00.westus.logic.azure.com:443/workflows/9dd4ca27824d4........0e895b459500a/triggers/manual/paths/invoke?api-version=2016-06-01

Developer Env. Type HTTP URL:

https://d2d0c3027........ac57196706544e.08.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/e38d..........42a1916ffa681234561/triggers/manual/paths/invoke/?api-version=1&tenantId=tId&environmentName=12345678-...........5-ac57-196706544e08

"actions": [
        {
            "verb": "triggerFlow",
            "url": "https://d2d0c3027........ac57196706544e.08.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/e38d..........42a1916ffa681234561/triggers/manual/paths/invoke/?api-version=1&tenantId=tId&environmentName=12345678-...........5-ac57-196706544e08",
            "name": "site creation event",
            "parameters": {
                "event": "site creation",
                "product": "SPO"
            }
        },

Is there any limitation while using Developer Environment HTTP URL in Site Script? or any fixes/suggestions would be really appreciated. Thanks.!

Categories:

General topics

Screenshot.png

I have the same question (3)

All responses (4)

Answers (0)

Expiscornovus 33,195 Most Valuable Professional on at

Like (0)

Report

Hi @Nanda_N,

In both flows you used a When a HTTP request is received trigger action? And what are you using in the who can trigger the flow setting?

I assume you followed the steps from this article?

https://learn.microsoft.com/en-us/sharepoint/dev/declarative-customization/site-design-trigger-flow-tutorial

Happy to help out 😁

I share more #PowerAutomate and #SharePointOnline content on my Blog, LinkedIn, Bluesky profile or Youtube Channel

Was this reply helpful? Yes No
GL-21071454-0 2 on at

Like (0)

Report

Has anyone been able to get this to work? I've created a simple Flow (per https://github.com/SharePoint/sp-dev-docs/blob/main/docs/declarative-customization/site-design-trigger-flow-tutorial.md) and tried with "Anyone" and "Any user in the tenant" and nothing seems to work. I can call the endpoint directly using Invoke-RestMethod and that works fine but attempting to register the site script always throws the error. I also tried converting the Flow to a solution and publishing but that didn't make any difference. Using Add-SPOSiteScript and Add-PnPSiteScript both throw the same error.

Was this reply helpful? Yes No
CU24071922-2 2 on at

Like (0)

Report

Did anyone found solution to this, im also having same problem for my pre prod environment

Was this reply helpful? Yes No
Sometimes helpful 2 on at

Like (0)

Report

Adding site scripts is purely a remote function, meaning the code is executed on the SharePoint servers using your raw input (title, description, content). There appears to be some URL validation happening on the server, perhaps as simple as validating that a URL ends in ".logic.azure.com" (or ".us" in gov clouds).

My guess is that URLs being generated with those environment-specific hostnames is a new feature in Power Platform, and the validation on the SharePoint side was not updated. Unclear if there is a way to control that. It was also asked here: Webhook URL difference: prod-logic.azure.com vs environment.api.powerplatform.com.

In the GCC High tenants (which generally seem "a few versions behind"), the When a HTTP request is received trigger always produces URLs with the same hostname, whether the Flow is in the default environment or another, and regardless of that environment's type (including Developer types) or being part of a solution.

Was this reply helpful? Yes No