On-Premises Machines, Rotating Credentials, and a DLP Wall

The cloud flow's desktop flow action needs a registered machine or machine group, and those machines register through an on-premises data gateway. Without a gateway the machines are invisible to the service, which is the usual cause of 'no machine available' at start time. Inbound firewall ports are not required - the gateway makes outbound connections only - so IT's constraint is compatible with the design.

Minimum viable design:

• Install a standard on-premises data gateway on a hardened host in the same subnet as the file share and SQL Server, with outbound 443 allowed. Add a second gateway member to form a gateway cluster, because a single gateway is a single point of failure for all three flows.
• Register the runtime machines and place them in a machine group; each machine runs one unattended run at a time, so five concurrent runs needs at least five machines in the group (plus headroom if you want one to be lost to maintenance). Pooling them means the cloud flow does not name a specific machine.
• Do not plan on hosted machines here: hosted compute in Microsoft's network cannot reach the datacenter subnet without network exposure, so the on-prem machines are the correct choice despite the maintenance overhead.

Split the two credential problems, because they have different mechanisms.

Machine sign-in (unattended session): the Windows account used to sign in to each runtime machine is configured in the machine registration settings and stored securely by the platform, not in the flow. Rotation means updating that credential in the machine configuration every 60 days - script it through the Power Platform admin APIs so it is a scheduled job, and rotate the gateway and machine credentials in the same maintenance window. Never place the machine account password into a flow action.

Application secrets (vendor API keys, SQL logins): store them in the corporate vault and retrieve at run time. A cloud flow calls the Key Vault Get secret action and passes the value to the desktop flow as an input variable, which the desktop flow holds only as a Sensitive text variable so it is masked in logs.

Watch the DLP interaction: if the vault's connector is Blocked by the same policy, the cloud flow cannot fetch the secret. Escalate for a scoped exception for the vault connector in the RPA environment (business classification, with an audit trail) rather than embedding secrets - embedding them would break the mandate and put the password in solution history.

Options, in order of preference:

1. Remove the need for the blocked connectors. Most RPA patterns reach an internal system through the gateway and Dataverse, not through HTTP. If the only use of HTTP was a convenience call, replace it with a Dataverse table write plus a scheduled flow, and the policy stops being a blocker.
2. Scope the policy to environments. A tenant-wide 'all environments' policy that prohibits the connectors an RPA environment needs forces the RPA work into a shadow environment, which is worse for governance. Recommend the admin move to a baseline tenant policy plus an environment-specific policy for the RPA environment where the vault connector and the specific approved connector are Business-classified. This keeps the strict policy on collaboration environments where it matters.
3. Get a governed custom connector approved. If an API is genuinely required, publish a custom connector owned by the platform team with the API key held in the vault, and have it classified as Business so it can be used with Dataverse and SharePoint. This is a review process, not a workaround.

Do not attempt to bypass the policy by having the desktop flow make raw network calls. That defeats the control the bank is relying on, is unsupportable, and is the kind of decision an exam question is testing you not to make.