Skip to integration content

How to integrate Unify with Microsoft Teams

To integrate Unify with Microsoft Teams, create a Workflows webhook for your destination channel and POST an Adaptive Card from a Unify Play. Match the trigger’s authentication setting, then inspect the posted card. Use the alert to give a named reviewer a clear next action.[1][3][4]

Connection
Via webhook
Team collaboration
Tool
Microsoft Teams
Teams Workflows trigger
Data flow
Unify → Microsoft Teams
JSON payload

At a glance

  1. Choose a channel and a person responsible for reviewing the alert
  2. Use the Teams card payload rather than a flat prospect object
  3. Check delivery and reviewer action separately

When this workflow makes sense

Start with the decision your team needs to make, then choose the connection that supports it.

A channel alert is useful when it changes a decision. Give the reviewer the known prospect facts and the reason to look at the account, then state what needs human judgment. Decide whether the channel is a shared review queue or simply a notification surface. Delivery is a technical result; ownership of the next action is an operational decision.

A good fit when

Sales teams working in Microsoft Teams that want a shared review alert when a prospect reaches a defined point in a Unify Play.

Reconsider the plan when

If every event produces a card without a clear reviewer, narrow the Play criteria first. Confirm that the proposed webhook authentication and channel are allowed by the Microsoft tenant.

Design the handoff

Use this framework to agree on the input, the next action, and who owns the result.

Suggested workflow design, based on the documented capabilities below.

StageDecision to make
TriggerChoose the Play stage that creates a useful reason for a person to review the account.
Card contentInclude the known prospect facts and one explicit review action.
OwnershipName the person responsible for follow-up and maintain a workflow co-owner.
CompletionCheck the posted card and the human handoff separately from request acceptance.

Explore the scenarios

Choose the situation that fits your team and work through the proposed plan.

Open a scenario to explore its plan. Checklists track your selections in this page only.

Give the team a useful account alert

A prospect reaches a qualification stage and a rep should review the context in Teams.

The decision that matters

Choose the reviewer before writing the card. Keep the observed facts separate from the action you are recommending.

  1. Choose the channel and the person who reviews incoming cards
  2. Send the fictional Adaptive Card from a controlled Play record
  3. Read the posted card with the reviewer and check the next action
Your validation checklist
0 of 3 checks marked by you
Keep alerts working through an owner change

The person who created the receiving workflow may be unavailable or leave the team.

The decision that matters

Workflow maintenance and sales follow-up need explicit owners. Sharing a channel does not make every member a workflow owner.

  1. Review the workflow owner and add a co-owner
  2. Check that the posting connection and destination remain valid
  3. Send a controlled alert and document who investigates a missing card
Your validation checklist
0 of 3 checks marked by you

Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.

Connect your tools to Unify

Set up your integration or walk through it with our team

Define success before launch

Inspect the data and the intended outcome separately. Connection status is only the first check.

Expected, not tested

The selected channel contains a card showing the fictional prospect and the proposed review action.

Inspect the receiving workflow and the rendered card in the intended channel. An accepted request does not prove that a rep received useful context or acted on it.

Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.

Questions answered

Common decisions when connecting Unify and Microsoft Teams.

How do I connect Unify to Microsoft Teams?

Create a Teams Workflows webhook and send it a JSON POST from a Unify Play. Configure the receiving destination and verify the resulting card.[3]

Can I reuse the flat prospect payload from the other articles?

Use the card envelope in this article for the Teams template. The prospect facts belong inside its Adaptive Card content.[4]

Which authentication setting does this example use?

Anyone, with no Authorization header. Restricted trigger modes require Microsoft authentication and additional setup.[4]

Who owns the receiving workflow?

The workflow is associated with its user owner. Keep a co-owner and valid connections so ownership changes do not interrupt delivery.[5]

Does posting a card update Unify or complete the sales task?

This outbound request establishes delivery to a receiving workflow. A return update or an approval action needs a separately configured path.[1]

Limits & decisions

Check these boundaries before designing a live workflow around the connection.

  • The example creates a notification, not an approval or automatic return sync
  • Trigger authentication and available destinations must fit your Microsoft tenant policies
  • Use Workflows for this setup; legacy Microsoft 365 connector instructions describe a different path
  • No live workflow execution or card delivery has been tested

What the connection supports

Understand the connection, the data involved, and the behavior that matters for a Unify + Microsoft Teams workflow.

Connection flowVia webhook
Prospect data

POST / JSON

