PowerPlatform – Nishant Rana's Weblog

Open a Power Automate Flow for Edit Without Fixing Broken Connections First

While reviewing Power Automate flows recently, we ran into an issue where we could not open a flow in edit mode

When opening the flow, Power Automate displayed the “This flow will connect to” screen and requested that we fix one or more connections before proceeding.

In our case, the flow contained an Office 365 Outlook connection reference that required attention. The problem was that we did not have access to create or repair that connection. Because of this, the Continue button remained disabled and we were unable to open the flow designer to understand what the flow actually did.

At first glance, it appeared that fixing the connection was the only option. However, in our scenario, we were simply analyzing existing flows to understand their purpose and determine whether they were still required.Repairing the Outlook connection would have required additional investigation, coordination with the appropriate users, and potentially creating or reassigning connection references. Since our immediate goal was only to review the flow logic, spending time resolving the connection issue first did not make sense.

Fortunately, we found another approach that allowed us to access the flow designer without fixing the connection immediately.

Instead of trying to fix the connection, open the flow’s Details page. From the details page, locate the Connections section and select Edit.

Next, add your user account as a Co-owner of the flow.

Once we added our user account as a co-owner, we refreshed the page and tried opening the flow again.This time, we were able to open the flow designer and review the flow logic even though the Outlook connection issue was not resolved.

Seems that adding our account as a co-owner provides the permissions required to access and inspect the flow. This simple workaround can save considerable time when reviewing large numbers of flows across an environment.

Hope it helps..

Advertisements

Using the Restore Message to Recover Deleted Records in Dataverse

Accidental data deletion in Dataverse happens more often than we expect. A bulk delete job, an incorrect Power Automate flow, or incorrect manual delete can remove important records in seconds. Instead of restoring the environment, Dataverse provides a much better alternative: the Restore message, which allows us to recover deleted records programmatically.

Prerequisite: Recycle Bin Must Be Enabled

The Restore message works only if the Recycle Bin is enabled for the table before the record is deleted. If the recycle bin is disabled, deleted records are permanently removed and cannot be recovered using the SDK.

When a record is deleted, Dataverse moves it to the recycle bin. We can query these deleted records using RetrieveMultiple with DataSource = “bin” and then pass the deleted record’s ID to the Restore message. The restore operation recreates the record using the same record ID.

Sample Console App –

The following console app retrieves deleted Case (incident) records from the recycle bin and restores them using the Restore message.

static void Main(string[] args)
{
    Console.WriteLine("Restore Deleted Records started.");

    string connString = @"AuthType=OAuth;
Username=your.user@tenant.onmicrosoft.com;
Password=********;
Url=https://yourorg.crm.dynamics.com/;
AppId=00000000-0000-0000-0000-000000000000;
RedirectUri=app://58145b91-0c36-4500-8554-080854f2ac97/";

    var serviceClient = new CrmServiceClient(connString);
    var service = serviceClient.OrganizationWebProxyClient
        ?? throw new Exception("Organization service not available");

    // Retrieve deleted records from recycle bin
    QueryExpression query = new QueryExpression("incident")
    {
        ColumnSet = new ColumnSet("title"),
        DataSource = "bin",
        TopCount = 50
    };

    var deletedCases = service.RetrieveMultiple(query);

    if (deletedCases.Entities.Count == 0)
    {
        Console.WriteLine("No deleted records found.");
        return;
    }

    foreach (var deletedCase in deletedCases.Entities)
    {
        Guid caseId = deletedCase.Id;
        string title = deletedCase.GetAttributeValue<string>("title") ?? "Case";

        // Prepare entity for restore
        Entity caseToRestore = new Entity("incident", caseId);
        caseToRestore["title"] = title + " (Restored)";

        // Restore using Restore message
        OrganizationRequest restoreRequest = new OrganizationRequest("Restore");
        restoreRequest["Target"] = caseToRestore;

        service.Execute(restoreRequest);

        Console.WriteLine($"Restored record: {caseId}");
    }

    Console.WriteLine("Deleted records restored successfully.");
}

E.g., we have the following deleted case, and its related records in our recycle bin.

On running our console app, we can see our deleted case records restored.

Get all the details here.

Hope it helps..

Advertisements

How to Identify and Update Power Automate HTTP Request Trigger Flows Before November 2025

Few weeks back, while working on one of our Power Automate flows, we noticed a banner warning on the HTTP Request trigger step. Microsoft has announced that starting August 2025, all flows using HTTP or Teams Webhook triggers with logic.azure.com URLs will move to a new endpoint under environment.api.powerplatform.com. The old URLs will stop working after November 30, 2025.

