A developer is building an Azure Function that will back a custom connector so makers can call a pricing calculation from flows and apps. The connector should be created from a definition rather than built by hand. How should the developer build the function and describe it for the connector?
Select an answer to reveal the explanation.
Short Explanation
A custom connector is a wrapper around a REST API, so your function has to speak HTTP. HTTP triggers plus an OpenAPI 2.0 description give the connector everything it needs to import. Queue or timer triggers make a fine backend for other jobs, just not for a connector.
Full Explanation
A custom connector wraps a REST API described by an OpenAPI definition. HTTP-triggered Azure Functions expose request and response endpoints the connector can call, and describing those endpoints in an OpenAPI 2.0 document, generated by tooling or written by hand, lets the developer import the definition and get actions, parameters and responses without manual entry. Service Bus-triggered functions run when a message arrives on a queue; a connector calls HTTP endpoints and cannot post Service Bus messages by pointing at a queue URL, and the caller would never receive a synchronous price. Timer-triggered functions polling Dataverse turn a request and response call into a delayed batch process and require makers to write and read table rows rather than call an action. Durable orchestrations expose status endpoints for long-running work, but a status page is not an API definition, and importing it as a host is meaningless. Exam caveat: Microsoft lists Azure Functions, Web Apps and API Apps as good hosts for APIs behind custom connectors, and API Management can also export functions it fronts. Operational check: test the function's HTTP endpoint directly, import its OpenAPI definition into a new connector, and run the pricing action from the Test tab.