Document a user mention notification pattern

What this pattern solves

Search intent

Help a Power Platform builder understand when to use Teams Adaptive Cards Document a user mention notification pattern, how to implement it, and what mistakes to avoid before using it in a production business app.

Problem

Power Platform teams often need to document a user mention notification pattern but lose time inventing structure, ownership, validation, and handoff details from scratch.

What the finished pattern should include

• The flow has a clear trigger, scoped actions, tracked outcomes, and an exception path.
• Notifications or approvals tell users what happened and what action is required.
• Support owners can review failed runs without reverse-engineering the workflow.

Solution

Adaptive Card workflow for Document a user mention notification pattern:
Trigger -> Get source record -> Compose card JSON -> Post card in Teams -> Wait for response -> Update source record

Card payload starter:
{
  "type": "AdaptiveCard",
  "version": "1.4",
  "body": [
    { "type": "TextBlock", "weight": "Bolder", "text": "Document a user mention notification pattern" },
    { "type": "TextBlock", "wrap": true, "text": "Review the request and choose an outcome." }
  ],
  "actions": [
    { "type": "Action.Submit", "title": "Approve", "data": { "outcome": "Approved" } },
    { "type": "Action.Submit", "title": "Reject", "data": { "outcome": "Rejected" } }
  ]
}

Implementation checklist

• Confirm the Teams & Adaptive Cards scenario and the business user this pattern supports.
• Identify the data source, owner, security model, and exception path before building.
• Build the smallest reusable version first, then add optional branches or polish.
• Test with realistic data, permissions, edge cases, and handoff expectations.
• Link this pattern to its collection, topic hub, and related implementation patterns.

Step-by-step instructions

• Build the Adaptive Card payload and routing logic needed for Document a user mention notification pattern.
• Post the card from Power Automate to the correct chat, channel, or user.
• Parse the response and update the source record with outcome, responder, and timestamp.
• Test timeout, retry, duplicate response, and missing user scenarios.

When to use

• Use when a maker or delivery team needs to document a user mention notification pattern in a repeatable way.
• Use when the pattern needs to survive handoff from build to support.
• Use when app, flow, data, and governance decisions need to stay aligned.

When not to use

• Avoid when the work is a throwaway prototype with no production path.
• Avoid when an enterprise standard already provides a required implementation method.

Common mistakes

• Skipping ownership details because the builder still remembers how it works.
• Treating environment, permission, and connector assumptions as obvious.
• Publishing without a clear support path for failed saves, failed flows, or access issues.

Troubleshooting

• If users cannot complete the pattern, test permissions and required fields first.
• If support teams cannot maintain it, reduce hidden logic and document the source of truth.
• If performance is weak, review delegation, connector calls, table design, and trigger scope.

FAQ