The screenshot below shows the banner that appears when the flow is opened in the designer.

A screenshot of a computer

AI-generated content may be incorrect.

When we saw this, we wanted to make sure no other flow across environments was using the old logic.azure.com–based URLs. Instead of checking each flow manually, we used SQL4CDS to quickly identify all such flows.

We ran the following query in SQL4CDS:

SELECT wf.name, wf.workflowid, wf.owneridname, wf.modifiedon
FROM workflow wf
WHERE wf.category = 5
AND LOWER(wf.clientdata) LIKE '%"type":"request","kind":"http"%'

This query returns all flows that have an HTTP Request trigger. It checks the clientdata column in the workflow table where the flow definition is stored as JSON and looks for the trigger type “Request” and kind “Http”.

This helped us identify every flow that exposes an HTTP endpoint — typically used for integrations, webhooks, or form submissions from external systems. Once we had this list, we opened each flow and copied the new trigger URL from the message banner.

The same can be achieved using PowerShell with the command: This lists all flows in a given environment that are part of Microsoft’s trigger URL migration.

Get-AdminFlowWithMigratingTriggerUrl -EnvironmentName

After copying the new URL, we updated our calling applications (for example, the website forms and marketing integrations) to replace the old endpoint with the new one. The new URLs are hosted under the Power Platform domain environment.api.powerplatform.com, replacing the older logic.azure.com endpoints.

To confirm that the requests were now reaching the new infrastructure, we captured the request headers after updating the URL.

This header (x-ms-igw-external-uri) is the easiest and most reliable way to confirm that your flow is now routed through the new Power Platform ingress gateway.

If this header is present and points to environment.api.powerplatform.com, the flow has been successfully migrated. If you still see logic.azure.com under the Host or DISGUISED-HOST headers, that flow or calling application still needs to be updated.

In our case, after replacing the URLs and testing, all flows were confirmed to be running on the new platform, and the integrations worked as expected.

So if we see this warning in your environment, you can either use the SQL4CDS query or the PowerShell command to locate such flows, update the calling systems with the new URL, and then verify by checking for the x-ms-igw-external-uri header in the request. That’s all you need to ensure your integrations continue to work smoothly past November 2025.

Hope it helps..

Advertisements

Troubleshoot “Something happened, and we couldn’t copy to this environment” error – Dataverse /Dynamics 365

Recently, while trying to copy an environment, we got the following issue –

Something happened, and we couldn’t copy to this environment. Please retry. If the issue continues, go to the Help + support tab. Include this correlation ID: 5e294f10-a784-4cda-881f-37799a37ddbc

At first glance, this seemed serious, especially because it mentioned a correlation ID and hinted at contacting Microsoft support.

In History also we can see it showing the status as failed.

We simply retried the copy operation — and this time, it worked flawlessly.

This indicates that the issue was likely transient, possibly caused by temporary backend resource availability or network hiccups.

Takeaway: Not every red error banner means a deep technical issue. Sometimes, it’s just the system asking for another try.

Hope it helps..

Advertisements

Resolved – Environment Operation Error, while trying to copy environment (Dataverse / Power Platform)

Recently we created a new environment, and when we tried copying our production environment to it, it gave the below error.

“Environment Operation Error -Sorry, something went wrong while requesting the details of an ongoing operation”

A screenshot of a message

AI-generated content may be incorrect.

On trying to open the newly created environment, we got the below error.

“Environment Not Found -The environment was not found. This can happen if you recently performed an operation or switched accounts”

A screenshot of a computer error message

AI-generated content may be incorrect.

Shortly after that, we noticed the environment disappeared from the list of environments in the Power Platform Admin Center. To investigate what might have gone wrong, we raised a support ticket. However, after about an hour, the Admin Center began displaying the newly created environment we were copying to, and upon opening it, we saw the message – “The environment was successfully copied.”

We got the below explanation from Microsoft Support which clarified the behaviour – “If a copy operation begins but does not complete, particularly when using the “Copy over everything” option, the target environment may enter a missing or soft-deleted state. This is a known behavior in Power Platform, where environments can temporarily disappear from the environment list during long-running or interrupted operations.”

Hope it helps..

Advertisements

Resolve – This environment can’t be copied because your org (tenant) is over capacity. Request an extension (Dataverse / Dynamics 365)

When trying to overwrite another environment with a copy of Prod, the system prevented the operation due to exceeding tenant capacity limits. This copy operation is subject to environment and storage capacity constraints.

We raised a Microsoft Support Ticket and learned that we can resolve this issue by either purchasing additional storage or requesting free temporary storage to complete the copy operation.

We need to raise another support ticket for temporary storage, that includes below details