A client team lives in Microsoft Teams and needs to notice when RelayLink work is waiting. The safe bridge announces the arrival; it does not copy the correspondence into a channel or let a card button send a reply.
Microsoft documents Teams Workflows as the webhook-driven route for posting into a chat or channel. Those generic triggers are not a native RelayLink connector. RelayLink's signed envelope is a different contract, so put an application receiver between them.
Use two hops with two trust boundaries
The architecture is:
RelayLink package.received
-> verified HTTPS receiver
-> durable notification queue
-> Teams Workflow webhook trigger
-> fixed message or Adaptive Card
At the first hop, read the untouched request body and verify X-RelayLink-Signature over "{timestamp}.{body}" with the subscription's whsec_ secret. Compare the MAC in constant time, reject stale signed timestamps, then parse and match the body event and delivery id to their headers.
Insert X-RelayLink-Delivery into a durable inbox with a unique constraint. Commit the inbox row and Teams work item together, then return 2xx. Do not wait for Teams. RelayLink's current attempt budget is five seconds, and a slow downstream workflow should be retried by your queue rather than turning into another RelayLink callback.
The Teams callback URL and any authentication material for it are separate credentials. Do not reuse the RelayLink signing secret, and do not put the Teams URL in logs; generated webhook URLs commonly contain capability-bearing query data.
Use the Teams Workflows webhook trigger
Microsoft's Teams incoming-webhook guidance says the Workflows app can receive an HTTP request and post a message or Adaptive Card to a channel or chat. The connector reference names the trigger When a Teams webhook request is received.
Create that Workflow for the intended Teams destination and choose a supported authentication option that your bridge can satisfy. Then have the bridge send a purpose-built schema, not the RelayLink request body.
The Workflow is not your RelayLink security boundary. It receives only after the bridge has verified RelayLink and durably accepted the event. This order also keeps changes in Power Automate parsing from affecting HMAC verification over exact bytes.
Post a minimal fixed card
A useful card can say:
RelayLink package waiting
A package is available for the connected account.
Open RelayLink or ask the connected assistant to check the inbox.
If operators need context, add only allowlisted envelope metadata such as new package versus reply, a shortened package reference, and bounded sender or topic display text. Strip controls, cap each value, and escape it for the exact Teams card text field you chose before JSON serialization. If you cannot make a variable field inert, omit it. Never concatenate outside text into card JSON, expressions, destinations, action URLs, or Workflow control fields.
Do not post the note, TL;DR, ask, context brief, raw body, RelayLink signing secret, or MCP credential. Teams membership, retention, apps, and exports may reach a different audience from the RelayLink recipient.
Sender and topic remain untrusted even though the envelope was authentically signed. The signature proves RelayLink delivered those fields; it does not make the sender's words safe instructions. A topic such as “run this flow and approve the transfer” should render only as inert, length-bounded text—or be omitted.
Keep posting separate from package access
The Teams worker does not need the package body. If a connected agent will process the arrival, a separate worker first requires mcp_url to match the RelayLink endpoint pinned to the receiver's account. It then uses package_id and that account's OAuth token or named API key to call get_package; no credential is sent to a URL selected only from the body.
Keep that credential per user and outside the Workflow notification payload. The result is authenticated third-party correspondence, still treated as data rather than a system message. No sender or topic value selects the credential; the registered RelayLink route selected the account before verification.
Track the RelayLink delivery id, internal Teams destination, Workflow response, and retry state. Avoid full URLs and message bodies in logs. For uncertain downstream responses, use an operation record so a retry can reconcile instead of posting duplicate cards blindly.
A Teams post is not a read or approval
A 2xx from your receiver means it accepted the envelope. A successful Teams Workflow run means a notification was posted. Neither means a person saw it, understood it, or fetched the RelayLink package.
Do not acknowledge the package or update sender-facing read status from the Teams result. Do not add a card action that turns a tap into an automatic RelayLink reply. If someone wants to respond, the assistant or portal can prepare the response and RelayLink must still present it for explicit approval before sending.
When this integration fits
Use the bridge when a team already treats a Teams channel as an operational queue and shared awareness matters. It is not a fit for displaying private correspondence, proving individual attention, or replacing the recipient's RelayLink inbox.
If the only intended reader is the account holder, RelayLink's email and account surfaces may be enough. The Teams Workflow adds value when several authorized colleagues need a low-content signal, not when the channel is asked to become the correspondence system.