A canvas app does not gain live, server-pushed updates merely by adding a timer. If users need to see new chat messages or a changed video link without polling a data source, one possible design is a Power Apps component framework (PCF) control connected to Azure SignalR Service through an authenticated server-side API.
That design is a professional-development project, not a no-code trick. It introduces Azure resources, client code, identity, monitoring, cost and Power Apps licensing questions. Use it when the real-time requirement justifies that extra surface area.
The architecture
A defensible serverless design has four parts:
- Canvas app: hosts the user experience and exchanges controlled values with the code component.
- PCF code component: opens the SignalR client connection, receives approved events and exposes them to the app.
- Azure Functions: authenticates requests, validates commands and sends authorised messages.
- Azure SignalR Service: maintains client connections and routes server-sent events.
Microsoft's serverless SignalR guidance requires at least a negotiation function and one or more functions that send messages. The negotiation function gives a client a valid endpoint and access token. Do not put an Azure SignalR connection string in a canvas app or browser component.
A safe message path
Suppose the app shares a YouTube URL and a chat message.
The sending path should be:
- The signed-in user submits a command from the app.
- An Azure Function authenticates the caller.
- The function validates the message type, allowed fields, length and destination.
- The function writes durable data to the system of record if the message must survive reconnects.
- The function asks SignalR to notify the correct user or group.
- Connected clients receive the event and refresh only the relevant state.
SignalR is the delivery channel, not automatically the durable database. If chat history, moderation, audit or recovery matters, store those records separately and treat the event as a prompt to retrieve authorised state.
Authentication is not optional
Azure SignalR can issue anonymous or user-bound connection credentials. A workplace app should normally bind the SignalR connection to a verified identity and limit messages to the intended audience.
Check all of these before release:
- how the Function verifies the Microsoft Entra identity or other approved identity
- whether a user can request a token for another user or group
- whether the server validates every client-supplied record ID, URL and recipient
- whether a reconnect can reveal messages the user should no longer see
- where connection strings and application settings are stored
- which events and failures are logged without recording sensitive message content
Never treat a hidden canvas control as an authorisation boundary. Browser traffic and component code can be inspected or manipulated.
PCF and licensing boundaries
Microsoft documents PCF code components for canvas apps, but some component-framework APIs are not available in canvas apps. Check the API reference for every capability you use.
The environment must allow code components in canvas apps. Your deployment also needs the component packaged in a solution and made available in each target environment.
Licensing depends on what the component and app connect to. Microsoft's PCF licensing guidance says a code component that connects directly from the browser to an external service is premium. Azure services can also create consumption or service charges. Confirm the current Power Apps and Azure entitlements for the actual design and users before committing to it.
Do not use this design for every refresh problem
SignalR is worth considering when users need prompt server-pushed events and ordinary refresh or polling creates an unacceptable experience. It is harder to justify when:
- the app can refresh after a user action
- a short timer delay is acceptable
- the update volume is low
- the team cannot operate Azure Functions and client code
- the data needs can be met by a simpler supported control or workflow
A model-driven app or a different front end may also fit the requirement better. Start with the required user experience, latency and support model. Do not begin with SignalR because it makes an impressive demo.
Production checklist
Before a pilot, prove:
- authorised and unauthorised connection attempts
- message validation and maximum payload handling
- group membership changes
- reconnect, duplicate message and out-of-order event behaviour
- persistent history after a client disconnects
- component behaviour on supported browsers and devices
- accessibility of the chat and media controls
- monitoring, alerting, cost controls and incident ownership
- removal or disabling of the component if the Azure service is unavailable
This article describes an architecture. It does not provide a deployable component or prove that an older proof-of-concept is secure against the current platform.
Sources
- Microsoft Learn: Azure Functions development with Azure SignalR Service
- Microsoft Learn: Code components for canvas apps
- Microsoft Learn: Power Apps component framework overview and licensing
Working through a PCF decision that has moved beyond a quick demo? Join the Power Apps Builders Space for build patterns that keep identity, licensing and support in view.