Documented behavior at a glance
DecisionWhat to know
DirectionUnify → Microsoft Teams[1]
Receiving workflowTeams Workflows webhook template for channel alerts[3]
RequestPOST with a message envelope and Adaptive Card attachment[4]
OwnershipUser-owned workflow; assign a co-owner for continuity[5]
DestinationA configured channel or chat, subject to the selected workflow and tenant permissions[3]

Technical setup reference

References and requirements for the Microsoft Teams connection.

Connection requirements and setup checklist

Before connecting

  • A Unify Play with a Webhook action
  • Access to Teams Workflows and the destination channel
  • A workflow owner and permission to use the chosen trigger authentication setting
  1. Choose the receiving channel

    In Teams Workflows, choose Send webhook alerts to a channel. Select the destination and the connection used to post messages.[3]

  2. Check trigger access

    For this example, select Anyone on the Teams webhook trigger. Save and copy the complete callback URL. If organizational policy requires tenant-restricted access, validate that authentication path before proceeding.[4]

  3. Configure the Unify request

    Paste the callback URL into a Unify Webhook action. Use POST, JSON, and authentication None. Start with the fictional Adaptive Card below and inspect Expand preview.[1][2][4]

  4. Inspect delivery and ownership

    Send a controlled record and inspect the workflow run and actual channel card. Replace sample values only after checking the display. Assign a co-owner to maintain the workflow if its creator leaves.[3][5]

Request configuration

Method
POST
URL pattern
https://YOUR_GENERATED_WORKFLOW_HOST/YOUR_COMPLETE_CALLBACK_PATH_AND_QUERY
Headers
Content-Type: application/json
Authentication
This example uses the trigger’s Anyone option and authentication None in Unify. Do not add an Authorization header. Protect the complete callback URL. Tenant-restricted options require a compatible Microsoft authentication token and a separately validated token lifecycle.

Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]

Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.

Example handoff payload

Start with a fictional prospect. Validate the resolved values before using a real record.

Inspect the sample payload and field mapping
Example request body
{
  "type": "message",
  "attachments": [
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "contentUrl": null,
      "content": {
        "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
        "type": "AdaptiveCard",
        "version": "1.2",
        "body": [
          {
            "type": "TextBlock",
            "text": "Prospect ready for review",
            "weight": "Bolder",
            "wrap": true
          },
          {
            "type": "FactSet",
            "facts": [
              {
                "title": "Name",
                "value": "Alex Morgan"
              },
              {
                "title": "Email",
                "value": "alex@example.com"
              },
              {
                "title": "Company",
                "value": "Example Company"
              },
              {
                "title": "Domain",
                "value": "example.com"
              }
            ]
          },
          {
            "type": "TextBlock",
            "text": "Next step: review account context before follow-up.",
            "wrap": true
          }
        ]
      }
    }
  ]
}

Fictional data. Replace sample values before using a real Play.

Microsoft Teams expects a card envelope for this workflow. Keep type, attachments, contentType, and the Adaptive Card structure; replace only the fictional prospect values and message copy. The flat payload used by the other webhook articles is not interchangeable with this example. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2][4]

Payload fieldValue to send
attachments[0].content.body[1].facts[0].valueUse {{ person.first_name }} and {{ person.last_name }} for the Name fact
attachments[0].content.body[1].facts[1].valueUse {{ person.email }} for the Email fact; decide how missing values should appear
attachments[0].content.body[1].facts[2].valueUse {{ company.name }} for the Company fact
attachments[0].content.body[1].facts[3].valueUse {{ company.domain }} for the Domain fact

The prospect facts live inside the Adaptive Card’s FactSet. Preserve the envelope and map the values shown in the example. The template posts the card; it does not infer a card from arbitrary prospect keys.

Troubleshooting

Start with the stage where the expected data or action stops appearing.

The trigger rejects the request

Check the complete URL and authentication mode. Anyone requests must omit the Authorization header; tenant-restricted requests need an appropriate token.[4]

The workflow runs but no useful card appears

Inspect the posting action, connection, destination, and card JSON. Start with the complete sample envelope before replacing its values.[3][4]

Alerts stop after an owner change

Workflows belong to users. Check ownership, connections, and enabled state, and maintain a co-owner for continuity.[5]

Sources & review

Official documentation reviewed on September 15, 2026.

Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.

Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.

Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.

  1. [1] Unify: Webhook action
  2. [2] Unify: Webhooks in Plays
  3. [3] Microsoft: Send messages using incoming webhooks
  4. [4] Microsoft: Teams webhook schema and authentication
  5. [5] Microsoft: Workflows setup and ownership

Get started with Unify

Create your account or book a demo with our team