nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Power Automate - Re-Establish Connection

ModernElectric

Good Morning:

I have a large number of Survey123 forms created with individual Power Automate Flow(s) that automatically create a PDF printed report and emails it to selected personnel who need it.

It has become a trend in recent months that I get a complaint from a Superintendent that they did not receive a specific report after their foreman said it was submitted. Investigating the flow(s), they fail and I have to go back in and re-set up the connection, re-establishing the webhook that is created when I build the flow.

I need some guidance on what I need/should be doing to prevent this from continuing to happen.

Find more posts tagged with

Accepted answers

All comments

CodyPatterson

Hey @ModernElectric

From this post:

https://community.esri.com/t5/arcgis-survey123-questions/power-automate-survey123-connector-issue/m-p/1613358#M62547
I saw this comment:

Quick Tip: Keeping the ArcGIS Connectors for Power Automate Refresh Token Valid

Would this be something that would be beneficial?

Cody

abureaux

Connection needs to be refreshed once every 2 weeks. I have a reminder to do it every week, and track the refreshes in SharePoint to avoid such an issue.

Also, you can attach error handling to your flows, so if they do fail, you get notified right away and can investigate. Let me know if you'd like info on this (it's generally pretty easy).

ModernElectric

@abureaux

Yes, I would appreciate info on setting that up in my existing flows. This way, I can be more proactive in catching a failed flow before being yelled at for them not working when someone needs the final reports.

Power Automate use to, at one time, send me an email notification when a flow failed, but have not seen them in awhile.

ModernElectric

@CodyPatterson

Thank you for the feedback and guidance. I will look into the Quick Tip to see how I can benefit

abureaux

At the most basic level, you need three things:

Scopes
Run After
Send an email

Here are the steps:

1. Make two scopes and put all your flow steps into the first Scope. The only real exceptions here are Initialize Variables and the Flow's trigger, neither of which can go into a scope--you can ignore these steps. As for naming the Scopes, that is up to you and it technically doesn't matter; however, most people will refer to this as "Try" and "Catch". Your flow should now look similar to below:

2. Click the ellipses (...) for the second Scope > click "Configure run after" > uncheck "is successful" and check "has failed" > click Done. It should look like this:

You will now notice a red arrow between the two steps. That indicates a different "run after", which is what you want.

3. Finally, within the second Scope add your error handling steps. At minimum, I recommend two things: A) Send an email, and Terminate (set it to "Failed").

3A) The email should go to the flow's owner, and the subject should be something that (presumably) you will recognize. Feel free to customize this any way you want.

But the most important part is the code below. This code will create a link which will take you to the flow that failed. This saves tons of time! To add the code: Click into the Send an email's "Body" field > in the popup, click "Expression" > paste the code as-is > click OK.

concat('https://emea.flow.microsoft.com/manage/environments/', workflow()['tags']['environmentName'], '/flows/', workflow()['name'], '/runs/', workflow()['run']['name'])

3B) Finally, add a "Terminate" step, and set it to "Failed" ("Cancelled" will also work, but I personally use "Cancelled" for other operations). You really want to do this, otherwise whenever a flow fails, it will show up as "Succeeded" because your second Scope executed successfully. This will obviously be really confusing when you start to investigate your flows.

Here is an overview of the full set-up:

TIPS

The "Terminate" steps needs to be the FINAL step in the Scope. As soon as Power Automate runs that step, the flow will fully end, and anything after that step will be ignored. It is for this reason I actually use "Terminate" to help test flows in smaller chunks.
"Terminate" cannot be added to an Apply to Each loop.
You can add a bunch of steps to the second Scope. For example, in my more complex flows I have things like Conditions to delete items from SharePoint if there is an error--this helps avoid duplicate entries and unnecessary extra files. Example:
EDIT: One last tip. When adding multiple steps to your error handling scope, the "Send an email" should be the first real step. Looking at the image above, let's pretend something goes wrong with the "Update item - Process Fail - Job Started (No)" step. In that case, I wouldn't get the notification email, and so would assume everything was okay. Always send the email first, then try to clean up the mess!

ModernElectric

@abureaux

Thank you. I will add this to my design list and see what I can accomplish

CalvinHarmin

I have found ArcGIS connectors unreliable -- lots of authentication errors in the middle of hundreds of other successful runs. This is a separate issue from the 2-week re-authentication issue.

I have changed my use of ArcGIS connector actions to using HTTP GET or POST actions using ArcGIS REST API instead. I'm not sure if this is possible for your workflows but I found it to be more reliable. This relies on getting an AGOL token first to use in the API call. The query output body has a "features" array that contains one or more features (if your query where clause had a match).

