# How to Send Power Automate Flow Results to Your Phone

> Post one selected cloud-flow result to a shared PingRoom Room with a protected webhook URL and a retry-safe event key.

- Published: 2026-10-18
- Author: PingRoom
- Category: Developers
- Topics: Power Automate push notification, Power Automate phone alert, Power Automate HTTP notification
- Canonical: https://pingroom.io/blog/power-automate-push-notifications
- Cover image: https://pingroom.io/blog/power-automate-push-notifications-cover.webp
- Cover description: Two PingRoom avatars guide one brass result token from a branching miniature flow into a shared dish while Pingo watches.

To send a Power Automate cloud-flow result to a phone, add one **HTTP** action after the result is final and post a short JSON body to a PingRoom incoming webhook. Put the current flow run name in the `Idempotency-Key` header so a retry of that action does not create a second Ping.

This is a webhook recipe, not a native Microsoft or PingRoom connector. Power Automate decides that the result is ready. PingRoom carries the selected update to a Room.

## Choose the destination that already fits your group

Microsoft retired the standalone Power Automate mobile app on August 31, 2026. [Microsoft's current guidance](https://learn.microsoft.com/en-us/power-automate/introduction-to-button-flows) says existing cloud flows continue to run and points people toward Teams, email, the Power Automate web portal, and Power Apps.

Start with the route that matches the people and task:

| Need                                                   | Better starting point                                                                                                           |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| Notify colleagues who already work in Microsoft Teams  | Send a Teams message or card                                                                                                    |
| Send a routine personal update                         | Send email                                                                                                                      |
| Open a flow-built app in a specific context            | Use the [Power Apps Notification connector](https://learn.microsoft.com/en-us/power-apps/mobile/power-apps-mobile-notification) |
| Share one concise result with an opt-in Room           | Post to a PingRoom incoming webhook                                                                                             |
| Preserve a durable audit record or critical escalation | Keep the source system and existing escalation path                                                                             |

Power Apps push requires an app the maker can access, and its notification action targets one user or security group at a time. A PingRoom Room is useful when the destination is the shared group rather than a Power App.

The Room owner needs active **PingRoom Pro**. Your Power Automate environment also needs to expose the HTTP action you plan to use. Microsoft documents both built-in and premium HTTP connectors, while connector entitlement and tenant data policy determine what a maker can add and run. Confirm the action is available in your flow before building the rest of this recipe.

## Prepare one result worth interrupting people for

Put the HTTP action after the branch where a person can act on the outcome. A review becoming ready is useful. Every row touched during processing usually is not.

This example assumes the flow has already produced two variables:

| Variable      | Example                            | Rule                                                  |
| ------------- | ---------------------------------- | ----------------------------------------------------- |
| `pingTitle`   | `Review ready`                     | Keep it at 40 characters or fewer                     |
| `pingMessage` | `Quarterly partner brief is ready` | Keep it at 120 characters or fewer for a private Room |

Create those values from trusted dynamic content before the HTTP action. Do not put credentials, personal records, raw form submissions, or long error output on a lock screen.

## Create the Room and protect its webhook URL

In PingRoom, create or choose a private Room, then open **Settings → Connections → From another app**. Add an incoming webhook named **Power Automate**, keep **Quick Ping** on **Custom message**, save it, and copy the complete URL. The [incoming-webhook walkthrough](/blog/webhook-to-push-notification) covers the browser setup.

The URL contains the credential for posting into that Room. Store it in protected flow configuration appropriate to your tenant. Do not paste it into a description, screenshot, shared template, or message.

In the HTTP action's **Settings**, enable **Secure Inputs** and **Secure Outputs** so the URL and response are hidden from ordinary run-history views. [Microsoft documents those controls](https://learn.microsoft.com/en-us/power-automate/how-tos-use-sensitive-input). They reduce accidental disclosure in history; they do not turn a broadly shared flow into a safe secret store. Limit who can edit the flow and rotate the PingRoom webhook secret if the URL is exposed.

## Configure the HTTP action

Add **HTTP** after the selected result branch and use these values:

| HTTP field               | Value                              |
| ------------------------ | ---------------------------------- |
| Method                   | `POST`                             |
| URI                      | the protected PingRoom webhook URL |
| Header `Accept`          | `application/json`                 |
| Header `Content-Type`    | `application/json`                 |
| Header `Idempotency-Key` | expression `workflow().run.name`   |

Microsoft's [workflow-expression reference](https://learn.microsoft.com/en-us/azure/logic-apps/expression-functions-reference#workflow) applies to Power Automate and defines `workflow().run.name` as the current run name. In the designer, choose the **Expression** tab for the header value and enter the expression without inventing a new timestamp or GUID.

Use this JSON in **Body**. Insert `pingTitle` and `pingMessage` with the designer's dynamic-content picker. Insert `workflow().run.name` through the Expression tab where shown.

```json
{
  "title": "@{variables('pingTitle')}",
  "message": "@{variables('pingMessage')}",
  "data": {
    "source": "power-automate",
    "flow_run": "@{workflow().run.name}"
  },
  "correlation_id": "@{workflow().run.name}"
}
```

The `Idempotency-Key` is an HTTP header, not another body field. Keep the body unchanged when Power Automate retries the same action. PingRoom can then return the completed response for that key instead of creating another Ping. A different flow run receives a different run name and therefore a different event identity.

If one source event can start several separate flow runs, use that source event's immutable ID instead. A flow-run name prevents duplicate Pings from retries inside one run; it does not merge separate runs that happen to describe the same source event.

![Two PingRoom avatars test a sealed brass URL capsule and a miniature retry loop while Pingo watches one returning token reach the same receiver.](/blog/power-automate-push-notifications-1.webp)

The miniature mechanism is an illustration, not Power Automate or PingRoom UI. [Pingo the Pigeon](/Pingo), PingRoom's fictional CMO, is only observing the retry. He cannot read the webhook URL, enter a private Room, edit a flow, or send a Ping. People configure and own the workflow.

## Set retries without changing the event identity

Power Automate actions can use fixed or exponential retry policies. [Microsoft recommends exponential retry behavior](https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/error-handling) for transient failures. Whatever policy you choose, leave the header and body mapped to values that remain stable for that run.

The safe pattern is:

- same flow run and same body → same key;
- changed event or changed body → new key;
- a new `guid()` or current timestamp on every attempt → not retry-safe.

PingRoom returns `409 idempotency_conflict` if the same key arrives with a different body. That is a signal to fix the mapping or choose the correct event identity, not to suppress the error and keep sending.

## Test acceptance, replay, conflict, and failure

Use a test flow branch, a private test Room, and non-sensitive copy:

1. Run the flow once and confirm one Ping with the expected title and message.
2. Resubmit the exact captured request with the same run name and body. It should not create a second Ping.
3. In a controlled test, reuse that key with changed copy and confirm the webhook returns HTTP `409`.
4. Temporarily point the test action at a disabled test webhook and confirm the non-2xx response is visible to the flow's failure path.

Our production receipt runs the documented request shape against a local mock of PingRoom's current webhook contract. It checks POST, JSON headers, title and message limits, run-name identity, exact replay, changed-body conflict, and a disabled-webhook response. It does not run inside a live Power Automate tenant or a live PingRoom Room, so the harmless end-to-end test still belongs in your environment.

## Read HTTP 200 correctly

HTTP `200` with `success: true` means PingRoom accepted the request and created or returned the Ping for that event key. It does not prove that every phone displayed an alert. Connectivity, operating-system notification permissions, Focus modes, battery settings, and Room preferences still affect device delivery.

The original Microsoft system remains the source of truth for the work item and the flow run. PingRoom is the attention path to the Room, not the audit database or flow manager.

Review the [complete incoming-webhook contract](/documents/webhooks) for current fields, limits, cooldown behavior, and error codes. PingRoom accepts one new Ping every five seconds by default, so aggregate a burst before HTTP instead of sending one interruption for every item.

When the four tests pass, [create or choose the destination Room](/app/rooms), turn on only the result branch someone should act on, and keep the detailed record in its original system.

_The two editorial illustrations were created with AI using approved PingRoom character references and reviewed by the PingRoom team._