Global Shipping Co. is designing a Copilot Studio agent for their IT help desk. The agent must read open incidents from ServiceNow and create new incidents when a user reports an issue. The team wants to use the most purpose-built, officially supported connector available within the Power Platform ecosystem rather than building a custom HTTP integration. The ServiceNow instance is cloud-hosted. Which connector approach should they choose?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The ServiceNow certified connector is the Power Platform's ready-made handshake with ServiceNow — actions like 'Get Record' and 'Create Record' are already wired up, authenticated, and tested. Option B is correct; using the certified connector inside a Power Automate flow is the officially supported, lowest-effort path for reading and creating ServiceNow incidents.
Full explanation below image
Full Explanation
Microsoft Power Automate ships a certified ServiceNow connector that provides pre-built actions (Get Record, Get Records, Create Record, Update Record) and triggers (When a record is created/updated). These actions handle OAuth authentication to ServiceNow out of the box and are maintained by Microsoft. In a Copilot Studio solution, the agent calls a Power Automate cloud flow as an action; that flow uses the ServiceNow connector to interact with the ITSM system.
Option B is correct because it directly matches the requirement for the 'most purpose-built, officially supported connector' — that description exactly characterizes certified connectors.
Option A is wrong. Building a custom connector from an OpenAPI definition is valid but it is more work than necessary when a certified connector already exists. Custom connectors are appropriate when no certified connector exists. The question specifically asks for the most purpose-built option.
Option C is wrong. Using raw HTTP action nodes with hard-coded basic authentication is a security risk (credentials exposed in topic configuration), fragile (any ServiceNow API change breaks it), and bypasses the managed authentication that Power Automate connectors provide. Basic auth may also be disabled by ServiceNow admins.
Option D is wrong. Dataverse virtual tables allow Dataverse to surface external data as if it were local, but this requires a virtual table provider plugin that must be developed and registered in Dataverse. It is complex to set up for ServiceNow, and is not 'purpose-built' for this use case. Virtual tables are better suited for tight Dataverse-centric scenarios, not general ITSM integration.
Exam tip: On the AB-620 exam, when you see a major SaaS platform (ServiceNow, Salesforce, SAP, Jira, etc.) mentioned alongside 'best connector' or 'officially supported,' check whether a certified Power Platform connector exists for it. If one exists and the system is cloud-hosted, that connector through Power Automate is almost always the right answer.