Justine is developing a Copilot Studio agent for Metro City Council. The agent has a registered plugin action named 'GetPermitStatus' that accepts a 'PermitNumber' input (Text) and returns a 'Status' output (Text) and 'ExpiryDate' output (Text). Justine needs to build a topic that lets residents query their building permit status and display both the status and expiry date in a single formatted message. Which topic design correctly invokes the plugin and displays the response?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The recipe is simple and always the same: 'Call an action' node → bind input → read outputs in message node. Justine drops the 'Call an action' node, selects GetPermitStatus, maps PermitNumber, and in the message node she writes 'Status: {GetPermitStatus.Status} | Expires: {GetPermitStatus.ExpiryDate}'. Done. Answer: B.
Full explanation below image
Full Explanation
Invoking a plugin action in a Copilot Studio topic follows a fixed, tool-supported pattern using the 'Call an action' node and downstream variable references. This pattern is consistent across all action types — plugin actions, cloud flows, and Power Platform connector actions.
Option B is correct and describes the exact workflow. After a question node captures the permit number into a topic variable (e.g., Topic.PermitNumber), the developer adds a 'Call an action' node and selects the 'GetPermitStatus' plugin from the action picker. The input parameter 'PermitNumber' is mapped to 'Topic.PermitNumber'. After the node executes, Copilot Studio creates two output variables: 'GetPermitStatus.Status' and 'GetPermitStatus.ExpiryDate'. A 'Send a message' node following the action node can directly embed these variables: 'Your permit status is {GetPermitStatus.Status}. It expires on {GetPermitStatus.ExpiryDate}.'
Option A is incorrect because the 'Send HTTP Request' node is a low-level tool for calling arbitrary HTTP endpoints — it bypasses the plugin action framework entirely. The plugin is already registered as a first-class action; there is no need to reconstruct an HTTP call. Additionally, plugins do not expose an 'internal API URL' that developers can call directly.
Option C is incorrect because hardcoding expected status values in condition branches is not a scalable or correct approach. With hundreds or thousands of possible permit numbers and dynamic statuses, condition-based branching cannot substitute for a real data lookup.
Option D is incorrect because redirecting to a second topic adds unnecessary indirection. A single topic can call the plugin and display results in the same conversation flow. Topic redirection is for reusable subtopics (like authentication or escalation), not for a linear lookup-and-display flow that fits in one topic.
Exam tip: Justine's scenario is a clean example of the standard plugin invocation pattern. Input → action → output → message. There is no need for HTTP nodes, condition branches, or topic redirects when a plugin action is already registered and available in the action picker.