Start by checking whether your applications offer a supported API or connector that can perform the exact work you need. If it covers the required steps and your business can use it, assess that route first. Browser automation is worth considering when people can complete the task through a website but a suitable system connection isn't available. Some workflows need both.
The buying decision should turn on what happens to a real business record: how the automation finds it, checks it, and confirms the result. A connection that moves information still needs rules for incomplete requests and failed updates.
Start with the task somebody repeats
Write down one complete example before comparing tools. Which application holds the original information? What does the employee enter elsewhere, and how do they know it saved correctly?
Be specific about the action. Reading an existing customer record, creating a service request, and attaching a document are separate requirements. A vendor saying it has an API doesn't establish that the API covers all of them.
An API is a way for software to request data or actions from another system. A connector can package those calls for an automation tool; Microsoft's documentation describes how its custom connectors communicate with APIs.
For the buyer, the next step is to ask for evidence that the available connection supports each required action, with the permissions the business will actually approve. Confirm any subscription requirements and access costs with the application provider before accepting an implementation quote.
Use this table to narrow the choice
These are assessment recommendations. Apply them to the particular applications and task before choosing an approach.
| What you find | Route to assess first | What needs proving |
|---|---|---|
| A supported connector or API covers the required reads and updates | API integration | The approved account can perform the actions, validate the results, and handle the expected workload |
| The application supports a documented file import that meets the timing need | File import or scheduled transfer | Field mapping, rejected rows, duplicate handling, and confirmation of accepted records |
| The required action is available through the website, with no suitable supported integration | Browser automation | Permitted access, reliable identification of fields and buttons, and a clear way to confirm completion |
| One application supports an API while the other requires its website | A workflow combining both | A record linking the work in each system and a recovery plan for a partially completed transfer |
| Nobody can explain the exception rules or determine whether an update succeeded | Clarify the process before automating it | A responsible person, a usable decision rule, and evidence of the final result |
A scheduled file import may solve a task that doesn't need immediate updates. Include it in the assessment so the project doesn't become more complicated than the work requires.
An API still needs an operating plan
Avoid treating API access as a promise of unlimited throughput. For example, Microsoft Graph can reject requests when an application exceeds its limits. Its throttling guidance tells developers to respect the supplied retry delay, with a backoff policy when that delay isn't available.
Ask how the proposed workflow handles a backlog. Which records remain waiting, when will it try again, and who gets notified if the work won't finish in time? Set those expectations against the business deadline.
Also ask what happens when a request times out after the receiving system may have saved it. Sending the same request again can be the wrong response. Some APIs provide a way to recognize a repeated request: Stripe, for example, documents idempotency keys for safe retries. That protection has conditions and doesn't establish what another application's API supports.
Have the implementer demonstrate the duplicate-prevention method for your system. If the outcome remains uncertain, the workflow needs a way to stop that record for investigation.
Browser automation needs more than a recording
Browser automation can identify webpage controls and enter information into them. It doesn't have to rely on clicking a fixed spot on the screen. Microsoft's UI-element documentation explains how selectors identify the controls an automation uses.
Those identifiers still need care. Microsoft documents a failure where a page's changing HTML makes an earlier selector unusable, along with ways to repair the selector.
For a buyer, that translates into a maintenance question: who checks the workflow after the application changes? Include that responsibility in the support discussion, alongside the account and browser environment the automation needs.
Confirm that the application owner permits the proposed access. If login requires a person to approve a prompt, decide whether the workflow will run with that person present or whether an approved unattended method exists. Don't build the business case around silently bypassing a login requirement.
A mixed workflow can be the sensible choice
Consider a hypothetical service business. Staff copy approved requests from a customer-management system into an older scheduling website. Assume the first system offers a supported API for reading those requests, while the scheduling system offers only a permitted web form for creating jobs.
One possible design retrieves the approved requests through the API, checks the required information, and uses browser automation to create each scheduling job. It records the resulting job reference against the original request. A request missing a service address goes to a person before the workflow creates anything.
The difficult moment is an interrupted save. If the scheduling site stops responding after submission, the workflow needs to establish whether the job already exists before submitting it again. Without a reliable lookup or other confirmation, that request should wait for review.
This example proposes a design to investigate. It isn't a client case study or a claim about any particular software product.
Ask for these checks before accepting the work
Use representative, approved test records and agree on the expected result for each check:
- A normal request: the correct destination record exists, its fields match the source, and the business can find the result.
- Missing required information: the workflow explains what needs correction and sends the request to the agreed person without creating an incomplete destination record.
- A repeated request or an interrupted save: the recovery process detects completed work or stops for review before risking a duplicate.
- Unavailable access: a failed connection or login produces an actionable notice and leaves enough information to resume safely.
Compare the ongoing work as well as the build price. Ask for the applicable software and access costs, monitoring arrangements, maintenance responsibilities, and the manual work that will remain. If a task is infrequent and quick, the implementation and support cost may outweigh the time it saves. Resolve that before buying.
AB Consulting assesses, builds, and repairs workflows around existing business applications. Bring a redacted example of the information being copied, the applications involved, and the point where employees have to intervene. Ask AB to review the workflow and work out which connection makes sense for the job.