Design RPA solutions
Classify the process before choosing tools
Decide first whether the work should be automated through an API at all. Cloud flows use connectors and are right for event-driven, service-to-service work: a new item in SharePoint, a Dataverse row change, an approval. Desktop flows use UI automation and belong where a screen is the only interface. Most real designs are hybrid: a cloud flow owns the trigger, orchestration, approvals and logging, then calls one or more desktop flows with the Run a desktop flow action, passing input variables and reading output variables back.
Decide attended vs unattended
Attended desktop flows run inside a signed-in user's session and suit human-in-the-loop handoffs. Unattended flows run on a machine or machine group with RPA capacity, usually from a scheduled cloud flow, and do not need a person present. A scenario describing overnight or out-of-hours processing is pointing at unattended; one where a clerk reviews an exception mid-process is attended.
Design for change and failure
Split the process into subflows with explicit input and output variables so each piece can be tested and reused. Retrieve credentials at run time from Azure Key Vault rather than hardcoding them. Decide up front what happens on a business exception (log the item and continue) versus an application exception (stop and alert). Make each run idempotent so a retry does not create duplicate records. Design solution-aware from day one and plan Dev/Test/Prod with environment variables and connection references.
Worked example
Invoices arrive by email and must be downloaded from a supplier portal that has no API. Design: a cloud flow triggers on the new email, adds an item to a work queue, runs a desktop flow unattended on a machine group to download and rename the file, then writes results back to SharePoint and posts a Teams summary.
Rule of thumb: automate through an API wherever one exists; reach for UI automation only where a screen is the only door.