Get AGOL token child flow (I use the Solution feature of Power Automate so I can run child flows and have a migration pipeline from a development/test to production environment. Lemme know if you're curious about that). But this all that the child flow is doing -- another API call to get AGOL token:

The actual query API call

Compose attributes of the first result. Or you could do a For Each... action and do something with each feature if you expect to return more than 1.

CalvinHarmin

I also highly kudos the methods @abureaux mentioned.

I will add this: it is extremely helpful to include the Flow Run URL in the email you send yourself so you can one-click jump to that flow history and see what failed. The method get this URL is thankfully very simple. Just put this in a compose or variable or just plug the expression into your email action directly.

concat('https://make.gov.powerautomate.us/environments/', workflow().tags.environmentName, '/flows/', workflow().name, '/runs/', workflow().run.name)

Replace 'https://make.gov.powerautomate.us/environments/' with whatever your own power automate domain is.

That will be the direct URL to review that specific flow run.

FYI this is the raw output of the workflow() expression. The concat() expression above just grabs the relevant bits to assemble the flow run URL correctly after your power automate domain.

{
    "id": "/subscriptions/cc97105b-731d-474d-b89d-251e6750824e/resourceGroups/05B5E599E0E84C08A2129FA883E62107-75C096716CAFE86D98E4DB2EC4DC0B17-ENV/providers/Microsoft.Logic/workflows/af484700-3606-4385-8c8c-c1fe190fdf2c",
    "name": "af484700-3606-4385-8c8c-c1fe190fdf2c",
    "type": "Microsoft.Logic/workflows",
    "location": "usgovtexas",
    "tags": {
        "flowDisplayName": "test: arcgis rest API",
        "capabilities": "Premium",
        "environmentName": "75c09671-6caf-e86d-98e4-db2ec4dc0b17",
        "logicAppName": "af484700-3606-4385-8c8c-c1fe190fdf2c",
        "environmentFlowSuspensionReason": "75c09671:2D6caf:2De86d:2D98e4:2Ddb2ec4dc0b17-None",
        "state": "Enabled",
        "createdTime": "7/3/2025 6:38:25 PM",
        "lastModifiedTime": "7/24/2025 6:23:00 PM",
        "createdBy": "6e1af543-02dd-4eff-979a-c0184fa8e143",
        "triggerType": "Instant"
    },
    "run": {
        "id": "/subscriptions/cc97105b-731d-474d-b89d-251e6750824e/resourceGroups/05B5E599E0E84C08A2129FA883E62107-75C096716CAFE86D98E4DB2EC4DC0B17-ENV/providers/Microsoft.Logic/workflows/af484700-3606-4385-8c8c-c1fe190fdf2c/runs/08584482255021274964740499500CU62",
        "name": "08584482255021274964740499500CU62",
        "type": "Microsoft.Logic/workflows/runs"
    }
}

The concat() expression creates this URL:

"https://make.gov.powerautomate.us/environments/75c09671-6caf-e86d-98e4-db2ec4dc0b17/flows/af484700-3606-4385-8c8c-c1fe190fdf2c/runs/08584482255021274964740499500CU62"

abureaux

I actually provided that code below (under #3A), but for the general URL.

abureaux

From what I have seen, Esri has been greatly improving the built-in connectors over the last year. I feel like some of the more recent issues I've been seeing are a result of all the back-end work they are actively doing. Personally, I find them to now be better than the older REST API method, and am in the (very slow) process of replacing all my older flows with these newer connectors.

However, I have more recently noticed some "blips", where the get items steps doesn't work. But it doesn't last long and my flows all retry on fail so I haven't found it to be a significant hindrance to my workflow (which sees reports being generated nearly constantly for several workflows throughout the work day).

CalvinHarmin

Doh I see it now! You covered all the bases 😁

CalvinHarmin

Hm interesting, I've had the opposite experience -- I've only started using Power Automate ArcGIS connectors a few months ago, and I have had enough issues with the ArcGIS connectors that it was the weakest link in my whole solution and caused me anxiety and time spent tracking down fails and (re)processing things. It thankfully did force me to increase my error handling strategy. But it's been 2-3 weeks since my rewrite without the ArcGIS connectors for querying/updating features, and so far none have failed whereas I would have experienced something on the order of 10-20 fails in the same time period before.

abureaux

Necessity is the mother of invention, after all! Trying to mitigate those exact same problems is what lead me to my current set-up.

Probably worth a new thread, but if you are reprocessing failed runs, you may wish to consider changing how your flows operate.

For example, all my flows are two stages, with the goal of being self-sufficient and error resilient. The first stage is a quick "setup" (and relies on the ArcGIS Enterprise connectors to get my data from the FL), and the second is the "processing" stage, which could be anything from simply generating a report and sending an email, to more complex stuff like approvals, moving data between databases, running related processes, etc.

While a disruption to Esri's services still halt my processes (no way around that), once things are working again on their end, all my flows automatically process the delayed items and I can be assured that nothing is missed.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.