Running PowerShell scripts would allow to significantly simplify workflows and would allow for implementing functionality that is cumbersome, incomplete or have not been implemented in Power Automate yet, e.g. provision sites based on PnP XML templates, implement automated tenant management tasks, automatically provision workflows for new sites, automate disposition and archival processes, etc. Cloud Shell (see https://docs.microsoft.com/en-us/azure/cloud-shell/overview) already implements everything that would be required, but Power Automate has no activity or connector to connect to a Cloud Shell instance.
This can be implemented in the following manner:
A tenant admin can create its own Cloud Shell instance which already has PowerShell script execution and file storage capabilities. Cloud Shell Activity would be able to utilize remote script execution within the Cloud Shell instance. Thus, remote script execution needs to be enabled in order to create a Cloud Shell connector.
Cloud Shell activity inputs and outputs should be standardized. Output values, errors ($Error object), user messages (e.g. console/host output) should be a part of the output object (e.g. a JSON object that conforms to Power Automate Activity IO schema). Thus, execution results can be handled, reported on or persisted.
Cloud Shell scripts should run in the context of the user executing the workflow or by passing app credentials (e.g. in the input parameters), which should allow for accessing of M365 and Azure resources like SharePoint Online sites, Groups, Teams, Emails, Azure Key Vault, Azure Functions, etc. if the user or app registration has the authorization to do so.
Power Automate activity requests will count against the daily Power Platform requests for each call to the Cloud Shell. But network traffic, compute, storage and other resources utilized by the Cloud Shell shall not count against Power Automate requests.