How to send a Microsoft Teams Adaptive Card from Journey Builder (no code)

You’re dropping one simple step into Journey Builder that posts a Microsoft Teams Adaptive Card right into the channel where your team actually works. The card auto-fills with Journey fields like name, email, order/lead ID & segment; so it reads like a real message, not a system dump: “New VIP lead: Jane at ACME - View in CRM.” No tickets. No waiting on devs. Just paste the card layout, click to insert fields, and hit activate.

Why bother? Because an Adaptive Card is more than a notification. It’s a clear next step at the exact moment the journey fires. Sales sees “New VIP lead” with a deep link, Support gets “Bug #2837. Assign?” Ops gets “Payment failed. Retry?” Work moves forward instantly instead of disappearing into inboxes or task queues.

It’s reliable, too. You set a quick timeout and a couple of retries, keep Debug on while testing, then save the whole thing as a reusable template for the next campaign. In short: one tiny step that turns slow handoffs into real-time, in-channel action.

Why marketers should care:

• Speed to action: Leads/tickets don’t sit in inboxes—Sales/CS get a rich card in seconds. Expect faster speed-to-lead and fewer “missed” handoffs.
• Clarity, not chaos: The card carries the context you choose (name, email, offer, next step), so there’s less back-and-forth and fewer mistakes.
• Own the last mile (no dev tickets): You can add, edit, and ship this from the journey you already manage. Market moves → you move.
• Measurable impact: Watch lead response time, handoff SLA, and resolution time improve when the right people get the right info instantly.
• Scales everywhere: Use the same pattern for high-value leads, VIP purchases, churn risks, failed payments—anything that deserves a fast, human response.

Where this shines

1. High-value lead arrives → Teams gets “New VIP lead: {{FirstName}}” with a deep link to CRM.
2. Bug reported → “Bug #{{ID}} for {{FirstName}}” lands in #engineering with assign/acknowledge.
3. Order update → Card posts to #ops with shipment status and the customer’s email.

What it replaces

1. Slow email threads, CRM tasks no one sees, and “who’s on this?” confusion.
2. This is a real-time, in-journey nudge that moves work forward.

Think of the card like a rich notification. Pick the moment (new lead/bug/VIP purchase), the message (bold title + 1–2 facts + optional link), and where it lands (the channel behind your endpoint).

Steps to create a webhook in Microsoft Teams:

1. Open Microsoft Teams.
2. Go to the channel where you want to post messages.
3. Click the three dots (…) next to the channel name → Connectors.
4. In the list, find Incoming Webhook → click Configure.
5. Give the webhook a name and optionally upload an image (for the message avatar).
6. Click Create → Teams will generate a Webhook URL.
7. Copy this URL.

You can now send JSON payloads (via POST) to this endpoint.

Headers: Content-Type: application/json (+ Authorization: Bearer {{token}} if Graph/bot).

‍Body: paste Adaptive Card JSON and inject Journey fields via the editor. Defaults:Timeout 10s, Retry ×2 (429/5xx), Alert channel: Slack/Teams. Token pattern: add a pre-auth step if your endpoint needs a fresh token.

{
  "type": "message",
  "attachments": [
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "content": {
        "type": "AdaptiveCard",
        "version": "1.5",
        "body": [
          {
            "type": "TextBlock",
            "weight": "Bolder",
            "text": "Bug #2837 for {{Journey.FirstName}}"
          },
          {
            "type": "TextBlock",
            "text": "Assigned to: {{Journey.Email}}"
          }
        ]
      }
    }
  ]
}

Turn Debug = ON, push one contact, confirm a card appears in Teams and the log shows HTTP 200 + the mapped values. Add a Decision Split (success path vs fallback).

Turn Debug OFF, activate the Journey, spot-check the channel for early sends, and watch your alert path for failures.

For webhooks that send dynamic cards to Microsoft Teams, response variables are not required—CloudRelay handles the delivery directly, so you can post updates into Teams channels without extra configuration.

In addition, CloudRelay automatically provides three built-in response variables: request, response, and error. If the error variable is not empty, you can configure a Decision Split to route failures into a separate path, for example to trigger an internal notification so issues are caught immediately.

Enable Debug Mode to run a single contact through CloudRelay. This will generate a detailed log on our dashboard, including request payloads, responses, and any errors, so you can clearly confirm the setup. For example, you should see a Teams card delivered and an HTTP 200 response with your mapped values.

Once validated, add a Decision Split in Journey Builder to define a success path and a fallback path.

Note: Debug Mode is designed for testing only. It provides full transparency into the transaction flow and should be disabled once your integration goes live. Debug logs are stored no longer than 7 days and are automatically discarded afterwards.

Values you label as Response Variables are usable immediately in splits. To use one in email content, write it to a Data Extension first.

Share only what’s needed on the card, avoid unnecessary PII, keep Debug off in production, and use regional routing (EU/US) that matches your policy.