RPA: we automate the screen when no other entry point exists
A desktop robot opens, queries, enters data, and confirms in your system as a person would. When that system has an API or connector, we tell you and use it: it lasts longer and fails less often.
The robot complements integration by covering systems where integration is unavailable. These are the signs that your case falls into that category.
The system has no API or connector. Windows desktop applications, legacy systems, and modules the vendor never opened: the screen is the only available entry point.
Integration exists but is unavailable to you. The interface module is priced separately, is not included in your version, or depends on a vendor project without a completion date.
The process runs in a third-party portal. Online banking, customs, supplier or customer portals that only provide a screen and user login.
A bridge until formal integration is available. The robot supports operations now and is retired when the connector becomes available, with that transition defined in the design.
High-volume work requiring little judgment. Repeated data entry, reconciliation between two screens, downloading and classifying reports: tasks where human error is a matter of time.
When to choose another approach
When an API or connector is the right choice
Identifying this before billing is part of our work. Microsoft's own guidance recommends an API-based connector whenever available: APIs remain stable when applications change, while robots depend on the interface staying consistent.
The system already has a documented connector or API. We integrate through it. A robot over an available API adds unnecessary maintenance cost. This work is explained in systems integration.
The data resides in an accessible database. We read the database with read-only permissions; there is no reason to navigate the screen displaying it.
The process involves decisions rather than data entry. If the human work involves approving, prioritizing, or negotiating, you need an approval workflow with traceability, not a robot.
The system will be replaced in a few months. Automating the interface of an application scheduled for retirement creates costs lost during migration.
The volume requires responses in seconds. Thousands of daily transactions with short response times call for direct integration: robots work at graphical interface speed.
Criterion
Connector or API
Desktop RPA
Resilience to change
High. Vendors avoid breaking API contracts between versions.
Moderate. A screen redesign or field change requires a robot adjustment.
Getting started
Depends on availability, documentation, and access credentials.
No third-party wait: if you can access the screen, the robot can too.
Maintenance
Low and predictable.
Recurring and planned. Budgeted from the start.
Volume and speed
High. Operates at service speed.
Limited. Operates at interface speed, one case at a time.
Infrastructure
No additional infrastructure in most cases.
Requires a machine or environment for the robot and someone to monitor it.
Audit trail
A record of every call and its response.
Logs for every run, with screenshots of the failure point when it stops.
The principle in one sentence. If an API exists, use it. If it doesn't, a robot makes the difference between automating the process and entering data manually for another year.
What we deliver
A robot that stops safely, as well as runs
Recording clicks is the easy part. Exception handling, logs, and a documented handoff are what keep operations running.
Discovery on the actual interface
We walk through the process with the person performing it today, including unusual cases that have never been documented.
Development with stable selectors
The robot identifies fields by their attributes rather than their screen positions.
An owner for every exception
Anything the robot cannot recognize is stopped, reported, and queued for a person.
Logs for every run
What it processed, what it skipped, and where it failed, with evidence captured at the point of failure.
Delivery and handoff
Documentation, department training, and the robot under your organization's control.
The robot handles the volume; a person still handles exceptions.
Who leads the practice. Humberto Henríquez, founder of the company, a Systems Engineer with master's degrees in Data Science and Business Intelligence. Meet the company →
What we need from you
What your organization provides to keep the robot running
These requirements are defined before development: a robot needs a place to run, its own credentials, and a business owner before it can reach production.
IT responsibilities
A machine to run on. A dedicated workstation, virtual machine, or managed infrastructure, selected with your IT department.
Its own service account. Least-privilege access without sharing anyone's personal account, so logs clearly identify the robot's actions.
Advance notice of application updates. The most important point: a version change announced in advance can be handled in hours; discovering it in production can cost a day of operations.
Licensing review. Unattended operation and premium connectors are reviewed with IT during assessment, before making commitments.
Business responsibilities
A business owner. Someone to resolve exceptions escalated by the robot and validate results during the first weeks.
Test data or environment. Real cases for testing without touching production, including cases that tend to fail.
An agreed execution window. When it runs, how long it may take, and what happens if the application fails midway.
Written rules. What the robot does with duplicates, out-of-range amounts, or unreadable documents.
What it integrates with
The robot is one process step
In most cases, RPA handles the segment without an API and connectors handle the rest: this combination is common.
Inputs
EmailWhatsAppFormsSharePointSFTPWeb portals
→
Orchestration and robot
Power AutomateDesktop RPARulesHuman approvalRetriesLogs
→
Destinations
ERPCRMExcelSQLNotificationsReports
When policy requires the engine to reside within your perimeter, the equivalent architecture is covered in self-hosted orchestration; when the process starts with a Teams conversation, in agents with Copilot Studio; and when an agent queries and executes the process, in AI agents.
Objections
What holds back the decision, plainly stated
“RPA breaks when the system changes”
That is true. We use attribute-based selectors, stop when the robot cannot recognize an item, and notify the responsible person rather than writing uncertain data. Maintenance is budgeted from day one.
“It locks us into a vendor”
The robot, documentation, and credentials remain in your tenant under your organization's ownership. We provide an operations manual and training so your team can maintain it independently.
“What if the robot does something wrong?”
It runs with a least-privilege account, within the agreed execution window, and without authority over irreversible steps: payments, cancellations, and customer communications require a person's sign-off. Everything is logged.
“IT doesn't want another machine to manage”
This is an architecture discussion: options include a virtual machine in your cloud or managed infrastructure. We define the approach with IT before development, with licensing implications clearly stated.
“We tried automation, but it was left unfinished”
This often happens when only the successful path was automated and no one defined exceptions. We can take over existing solutions: assessment, exception handling, alerts, and documentation, through managed operations.
“We don't know where to start”
Start with the highest-volume process requiring the least judgment. The guide to the nine most commonly automated processes ranks the candidates, and the ROI calculator estimates the current cost of performing them manually.
Frequently asked questions
Before we start
How do we know whether our case needs RPA or integration?
We first check whether the system offers an API, connector, or accessible database. If so, we integrate through it: integration withstands version changes that break robots. RPA is used when the screen is the only available entry point. This review is part of the assessment and carries no commitment to engage us.
What happens when the application changes and the robot fails?
The robot stops rather than continuing with uncertain data, notifies the responsible person, and logs the case. Adjusting the affected selector is planned maintenance, not a process redesign; with managed operations, we take responsibility for that monitoring.
Do we need a computer running all the time?
The robot needs a machine to run on: a dedicated workstation, your organization's virtual machine, or managed infrastructure. The appropriate option and licensing are defined with IT during the assessment, alongside the rest of your Microsoft 365 automation.
Bring us the process you currently enter manually
In the executive assessment, we review whether your case needs a robot, a connector, or neither, using the same criteria we would apply to our own project.
