More often than we want to admit, customers frequently come to us with cases where a Consumption logic app was unintentionally deleted. Although you can somewhat easily recover a deleted Standard logic app, you can't get the run history back nor do the triggers use the same URL. For more information, see GitHub – Logic-App-STD-Advanced Tools.

However, for a Consumption logic app, this process is much more difficult and might not always work correctly. The definition for a Consumption logic app isn't stored in any accessible Azure storage account, nor can you run PowerShell cmdlets for recovery. So, we highly recommend that you have a repository or backup to store your current work before you continue. By using Visual Studio, DevOps repos, and CI/CD, you have the best tools to keep your code updated and your development work secure for a disaster recovery scenario. For more information, see Create Consumption workflows in multitenant Azure Logic Apps with Visual Studio Code.

Despite these challenges, one possibility exists for you to retrieve the definition, but you can’t recover the workflow run history nor the trigger URL. A few years ago, the following technique was documented by one of our partners, but was described as a “recovery” method: 

Recovering a deleted Logic App with Azure Portal – SANDRO PEREIRA BIZTALK BLOG (sandro-pereira.com) 

We’re publishing the approach now as a blog post but with the disclaimer that this method doesn’t completely recover your Consumption logic app, but retrieves lost or deleted resources. The associated records aren’t restored because they are permanently destroyed, as the warnings describe when you delete a Consumption logic app in the Azure portal. 

Recommendations

We recommend applying locks to your Azure resources and have some form of Continuous Integration/Continuous Deployment (CI/CD) solution in place. Locking your resources is extremely important and easy, not only to limit user access, but to also protect resources from accidental deletion.

To lock a logic app, on the resource menu, under Settings, select Locks. Create a new lock, and select either Read-only or Delete to prevent edit or delete operations. If anyone tries to delete the logic app, either accidentally or on purpose, they get the following error:

For more information, see Protect your Azure resources with a lock – Azure Resources Manager.

Limitations

• If the Azure resource group is deleted, the activity log is also deleted, which means that no recovery is possible for the logic app definition.
• Run history won’t be available.
• The trigger URL will change.
• Not all API connections are restored, so you might have to recreate them in the workflow designer.
• If API connections are deleted, you must recreate new API connections.
• If a certain amount of time has passed, it’s possible that changes are no longer available.

Procedure

1. In the Azure portal, browse to the resource group that contained your deleted logic app.
2. On the logic app menu, select Activity log.
3. In the operations table, in the Operation name column, find the operation named Delete Workflow, for example:

4. Select the Delete Workflow operation. On the pane that opens, select the Change history tab. This tab shows what was modified, for example, versioning in your logic app.

As previously mentioned, if the Changed Property column doesn’t contain any values, retrieving the workflow definition is no longer possible.

5. In the Changed Property column, select <deleted resource>.

You can now view your logic app workflow’s JSON definition. 

6. Copy this JSON definition into a new logic app resource.
   • As you don’t have a button that restores this definition, the workflow should load without problems.
   • You can also use this JSON workflow definition to create a new ARM template and deploy the logic app to an Azure resource group with the new connections or by referencing the previous API connections.
   • If you’re restoring this definition in the Azure portal, you must go to the logic app’s code view and paste your definition there.

The complete JSON definition contains all the workflow’s properties, so if you directly copy and paste everything into code view, the portal shows an error because you're copying the entire resource definition. However, in code view, you only need the workflow definition, which is the same JSON that you’d find on the Export template page.

So, you must copy the definition JSON object’s contents and the parameters object’s contents, paste them into the corresponding objects in your new logic app, and save your changes.

In this scenario, the API connection for the Azure Resource Manager connector was lost, so we have to recreate the connection by adding a new action. If the connection ID is the same, the action should re-reference the connection.

After we save and refresh the designer, the previous operation successfully loaded, and nothing was lost. Now you can delete the actions that you created to reprovision the connections, and you're all set to go.

 We hope that this guidance helps you mitigate such occurrences and speeds up your work.