ExamFinch.com My Study

Study guide

8.2 Configure Adaptive Cards

Practice this exam

Microsoft Certified: AI Agent Builder Associate AB-620

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Candidate Profile & Prerequisites 1.3 Skills Map & Study Strategy

2 Plan Integration, Identity & Channels

2.1 Plan Integration with Enterprise Systems 2.2 Plan Identity Strategy 2.3 Plan Channels and Deployment

3 Responsible AI, Security & Reuse

3.1 Plan Responsible AI Strategy 3.2 Security and Governance Considerations 3.3 Plan Reusable Agent Components 3.4 Design Agents for Internal or External Audiences

4 Agent Flows Fundamentals

4.1 Create an Agent Flow 4.2 Human-in-the-Loop Agent Flows 4.3 Configure Actions and Connectors in Flows

5 Agent Flow Monitoring & Resilience

5.1 Monitor Agent Flows 5.2 Input and Output Parameters 5.3 Error Handling in Agent Flows

6 Topics Configuration Core

6.1 Add Agent Flows to a Topic 6.2 Configure Agent Response Formatting 6.3 Add Tools to a Topic

7 Advanced Topic Responses

7.1 Custom Prompts for Advanced Responses 7.2 Custom Knowledge Sources for Advanced Responses 7.3 API and Send HTTP Request Responses

8 Generative Answers, Cards & Variables

8.1 Configure the Generative Answers Node 8.2 Configure Adaptive Cards 8.3 Manage Variables

9 Enterprise Knowledge Sources

9.1 Connect to Copilot Connectors 9.2 Connect to Power Platform Connectors 9.3 Connect to Azure AI Search

10 Add Tools to Agents

10.1 Configure and Monitor Computer Use 10.2 Configure MCP Tools 10.3 Tools via Existing Custom Connectors 10.4 Add REST APIs to an Agent

11 Multi-Agent Collaboration

11.1 Design Multi-Agent Solutions 11.2 Integrate a Foundry Agent 11.3 Integrate an Existing Copilot Studio Agent

12 Fabric Data Agents & A2A

12.1 Integrate a Fabric Data Agent 12.2 Multi-Agent Solutions with A2A Protocol

13 Integrate Agents with Azure

13.1 Generative Answers with Azure AI Search & Foundry 13.2 Foundry Model Catalog for Custom Prompts 13.3 Monitor Agents with Application Insights

14 Evaluate Agent Performance

14.1 Create a Test Set 14.2 Choose an Evaluation Method 14.3 Review Test Results

15 Application Lifecycle Management

15.1 Create a Solution 15.2 Add Existing Agents to a Solution 15.3 Create and Use Environment Variables 15.4 Power Platform Pipelines for Agents

8.2 Configure Adaptive Cards

Key Takeaways Explain This Topic AI

Ask with Adaptive Card is for interactive collection with Action.Submit; Message-node Adaptive Cards are for non-interactive display.

Cards are authored as Adaptive Card JSON (schema versions limited by channel) or converted to Power Fx formulas for dynamic binding.

Submit actions populate output variables automatically from input ids; Edit Schema fixes incorrect generated types.

Channel support differs: Web Chat may support newer schema than Teams or Omnichannel live chat—always design for the production host.

Cards beat plain text when multi-field forms, validation, layout, or structured choices reduce conversation friction.

Last updated: August 2026

8.2 Configure Adaptive Cards

Quick Answer: Use Ask with Adaptive Card for interactive forms with Action.Submit , author JSON (or Power Fx Formula cards) with input id s, let Copilot Studio map outputs to variables, and test on every target channel because schema and action support differ.

AB-620 expects you to configure adaptive cards as a first-class topic skill—not as decorative UI fluff. Cards collect structured data, reduce multi-turn chatter, and pair with flows, tools, and generative answers.

Two card surfaces in Copilot Studio

Surface Node Interaction Typical use

Interactive form Ask with Adaptive Card User must submit; outputs → variables Multi-field intake, confirmations, bookings

Display card Message (or Question prompt chrome) with Adaptive Card media Informational; no submit contract required Order summary, status board, rich results

Microsoft’s rule of thumb: if the card is only meant to show information, put it on a Message node. The Ask with Adaptive Card node is for interactive cards that include at least one submit path so the conversation can continue with stored answers.

Schema versions and channel support

Adaptive Cards are platform-agnostic JSON, but hosts cap versions and actions :

  • Host / channel Practical schema note Action caveat
  • Copilot Studio test chat Can render newer cards (docs reference 1.6 in test) Test is not production

Bot Framework Web Chat (default website) Up to 1.6 patterns in many setups Action.Execute not supported in some Web Chat paths

  • Teams Often limited to 1.5 Follow Teams Adaptive Card validation guidance
  • Omnichannel live chat widget Often limited to 1.5 Verify before shipping contact-center experiences

Design for the strictest production channel , not only the Studio canvas. A card that works in test but fails Teams validation is a failed deployment.

  • Core JSON shape (conceptual): {
  • "$schema": "http://adaptivecards.microsoft.com/schemas/adaptive-card.json",
  • "type": "AdaptiveCard",
  • "version": "1.5",
  • "body": [ /* TextBlocks, Inputs, Containers, ColumnSets */ ],
  • "actions": [ { "type": "Action.Submit", "title": "Submit", "data": { } } ]
  • }
  • Inputs, validation, and output variables

Common input element types you will see in exam scenarios:

  • Element Role
  • Input.Text Free text, optional isRequired , regex , errorMessage , multiline
  • Input.Number Numeric fields
  • Input.Date / Input.Time Temporal values
  • Input.Toggle Boolean switches
  • Input.ChoiceSet Single or multi select lists

