RPA, low-code or custom code: choosing for a specific process

You want to move orders from one application to another. Before comparing tools, I would check how each application lets data in and out. A documented API, file exports and a screen are different starting points.

RPA, low-code and custom development are not three separate boxes either. A visual platform can call an API, run code and use a desktop robot within the same process. The decision is about choosing components you can operate and maintain.

Three solutions for the same export

Here is a hypothetical scenario: every week, you need to extract a list of orders and add it to an internal register. This step does not issue invoices or confirm stock.

If the application only provides a screen and an export button, an RPA robot could open it, select the period and download the file. I would not rule it out on principle. Microsoft’s documentation explains that desktop workflows can identify elements using selectors without relying on absolute coordinates. It also covers alternative and text-based selectors. Moving a button does not necessarily cause every robot to fail.

Even so, I would test session changes, unexpected windows and application updates. If it cannot find the correct file, it should stop. For a weekly export that a person reviews before importing, it can be a reasonable option.

If a compatible connector exists, a low-code tool can retrieve orders and write them to the register. It is useful when the team can understand the workflow and adjust simple rules. I would check whether the connector supports every field, how it pages through results and what happens when usage limits are reached. Cost depends on the specific plan; I would not assume it is always billed per user or always grows in the same way.

If an API exists but the process needs rules the connector cannot handle, custom code lets you express them directly. In return, someone must document, test and update it. An API can also change, limit requests or be retired: writing your own code does not eliminate dependencies.

Compare maintenance as well as setup

I would request the same scope for all three options: order volume, fields, frequency, duplicate handling and response to failures. Otherwise, a quote for copying data and another for reconciling it look comparable although they solve different jobs.

Option	What I would verify in the trial	Ongoing work I would budget for
RPA through the screen	Correct export across different sessions	Interface and desktop-environment updates
Low-code connector	Fields, limits and error recovery	Connector, plan and rule changes
Code with an API	Incomplete responses, duplicates and retries	API versions, testing and support

For a critical process, I would require data checks, records, recovery and a named responsible person, whatever the tool. The method’s name does not establish those controls.

I would also ask how to export the workflow or code, where the documentation is kept and what another person needs to maintain it. The ability to change providers is tested through that handover, rather than a promise of independence.

My choice would start with available access and the total cost of maintaining a correct result. For this weekly list, a simple, reviewed solution may suffice. If it later needs to confirm orders without intervention, the risk and scope will need to be reassessed.