Azure SignalR Service can push events to a supported SignalR client, and Azure Functions can negotiate connections or publish messages. A canvas app does not expose SignalR as a standard connector or native control. To receive pushed events inside the app, you need a supported custom client layer, such as a carefully engineered code component.
That makes this an extension architecture, not a no-code toggle.
The supported Azure pattern
Microsoft documents Azure Functions bindings for SignalR Service. A common web-client flow is:
- A user authenticates.
- A negotiate endpoint returns connection information scoped to that user.
- A SignalR client opens and maintains the connection.
- An Azure Function or another trusted service publishes an event.
- The client receives the event and updates its interface.
For a Power Apps canvas app, steps 2 to 5 require an actual SignalR client. A custom connector only performs request-response API calls; it does not keep a WebSocket connection open to deliver events to ordinary Power Fx formulas.
A defensible Power Apps architecture
Use five explicit components:
- Canvas app: displays and edits business data.
- Code component or external web surface: hosts a supported SignalR client SDK.
- Azure Function negotiate endpoint: authenticates the caller and issues connection details.
- Azure SignalR Service: manages client connections and message fan-out.
- Authoritative data store: keeps durable business state.
Treat SignalR messages as notifications that something changed, not as the only copy of the business event. After receiving a notification, reload the authorised record from the system of record.
Authentication and authorisation
Do not expose the SignalR service connection string to Power Apps, a code component or the browser. It grants service-level capability and belongs in server-side configuration such as Azure app settings or a managed secret store.
Secure the negotiate and publish paths with Microsoft Entra ID or another appropriate identity mechanism. Authorise the user for the specific channel or record. A successfully authenticated tenant user is not automatically entitled to every message.
A code component that connects directly to an external service can also affect the app's premium designation. Verify current component framework licensing before choosing this route.
Data and message shape
Keep events small and versioned. For example:
{
"eventType": "inspection.updated",
"recordId": "8c40b5e1-0000-0000-0000-000000000000",
"version": 3
}
Do not push the complete confidential record unless every client and group assignment has been reviewed. The client can use recordId to request current data through an authorised connector or API.
Failure and recovery
Real-time connections drop. Devices sleep, browser tabs pause and tokens expire. The design needs:
- reconnect behaviour with backoff;
- a visible stale or disconnected state;
- a normal refresh path;
- idempotent processing of duplicate events;
- durable state outside SignalR;
- logging that excludes tokens and sensitive payloads.
SignalR does not guarantee that a disconnected canvas user has processed every notification. If the event matters for audit, payment, approval or safety, persist it and reconcile from the durable source.
When polling is the better answer
Use a timer and Refresh() when updates can be minutes apart, the audience is small and occasional staleness is acceptable. Use SignalR only when the business need justifies custom code, Azure resources, monitoring, licensing review and an operational support burden.
For help deciding whether the real-time requirement warrants this architecture, join the Power Apps Builders Space.