Deallocate on Activity Log

Prerequisites

One deployment, two identities. Yours to deploy it, and the one the deployment creates to do the work.

Software

An existing resource group to deploy into
Azure CLI with Bicep, or Terraform with the azurerm and azapi providers
The subscription registered for Microsoft.Logic and Microsoft.Insights

Who needs which role

To deploy

Your own account

You hold these, once, at deployment time.

Contributor on the resource group — the Logic App, the connection, the alert and the action group
User Access Administrator or Owner on the subscription — one role assignment lands there

Afterwards

The identity it creates

A system-assigned identity on the Logic App holds one built-in role and nothing else.

Desktop Virtualization Power On Off Contributor at the subscription — read, start, power off and deallocate a VM

The role's name is misleading and the role is not: it is the narrowest built-in role that can deallocate a machine, and it has nothing to do with AVD unless you point it at a host pool.

Do not use this for

It reacts to one event and does one thing. If that is not the whole problem, it is the wrong tool.

If you	Why not	Do this instead
Stop machines from the CLI or the portal on purpose and want those deallocated too	Only a guest shutdown carries the sentence the workflow looks for; an API stop is deliberately left alone	`az vm deallocate`, or a schedule
Need schedules, a dry run, guards, or a record of what was decided	There is no schedule, no blast radius and no report here — one event, one call	VM Power Management, further down
Run machines whose dynamic public IP or ephemeral OS disk has to survive a shutdown	Deallocation releases the one and discards the other	Static IPs, or keep those machines out of the alert's scope
Want it on some machines only	The alert rule is subscription-wide and the workflow has no exclusion tag	Narrow the rule's scope in the template

← Overview