Each input needs a stable id . On successful submit, Copilot Studio creates output variables named from those ids (and types inferred from the card). If inference is wrong, open node Properties → Edit Schema and correct variable names/types manually.

Submit actions

Interactive cards require a submit action—commonly Action.Submit with a title users understand (“Submit,” “Confirm booking”). Best practices for multi-card conversations:

Put a unique identifier in data (for example actionSubmitId ) so the agent or custom client can tell which card was submitted when users click an older card still visible in history.

Isolate handlers when consecutive cards appear; stale clicks on prior cards are a known UX risk.

On custom web chat hosts, disable buttons after first click to prevent double submit.

Invalid responses and interruptions

While the agent waits for a card submission, free text is treated as invalid unless it interrupts to another topic.

  • Property Purpose
  • How many reprompts Repeat up to 2 times (default), once, or don’t repeat
  • Retry prompt Optional message plus re-send card

Allow switching to another topic Default on: interrupting intents can run, then the card is resent when control returns

Use interruptions carefully: a user typing “cancel” should reach Reset/End paths rather than three useless card retries.

JSON vs Power Fx Formula cards

Authoring options:

  • Built-in Adaptive Card designer (subset of full Adaptive Cards Designer features)
  • Card payload editor with raw JSON

Formula mode — converts JSON into a Power Fx object formula so you can bind Topic.* , Global.* , and (via prepared variables) system context

Binding dynamic values

Hard-coded titles are fine for static forms. Real agents need personalization:

Switch Properties to Formula

Replace static strings with references such as Topic.Title , Global.CustomerName , or concatenated text ( "Hello " & Topic.FirstName )

Pre-compute complex strings with Set a variable value if you need values that are awkward inside the card formula

Important: After deep formula editing, you may not freely flip back to the original JSON. Keep a JSON backup in comments or source control for iterative design.

Community and Q&A guidance also notes that not every system variable interpolates magically inside static JSON—copy needed values into topic/global variables first, then reference those in Formula mode.

When cards beat plain text

  • Situation Prefer Adaptive Card Prefer text / Question / quick replies
  • Many fields at once (name, date, cost center, justification) Yes — single submit Many Question nodes feel slow
  • Regex/format validation on the form Yes — isRequired + regex Harder in free chat
  • Visual layout (columns, status, images) Yes Plain paragraphs
  • One simple yes/no Optional Multiple-choice Question may be enough
  • Channel without reliable card support Fallback text path Safer
  • Legal word-perfect disclosure Display card or Message text Avoid generative paraphrase

Cards also pair well with agent flows : collect fields → validate with Condition nodes → call flow → show confirmation card. That deterministic spine is classic AB-620 multi-step design.

Adding an Ask with Adaptive Card node

Add node → Ask with Adaptive Card .

… → Properties → Edit adaptive card .

Design elements or paste JSON; ensure ≥1 submit action.

Save ; preview appears on the node; outputs auto-create.

Map outputs into later Condition , Set variable , Action (flow/tool), or Message nodes.

Configure reprompt/interrupt properties for production UX.

Test on every target channel (Teams, web, voice UI constraints if applicable).

Rename the node meaningfully (names can be long) so large topics stay readable.

  • Scenario walkthroughs
  • Scenario A — Device request form

Contoso IT topic collects device type, justification, and cost center on one card. Input.ChoiceSet for device, required Input.Text for justification, regex on cost center. Submit fills topic variables → Condition validates → agent flow creates ticket → Message Adaptive Card shows ticket number (display-only).

Scenario B — Generative answer + confirmation card

Generative answers node stores policy summary in Global.PolicyAnswer with Send a message cleared. Message node Formula card shows the summary text plus Action.Submit choices “That answered me” / “Talk to HR.” Outputs drive escalation branching. Teams testing verifies citation fields if compliance requires source links on the card.

Scenario C — Consecutive cards

Survey topic sends Card 1 then Card 2. Each Action.Submit includes distinct actionSubmitId . Without unique data, a late click on Card 1 can confuse state—exam-ready designers plan identifiers and client disablement.

Scenario D — Channel downgrade

Marketing wants schema 1.6 features. Contact center uses Omnichannel 1.5. Maker authors 1.5-safe cards, keeps decorative 1.6-only features out of production payload, and documents the host matrix.

Design quality checklist

Prefer 1.5 (or host-documented max) for multi-channel agents.

Every interactive card has a clear Submit (or equivalent) action.

Input id s are stable; schema edited if auto variables mis-type.

Required fields and regex match business rules—not only “nice to have.”

Formula mode used for personalization; secrets never embedded in card JSON.

Reprompt counts and interruption policy match escalation design.

Stale multi-card submits handled via unique data payloads.

Plain-text fallback exists when a channel strips cards.

Accessibility: labels on inputs, short titles, wrap text for mobile.

After flow/tool success, confirmation card or message uses the same variable vocabulary.

Exam traps

Putting a non-interactive summary on Ask with Adaptive Card without submit (use Message instead).

Assuming Studio test success equals Teams success.

Forgetting that free text during card wait is invalid unless interruption fires.

Hard-coding user-specific values instead of Power Fx bindings.

Using cards for one binary question when a Question node is simpler—and vice versa for five-field forms.

Adaptive Cards turn Copilot Studio topics into structured micro-apps inside chat. On AB-620, show you can choose interactive vs display cards, respect channel schema, bind variables with Power Fx, and wire submit outputs into the rest of the agent.