Code or connector? Decide wisely: Use a prebuilt connector only if its documented actions match your business needs exactly.; Check for missing fields, error handling and API limits before committing to a route.; A mixed design works when connectors handle routine steps and code manages specialised logic.
Image: Workflow Automation Guide

Integration Platforms

Part of Designing reliable workflows between business applications

Deciding whether a workflow needs code or a connector

Decide between a prebuilt connector, custom connector, code or a mixed workflow by checking the exact operation, limits and recovery needs.

Use a connector when its documented trigger and action meet the required business operation, access needs, volume and recovery requirements. Use code for behaviour the available connector routes cannot provide safely. Decide against one defined workflow.

For a hypothetical paid-order workflow, the requirement might be to create one dispatch request, retain its ID and recover after a timed-out submission. Inspect the connector’s exact create action and the destination API. A connector may expose the operation yet omit a required field or response value.

Compare the available routes

RouteFits whenCheck before committing
Prebuilt connectorIts documented trigger, action, fields and authentication match the task.Exact operation, missing fields, limits, licensing and error detail.
Custom connectorA suitable API exists but no adequate prebuilt operation is available.API ownership, authentication, maintenance and platform entitlement.
Code calling the APIRequired logic or API behaviour needs more control.Hosting, deployment, tests, monitoring, secrets and support ownership.
Connector plus codeOrdinary steps fit the connector, while one operation needs custom behaviour.The boundary and how results, IDs and failures cross it.

Microsoft offers prebuilt and custom connectors. Custom connectors expose selected API operations. A cloud flow can be combined with code for a specialised calculation.

Choosing the right integration route: prebuilt connector vs custom connector vs code

  • Prebuilt connectorUse when documented trigger, action, fields and authentication match the task exactly. Check for missing fields, limits, licensing and error detail.
  • Custom connectorUse when a suitable API exists but no adequate prebuilt operation is available. Requires ownership of API, authentication setup and ongoing maintenance.
  • Code calling the APIUse when more control over logic or API behaviour is needed. Requires hosting, deployment, testing, monitoring, secrets management and support ownership.
  • Connector plus codeUse when most steps fit a connector but one operation needs custom behaviour. Define input, output and error contract for reliable reconciliation.

Check the exact connector capability

List the source event, destination operation, required fields, returned fields, permission scope, expected volume and recovery method. Read the selected connector reference and destination API contract.

Check what the route exposes when the destination rejects a value, throttles a request or fails to return a response after a write. Run history alone cannot resolve an uncertain external outcome; the destination may need to be queried.

Check licensing and limits for the actual deployment. Power Automate distinguishes entitlements for standard, premium and custom connectors. Its platform request limits are separate from connector throttling limits, and the connected service can impose its own limits. The relevant allowance depends on the plan, connector and account.

Include operating work in the choice

Code needs an owner for deployment, dependencies, credentials, logs and failures. A custom connector also needs maintenance when the underlying API changes. A prebuilt connector still requires decisions about business identity, destination confirmation and exceptions.

A mixed design can work when the workflow tool handles the trigger and ordinary actions but one component performs a specialised calculation or API operation. Define that component’s input, output and error contract so an uncertain result can be reconciled.

Decide against a representative case

Choose one representative event and expected destination record. For each feasible route, plan checks for a normal submission, missing data, a repeated event and a response lost after a write. Compare how each route exposes the destination ID or resolves an uncertain outcome, who will maintain it and which documented limits apply.

Select the simplest route that meets the business contract and that the operating team can recover. If a connector falls short, identify the exact gap before adding code.

Steps to decide between code and connector in Australian workflows

  1. Choose a representative eventExample: a paid order in a local e-commerce system using Australia Post shipping APIs.
  2. Plan for normal submissionVerify connector creates dispatch request and returns ID correctly.
  3. Test missing data scenarioCheck if connector handles missing order items gracefully with retry or alert.
  4. Simulate repeated eventEnsure idempotency — avoid duplicate dispatches via unique IDs or deduplication logic.
  5. Handle lost response after writeImplement query-back mechanism if the destination doesn’t return confirmation.
  6. Select simplest viable routeChoose the option that meets business contract and can be maintained by local IT team.

More from Integration Platforms