How to trigger a Power Automate flow in one Microsoft 365 tenant when files are created or modified in a SharePoint site in another tenant?

Hi @Ali, Mohammad Irshad

Thank you for providing such a detailed description.

Based on the behaviour you described, I would separate guest access to Power Automate from the identity used by the SharePoint connector. Microsoft documents that B2B guest users can create and run flows in the guest tenant when the applicable invitation, sign-in, consent, and licensing requirements are met. However, having Full Control as a guest on the SharePoint site does not necessarily mean that a SharePoint connection created in the guest user’s home tenant can enumerate and subscribe to resources in the external tenant.

Power Platform tenant isolation is another control layer. If tenant isolation is enabled, cross-tenant connector connections are blocked unless the relevant inbound or outbound tenant is placed on the allow list. Therefore, an isolation exception may be required if this control is enabled, but it would not by itself correct an unsupported identity or connector authentication scenario. For this requirement, I would consider one of the following architectures:

Create a lightweight trigger flow in Tenant A. Create the SharePoint connection and the file-created-or-modified trigger in the tenant that owns the site, using an internal account or another appropriately managed identity from Tenant A. That flow can then invoke the existing process in Tenant B through an approved HTTP or Azure integration endpoint.

Use the existing Azure Function as the cross-tenant integration layer. Since your function can already access Tenant A through Microsoft Graph application authentication, it can receive or detect the SharePoint change and then invoke an HTTP-triggered flow in Tenant B. This also keeps the application credentials out of the standard SharePoint connector.

The standard SharePoint connector does not expose Client ID, Tenant ID, and client-secret or certificate fields as an authentication option. Therefore, the existing App Registration cannot simply be substituted for the user connection used by the native SharePoint trigger.

A dedicated Tenant A service account may work if the connection is created under the correct tenant context and the relevant Power Platform policies permit it. However, I would first validate the design with both tenants’ Power Platform and Entra administrators, including:

• The environment and directory in which the connection is being created
• Power Platform tenant-isolation rules in both directions
• Conditional Access and cross-tenant access policies
• Licensing and governance requirements for the connection owner
• Whether the organisation permits a service account for unattended flows

Therefore, my preferred supported design would be to keep the SharePoint trigger or Microsoft Graph change-detection component in Tenant A, where the data resides, and use a secured integration endpoint to start the existing flow in Tenant B. I would not rely on the B2B guest’s Full Control permission alone to make the native SharePoint trigger operate across tenants.

As I am only another community user and cannot inspect either tenant, I would also recommend opening a Microsoft support request in Admin Center to obtain written confirmation for this particular cross-tenant connector and licensing configuration.