When working with Azure, it’s common to reorganize resources into different Resource Groups (RGs) for governance, billing, or simply tidying up environments. However, here’s a fact that often surprises developers and administrators: moving a Logic App Consumption to another Resource Group does not automatically update its internal workflow configurations; you must do it manually.
Let’s break this down with an example:
- Suppose you have a main (parent) Logic App Consumption (workflow) that calls a child Logic App Consumption (workflow) in the same Resource Group, for example, RG-SASP-LA-POC.
- Internally, in the main (parent) Logic App Consumption using the Logic App Connector, the call is represented by the workflow ID, which is a fully qualified Azure resource identifier. For example:
- /subscriptions/<subscription-id>/resourceGroups/RG-SASP-LA-POC/providers/Microsoft.Logic/workflows/LA-BP-Tip-Trick-GetSubsIdAndResourceGroup-Workaround
Notice how the resource group name (
RG-SASP-LA-POC) is baked into the definition.
Now, if you move these two Logic Apps, the father and the child, to another Resource Group, let’s say RG-SASP-LA-CONSUMPTION-POC. This is quite a simple task. We select the Logic Apps to be moved and then click on the Move button. Some validation will occur before you are allowed to move, and if these validations are successful, you can then move the Logic Apps.
After that, the Logic Apps themselves will appear in the new resource group in the Azure Portal. However, the internal JSON definition of the workflow won’t be updated to reflect this new resource group. In other words, it will not replace the old resource group reference with the new one, nor will it prompt you to confirm this action during the move. That means any reference to child workflows, API connections, or other Logic Apps using absolute resource IDs will still point to the old resource group.
This can create unexpected issues:
- If you delete the old Resource Group, those hardcoded references will break.
- Your Logic App will start failing at runtime because it’s still trying to reach resources in the “old world.”
- Although visually everything appears fine in the new Resource Group, under the hood, you are still tied to the old configuration.
So what can you do about it?
The best practice is:
- Always verify and update workflow definitions after moving Logic Apps between Resource Groups.
- For child workflow calls, consider using relative paths or parameters instead of absolute IDs. For example, reference only the workflow name where possible, and externalize environment-dependent values into parameters or configuration files.
- If you must rely on absolute IDs, you’ll need to manually edit the workflow JSON or redeploy using ARM/Bicep templates or Azure DevOps pipelines with the correct RG values.
In the Azure Portal, to quickly fix, just edit the Logic App and change the resource group in the Workflow ID.
This fact highlights an important principle when working with serverless and cloud-native architectures: what you see in the portal is often an abstraction of the underlying infrastructure. Behind the scenes, the underlying definitions might still contain absolute references that don’t change automatically.
So, next time you think about “tidying up” your Logic Apps by moving them to a new Resource Group, remember: the portal move operation is cosmetic for management, but not transformative for your workflow internals. Plan ahead, test after moving, and keep your configurations flexible.
To lazy to read? We’ve got you covered! Check out our video version of this content!
If you liked the content or found it helpful and would like to support me in writing more, you can consider purchasing (or helping to purchase) a Star Wars Lego set for my son.
