A workflow is the process; RPA is one way to perform a step
Workflow automation coordinates work: receive a request, check information, update a record and assign the next action. An API is a supported way for software systems to exchange requests and data directly. Robotic process automation, or RPA, can interact with an application through its screens, entering fields and selecting controls much as an employee would.
These are overlapping choices. Microsoft describes cloud flows that connect applications and services, and desktop flows that automate web or desktop tasks. A larger process can use both. RPA does not have to replace your CRM, and a workflow does not become complete simply because a robot can fill out one form.
Start by checking for a supported connector, API or approved import for the required operation. Consider screen interaction when the necessary action is available only through an authorized application interface. Keep an employee step when access, confirmation or reliability cannot be established. This article uses an illustrative order and official Microsoft documentation checked on October 18, 2026; no customer system or live RPA deployment was tested.
Compare both methods on the same service order
Sample Services has an accepted order, S-426, in its CRM. An employee has checked the service address and selected service. The next task is to prepare an order draft in a legacy supplier portal, then return its reference to the CRM. Final submission and any customer commitment remain with the account manager, Avery.
The CRM in this scenario has a supported connection for reading the order and writing a task. The portal is assumed to have no supported API for draft creation. Those are fictional design conditions to verify in discovery, not claims about a named supplier. Use the same order, fields, approval and expected reference when comparing the two implementation routes.
- Direct connection route, if supported: send the approved fields, including the source order reference, through the portal API or connector. Capture its draft reference and confirm that the correct CRM order contains it.
- Screen route: open the authorized portal session, locate the correct account, enter the approved fields and source order reference, save one draft and read its reference before updating the CRM.
- Either route: keep final submission held, show Avery the current draft and source order, and record the decision separately. A saved draft is not a submitted or activated service.
Specify the screen checks before recording the clicks
Microsoft documents UI elements and selectors for locating controls in desktop and browser automation. A selector identifies an element through its properties and position in the application structure; RPA need not rely only on fixed mouse coordinates. The documentation also distinguishes web elements from desktop elements, which need the appropriate action type.
For S-426, ask the implementer to identify the account heading, service-address field, service option, Save draft control and resulting reference. The design should check that it is on the intended account and page before entering information. Finding a button with a familiar label is insufficient when several orders or windows are open.
Microsoft lists application updates, screen resolution, scaling, window mode and user permissions among factors that can affect selectors. Include a demonstration in the intended runtime environment. If the portal renames a field or changes its layout, the proposed behavior should be to stop with an actionable task, rather than guess which control now means the same thing.
Choose attended or unattended operation explicitly
Attended operation runs alongside a signed-in employee. Microsoft states that attended desktop flows require an unlocked session with the user matching the desktop-flow connection. This can suit a limited helper that prepares fields while the employee remains responsible for the next decision. It does not establish that the process will run overnight when that employee signs out.
For unattended Power Automate desktop flows, Microsoft documents a managed remote Windows session and the required Process plan. Its Windows 10 and 11 guidance says active user sessions, including locked sessions, prevent unattended execution. It also states that unattended flows cannot run with elevated privileges. Check the exact operating system, session configuration and current licensing before proposing unattended delivery.
For the sample portal, first establish whether the application permits the intended automation and whether its authentication can be supported within company policy. Do not remove MFA, bypass a challenge or share an employee password to make the recording work. If a required sign-in or approval needs a person, make that boundary part of the operating plan.
Give the employee a useful exception record
Suppose the screen workflow presses Save draft, but the portal stops responding before a reference appears. The save may have happened. The same uncertainty can occur after a direct API request. Neither a timeout nor an unresponsive screen justifies immediately creating another draft.
Ask for the following employee view. It is a proposed business output, not a built-in Power Automate screen. The implementer must demonstrate how the selected CRM or task tool stores it and who can act on it.
- Order: S-426; link to the CRM order and approved field values. Owner: Avery.
- Completed work: source order read and approved values prepared. Portal draft save attempted once; no confirmed reference captured.
- Current state: portal confirmation unresolved. Do not mark the order submitted, activate service or send a completion notice.
- Employee action: inspect the authorized portal for the S-426 reference and matching fields. If a draft exists, record its reference; if the result cannot be established, escalate before another create action.
- Decision record: retain who checked, what was found and whether another attempt is authorized. Keep evidence access-controlled and exclude credentials or unnecessary customer information.
Test the operating boundary, not just a successful recording
A useful demonstration includes a normal order and the situations that would otherwise leave an employee guessing. Use fictional records and an approved test environment. The following are proposed acceptance checks, not results from testing either method.
- Normal draft: the intended supplier account receives the approved fields, one draft reference returns, and the CRM shows that final submission is still held.
- Changed screen: a renamed or unavailable field stops screen entry and identifies the affected order and control. No substitute field is silently chosen.
- Wrong account: a mismatched account heading prevents entry. The employee gets the source order and the mismatch to investigate.
- Unavailable session: the unattended machine cannot start, or the attended session is locked. The order remains visibly pending and an agreed owner receives the task.
- Uncertain save: interrupt the confirmation step after one save attempt. Demonstrate reconciliation before any repeated creation.
- Employee decision: Avery can compare the draft with the approved order, reject a discrepancy and authorize final submission only through the agreed review step.
Include the machine, access and application changes in maintenance
For screen automation, the managed scope needs to name the machine or hosted environment, operating account, application version, browser configuration and person responsible for changes. A portal redesign, expired connection or unavailable session can affect work even when the original recording has not changed. Direct connections have their own API, permission and field-change maintenance.
Microsoft recommends examining execution logs and, where available, screenshots when diagnosing unattended failures. Its security guide describes credential retrieval and sensitive variables that are masked during debugging and omitted from run logs. Configure and verify the applicable protections; a log setting does not by itself establish that every screenshot or copied value is safe to retain.
Agree on access to evidence, retention, escalation and a manual route for pending orders. Request a change test when the supplier updates the portal. Include platform licensing, runtime infrastructure and operator work in the scope, without assuming that a recorded click sequence is free to operate or cheaper than a supported direct connection.
Choose the smallest dependable bridge into the legacy system
Prefer a supported direct operation when it fits the required action and access policy. Use RPA for a bounded screen-only step when the account checks, runtime, confirmation and recovery path have been demonstrated. Combine them when the CRM connection works but one legacy portal action still requires a screen.
For S-426, success means an accurate supplier draft with a confirmed reference and a reviewable employee task. It does not mean autonomous activation, a guarantee of availability or an invented time saving. Measure completed drafts, pending exceptions and employee correction work during a limited rollout before claiming improvement.
Bring the implementer one real process, the system names and the exact action that cannot currently be connected. Ask to see the normal draft, a changed screen and an uncertain save. That gives the business a concrete decision about a legacy-system bridge, rather than a choice between two automation labels.
