Microsoft Azure

Manage and automate Microsoft Azure resources and services

Triggers

On Blob Created Listen to Azure Blob Storage blob creation events

On Blob Deleted Listen to Azure Blob Storage blob deletion events

On Image Deleted Listen to Azure Container Registry image deletion events

On Image Pushed Listen to Azure Container Registry image push events

On VM Deallocated Listen to Azure VM deallocation events

On VM Deleted Listen to Azure VM deletion events

On VM Restarted Listen to Azure VM restart events

On VM Started Listen to Azure VM start events

On VM Stopped Listen to Azure VM power-off events

Actions

Create Virtual Machine Creates a new Azure Virtual Machine with the specified configuration

Deallocate Virtual Machine Deallocates an Azure Virtual Machine, releasing compute resources

Delete Virtual Machine Deletes an existing Azure Virtual Machine

Restart Virtual Machine Restarts an Azure Virtual Machine

Start Virtual Machine Starts a stopped or deallocated Azure Virtual Machine

Stop Virtual Machine Powers off an Azure Virtual Machine without deallocating

Instructions

Azure Workload Identity Federation Setup

To connect SuperPlane to Microsoft Azure using Workload Identity Federation:

1. Create or Select an App Registration

1. Go to Azure Portal → Azure Active Directory → App registrations
2. Create a new registration or select an existing app
3. Note the Application (client) ID and Directory (tenant) ID

2. Complete the Connection

Enter the following information below and create the integration:

• Tenant ID: Your Azure AD tenant ID
• Client ID: Your app registration’s client ID
• Subscription ID: Your Azure subscription ID

After creation, you will be guided through configuring the Federated Identity Credential and granting the required permissions.

SuperPlane will use Workload Identity Federation to authenticate without storing any credentials.

On Blob Created

The On Blob Created trigger starts a workflow execution when a blob is created or replaced in an Azure Storage Account.

Use Cases

• Data pipelines: Trigger processing when new files arrive in a storage container
• Image processing: React to new images or media uploaded to blob storage
• Audit and compliance: Record blob creation events for traceability
• ETL workflows: Kick off data transformation when input files are uploaded

How It Works

This trigger listens to Azure Event Grid events from a Storage Account. When a blob is created or replaced, the Microsoft.Storage.BlobCreated event is delivered and the trigger fires with the full event payload.

Configuration

• Resource Group (required): The resource group containing the Storage Account.
• Storage Account (required): The Storage Account to watch.
• Container Filter (optional): A regex pattern to filter by container name.
• Blob Filter (optional): A regex pattern to filter by blob path.

Event Data

Each blob created event includes:

• subject: The full blob path in the format /blobServices/default/containers/{container}/blobs/{blob}
• data.api: The operation that triggered the event (e.g., PutBlob, CopyBlob)
• data.contentType: The content type of the blob
• data.contentLength: The size of the blob in bytes
• data.blobType: The blob type (BlockBlob, PageBlob, AppendBlob)
• data.url: The URL of the blob

Example Data

{
  "data": {
    "data": {
      "api": "PutBlob",
      "blobType": "BlockBlob",
      "clientRequestId": "6d6cef9a-a602-4a23-bc26-91bb68a2bf74",
      "contentLength": 524288,
      "contentType": "text/csv",
      "eTag": "0x8D4BCC2E4835CD0",
      "requestId": "d1e6b5a4-0001-0035-4a7b-2e5c4f000000",
      "sequencer": "00000000000004420000000000028963",
      "url": "https://mystorageaccount.blob.core.windows.net/mycontainer/path/to/myfile.csv"
    },
    "dataVersion": "",
    "eventTime": "2026-03-16T10:00:00Z",
    "eventType": "Microsoft.Storage.BlobCreated",
    "id": "831e1650-001e-001b-66ab-eeb76e069631",
    "metadataVersion": "1",
    "subject": "/blobServices/default/containers/mycontainer/blobs/path/to/myfile.csv",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/mystorageaccount"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.blob.created"
}

On Blob Deleted

The On Blob Deleted trigger starts a workflow execution when a blob is deleted from an Azure Storage Account.

Use Cases

• Cleanup workflows: Remove associated resources or records when a blob is deleted
• Audit and compliance: Record blob deletions for traceability
• Notification workflows: Alert teams when important files are removed from storage

How It Works

This trigger listens to Azure Event Grid events from a Storage Account. When a blob is deleted, the Microsoft.Storage.BlobDeleted event is delivered and the trigger fires with the full event payload.

Configuration

• Resource Group (required): The resource group containing the Storage Account.
• Storage Account (required): The Storage Account to watch.
• Container Filter (optional): A regex pattern to filter by container name.
• Blob Filter (optional): A regex pattern to filter by blob path.

Event Data

Each blob deleted event includes:

• subject: The full blob path in the format /blobServices/default/containers/{container}/blobs/{blob}
• data.api: The operation that triggered the event (e.g., DeleteBlob)
• data.blobType: The blob type (BlockBlob, PageBlob, AppendBlob)
• data.url: The URL of the deleted blob

Example Data

{
  "data": {
    "data": {
      "api": "DeleteBlob",
      "blobType": "BlockBlob",
      "clientRequestId": "6d6cef9a-a602-4a23-bc26-91bb68a2bf74",
      "contentLength": 0,
      "contentType": "text/csv",
      "eTag": "0x8D4BCC2E4835CD0",
      "requestId": "d1e6b5a4-0001-0035-4a7b-2e5c4f000000",
      "sequencer": "00000000000004420000000000028964",
      "url": "https://mystorageaccount.blob.core.windows.net/mycontainer/path/to/myfile.csv"
    },
    "dataVersion": "",
    "eventTime": "2026-03-16T11:00:00Z",
    "eventType": "Microsoft.Storage.BlobDeleted",
    "id": "afc359b4-001e-001b-66ab-eeb76e069631",
    "metadataVersion": "1",
    "subject": "/blobServices/default/containers/mycontainer/blobs/path/to/myfile.csv",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Storage/storageAccounts/mystorageaccount"
  },
  "timestamp": "2026-03-16T11:00:00Z",
  "type": "azure.blob.deleted"
}

On Image Deleted

The On Image Deleted trigger starts a workflow execution when a container image is deleted from an Azure Container Registry.

Use Cases

• Cleanup workflows: Remove associated resources when an image is deleted
• Audit trails: Record image deletions for compliance purposes
• Notification workflows: Alert teams when images are removed from the registry

How It Works

This trigger listens to Azure Event Grid events from an ACR registry. When an image or manifest is deleted, the Microsoft.ContainerRegistry.ImageDeleted event is delivered and the trigger fires with the full event payload.

Note: Image deletions reference manifests by digest. Tags may be empty if the manifest itself was deleted.

Configuration

• Resource Group (required): The resource group containing the ACR registry.
• Registry (required): The ACR registry to watch.
• Repository Filter (optional): A regex pattern to filter by repository name.

Event Data

Each delete event includes:

• target.repository: The repository name
• target.digest: The manifest digest that was deleted
• target.tag: The tag (may be empty for manifest deletes)
• actor.name: The user or service principal that deleted the image

Example Data

{
  "data": {
    "data": {
      "action": "delete",
      "actor": {
        "name": "myuser"
      },
      "id": "afc359b4-001e-001b-66ab-eeb76e069631",
      "request": {
        "addr": "203.0.113.0:49926",
        "host": "myregistry.azurecr.io",
        "id": "6d6cef9a-a602-4a23-bc26-91bb68a2bf74",
        "method": "DELETE",
        "useragent": "docker/20.10.7"
      },
      "source": {
        "addr": "myregistry.azurecr.io",
        "instanceID": "a29a591f-f89c-4f8d-b061-3c5d73d4756c"
      },
      "target": {
        "digest": "sha256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
        "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
        "repository": "myrepository",
        "tag": "",
        "url": "https://myregistry.azurecr.io/v2/myrepository/manifests/sha256:abcdef1234567890"
      },
      "timestamp": "2026-03-16T11:00:00Z"
    },
    "dataVersion": "1.0",
    "eventTime": "2026-03-16T11:00:00Z",
    "eventType": "Microsoft.ContainerRegistry.ImageDeleted",
    "id": "afc359b4-001e-001b-66ab-eeb76e069631",
    "metadataVersion": "1",
    "subject": "myregistry.azurecr.io/myrepository@sha256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.ContainerRegistry/registries/myregistry"
  },
  "timestamp": "2026-03-16T11:00:00Z",
  "type": "azure.image.deleted"
}

On Image Pushed

The On Image Pushed trigger starts a workflow execution when a container image is pushed to an Azure Container Registry.

Use Cases

• CI/CD pipelines: Trigger deployments when a new image version is pushed
• Image scanning: Kick off security scans when new images arrive
• Notification workflows: Notify teams when images are updated
• Tag tracking: React to specific image tags being published

How It Works

This trigger listens to Azure Event Grid events from an ACR registry. When an image push succeeds, the Microsoft.ContainerRegistry.ImagePushed event is delivered and the trigger fires with the full event payload.

Configuration

• Resource Group (required): The resource group containing the ACR registry.
• Registry (required): The ACR registry to watch.
• Repository Filter (optional): A regex pattern to filter by repository name.
• Tag Filter (optional): A regex pattern to filter by image tag.

Event Data

Each push event includes:

• target.repository: The repository name
• target.tag: The image tag
• target.digest: The image manifest digest
• actor.name: The user or service principal that pushed the image
• request.host: The registry hostname

Example Data

{
  "data": {
    "data": {
      "action": "push",
      "actor": {
        "name": "myuser"
      },
      "id": "831e1650-001e-001b-66ab-eeb76e069631",
      "request": {
        "addr": "203.0.113.0:49926",
        "host": "myregistry.azurecr.io",
        "id": "6d6cef9a-a602-4a23-bc26-91bb68a2bf74",
        "method": "PUT",
        "useragent": "docker/20.10.7"
      },
      "source": {
        "addr": "myregistry.azurecr.io",
        "instanceID": "a29a591f-f89c-4f8d-b061-3c5d73d4756c"
      },
      "target": {
        "digest": "sha256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
        "length": 1234567,
        "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
        "repository": "myrepository",
        "size": 1234567,
        "tag": "v1.2.3",
        "url": "https://myregistry.azurecr.io/v2/myrepository/manifests/sha256:abcdef1234567890"
      },
      "timestamp": "2026-03-16T10:00:00Z"
    },
    "dataVersion": "1.0",
    "eventTime": "2026-03-16T10:00:00Z",
    "eventType": "Microsoft.ContainerRegistry.ImagePushed",
    "id": "831e1650-001e-001b-66ab-eeb76e069631",
    "metadataVersion": "1",
    "subject": "myregistry.azurecr.io/myrepository:v1.2.3",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.ContainerRegistry/registries/myregistry"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.image.pushed"
}

On VM Deallocated

The On VM Deallocated trigger starts a workflow execution when an Azure Virtual Machine is deallocated.

Use Cases

• Cost tracking: Log when VMs are deallocated and compute charges stop
• Resource cleanup: Clean up associated resources (DNS, monitoring) when VMs are deallocated
• Scheduling verification: Confirm VMs are being deallocated according to cost-saving schedules
• Capacity planning: Track deallocation patterns for capacity planning
• Notification workflows: Alert teams when VMs go offline

How It Works

This trigger listens to Azure Event Grid events for Virtual Machine deallocate actions. When a VM deallocate action succeeds (status: Succeeded), the trigger fires and provides the full Azure Event Grid event payload.

Azure fires Microsoft.Resources.ResourceActionSuccess with operation name Microsoft.Compute/virtualMachines/deallocate/action when a VM is deallocated. Deallocation stops the VM and releases compute resources — the VM no longer incurs compute charges (only storage charges remain).

Important: This trigger fires on deallocate, not on power-off (stop without deallocation). Use the “On VM Stopped” trigger for power-off events.

Configuration

• Resource Group (optional): Filter events to only trigger for VMs in a specific resource group. Leave empty to trigger for all resource groups in the subscription.
• VM Name Filter (optional): A regex pattern to filter VMs by name. Only VMs whose name matches the pattern will trigger the workflow. Leave empty to trigger for all VM names.

Event Data

Each VM deallocate event includes the full Azure Event Grid event:

• id: Unique event ID
• topic: The Azure subscription topic
• subject: The full ARM resource ID of the VM (with /deallocate appended)
• eventType: The event type (Microsoft.Resources.ResourceActionSuccess)
• eventTime: The timestamp when the event occurred
• data: The event data including operationName, status, resourceProvider, resourceUri, subscriptionId, tenantId

Azure Event Grid Setup

Event Grid subscriptions are created automatically when the trigger is set up. SuperPlane will:

1. Create an Event Grid subscription at the Azure subscription scope
2. Configure it to forward Microsoft.Resources.ResourceActionSuccess events to the trigger webhook
3. Apply subject filters based on the configured resource group and resource type
4. Handle the Event Grid validation handshake automatically

No manual setup is required.

Notes

• The trigger fires when a VM is deallocated (stopped and compute resources released)
• After deallocation, only storage charges remain — compute charges stop
• It does not fire on power-off (stop without deallocation) — use “On VM Stopped” for that
• Failed deallocate operations do not trigger the workflow
• The trigger processes events from Azure Event Grid in real-time
• Multiple triggers can share the same Event Grid subscription if configured correctly

Example Data

{
  "data": {
    "data": {
      "operationName": "Microsoft.Compute/virtualMachines/deallocate/action",
      "resourceProvider": "Microsoft.Compute",
      "resourceUri": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01",
      "status": "Succeeded",
      "subscriptionId": "12345678-1234-1234-1234-123456789abc",
      "tenantId": "12345678-1234-1234-1234-123456789abc"
    },
    "dataVersion": "2",
    "eventTime": "2026-02-11T10:30:00Z",
    "eventType": "Microsoft.Resources.ResourceActionSuccess",
    "id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
    "metadataVersion": "1",
    "subject": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01/deallocate",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc"
  },
  "timestamp": "2026-02-11T10:30:00Z",
  "type": "azure.vm.deallocated"
}

On VM Deleted

The On VM Deleted trigger starts a workflow execution when an Azure Virtual Machine is deleted.

Use Cases

• Cleanup workflows: Remove DNS records, monitoring agents, or other dependent resources when a VM is deleted
• Inventory tracking: Update external inventory systems when VMs are removed
• Notification workflows: Send notifications to teams when VMs are deleted
• Cost tracking: Log VM deletion events for cost analysis and reporting
• Compliance auditing: Track and audit VM deletions for security and compliance

How It Works

This trigger listens to Azure Event Grid events for Virtual Machine resource delete operations. When a VM delete operation succeeds (status: Succeeded), the trigger fires and provides the full Azure Event Grid event payload.

Azure fires Microsoft.Resources.ResourceDeleteSuccess when a VM is successfully deleted. This is a distinct event from write operations — it only fires when the VM is actually removed, not during creation or updates.

Configuration

• Resource Group (optional): Filter events to only trigger for VMs in a specific resource group. Leave empty to trigger for all resource groups in the subscription.
• VM Name Filter (optional): A regex pattern to filter VMs by name. Only VMs whose name matches the pattern will trigger the workflow. Leave empty to trigger for all VM names.

Event Data

Each VM delete event includes the full Azure Event Grid event:

• id: Unique event ID
• topic: The Azure subscription topic
• subject: The full ARM resource ID of the VM
• eventType: The event type (Microsoft.Resources.ResourceDeleteSuccess)
• eventTime: The timestamp when the event occurred
• data: The event data including operationName, status, resourceProvider, resourceUri, subscriptionId, tenantId

Azure Event Grid Setup

Event Grid subscriptions are created automatically when the trigger is set up. SuperPlane will:

1. Create an Event Grid subscription at the Azure subscription scope
2. Configure it to forward Microsoft.Resources.ResourceDeleteSuccess events to the trigger webhook
3. Apply subject filters based on the configured resource group and resource type
4. Handle the Event Grid validation handshake automatically

No manual setup is required.

Notes

• The trigger fires only when a VM is successfully deleted
• Failed delete operations do not trigger the workflow
• The trigger processes events from Azure Event Grid in real-time
• Multiple triggers can share the same Event Grid subscription if configured correctly

Example Data

{
  "data": {
    "data": {
      "operationName": "Microsoft.Compute/virtualMachines/delete",
      "resourceProvider": "Microsoft.Compute",
      "resourceUri": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01",
      "status": "Succeeded",
      "subscriptionId": "12345678-1234-1234-1234-123456789abc",
      "tenantId": "12345678-1234-1234-1234-123456789abc"
    },
    "dataVersion": "2",
    "eventTime": "2026-02-11T10:30:00Z",
    "eventType": "Microsoft.Resources.ResourceDeleteSuccess",
    "id": "96257b6d-17d3-49e2-8369-fb185b29e1b5",
    "metadataVersion": "1",
    "subject": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc"
  },
  "timestamp": "2026-02-11T10:30:00Z",
  "type": "azure.vm.deleted"
}

On VM Restarted

The On VM Restarted trigger starts a workflow execution when an Azure Virtual Machine is restarted.

Use Cases

• Post-restart validation: Run health checks or smoke tests after a VM restarts
• Configuration reapplication: Reapply configuration that may not persist across restarts
• Monitoring alerts: Notify teams when VMs are restarted unexpectedly
• Audit logging: Track VM restart events for compliance and troubleshooting

How It Works

This trigger listens to Azure Event Grid events for Virtual Machine restart actions. When a VM restart action succeeds (status: Succeeded), the trigger fires and provides the full Azure Event Grid event payload.

Azure fires Microsoft.Resources.ResourceActionSuccess with operation name Microsoft.Compute/virtualMachines/restart/action when a VM is restarted. This reboots the VM in place without deallocating — the VM keeps its compute allocation and IP addresses.

Important: This trigger fires only on explicit restart actions. It does not fire on start (after stop/deallocate) or power-off. Use the “On VM Started” or “On VM Stopped” triggers for those events.

Configuration

• Resource Group (optional): Filter events to only trigger for VMs in a specific resource group. Leave empty to trigger for all resource groups in the subscription.
• VM Name Filter (optional): A regex pattern to filter VMs by name. Only VMs whose name matches the pattern will trigger the workflow. Leave empty to trigger for all VM names.

Event Data

Each VM restart event includes the full Azure Event Grid event:

• id: Unique event ID
• topic: The Azure subscription topic
• subject: The full ARM resource ID of the VM (with /restart appended)
• eventType: The event type (Microsoft.Resources.ResourceActionSuccess)
• eventTime: The timestamp when the event occurred
• data: The event data including operationName, status, resourceProvider, resourceUri, subscriptionId, tenantId

Azure Event Grid Setup

Event Grid subscriptions are created automatically when the trigger is set up. SuperPlane will:

1. Create an Event Grid subscription at the Azure subscription scope
2. Configure it to forward Microsoft.Resources.ResourceActionSuccess events to the trigger webhook
3. Apply subject filters based on the configured resource group and resource type
4. Handle the Event Grid validation handshake automatically

No manual setup is required.

Notes

• The trigger fires when a VM is explicitly restarted (rebooted in place)
• The VM keeps its compute allocation and IP addresses during a restart
• It does not fire on start (after stop/deallocate) — use “On VM Started” for that
• It does not fire on power-off or deallocate — use “On VM Stopped” or “On VM Deallocated”
• Failed restart operations do not trigger the workflow
• The trigger processes events from Azure Event Grid in real-time
• Multiple triggers can share the same Event Grid subscription if configured correctly

Example Data

{
  "data": {
    "data": {
      "operationName": "Microsoft.Compute/virtualMachines/restart/action",
      "resourceProvider": "Microsoft.Compute",
      "resourceUri": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01",
      "status": "Succeeded",
      "subscriptionId": "12345678-1234-1234-1234-123456789abc",
      "tenantId": "12345678-1234-1234-1234-123456789abc"
    },
    "dataVersion": "2",
    "eventTime": "2026-02-11T10:30:00Z",
    "eventType": "Microsoft.Resources.ResourceActionSuccess",
    "id": "d4e5f6a7-b8c9-0123-defa-234567890123",
    "metadataVersion": "1",
    "subject": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01/restart",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc"
  },
  "timestamp": "2026-02-11T10:30:00Z",
  "type": "azure.vm.restarted"
}

On VM Started

The On VM Started trigger starts a workflow execution when an Azure Virtual Machine is started.

Use Cases

• Post-boot configuration: Apply configuration, install agents, or run setup scripts when a VM starts
• Health checks: Run health checks or readiness probes after a VM boots
• Notification workflows: Notify teams when VMs come online
• Monitoring setup: Register VMs with monitoring systems when they start
• Auto-scaling workflows: Trigger downstream actions when new capacity comes online

How It Works

This trigger listens to Azure Event Grid events for Virtual Machine start actions. When a VM start action succeeds (status: Succeeded), the trigger fires and provides the full Azure Event Grid event payload.

Azure fires Microsoft.Resources.ResourceActionSuccess with operation name Microsoft.Compute/virtualMachines/start/action when a VM is explicitly started. This event fires specifically when a stopped/deallocated VM is started via the Azure portal, CLI, or API. It does not fire on initial VM creation, restarts, or other VM actions.

Configuration

• Resource Group (optional): Filter events to only trigger for VMs in a specific resource group. Leave empty to trigger for all resource groups in the subscription.
• VM Name Filter (optional): A regex pattern to filter VMs by name. Only VMs whose name matches the pattern will trigger the workflow. Leave empty to trigger for all VM names.

Event Data

Each VM start event includes the full Azure Event Grid event:

• id: Unique event ID
• topic: The Azure subscription topic
• subject: The full ARM resource ID of the VM (with /start appended)
• eventType: The event type (Microsoft.Resources.ResourceActionSuccess)
• eventTime: The timestamp when the event occurred
• data: The event data including operationName, status, resourceProvider, resourceUri, subscriptionId, tenantId

Azure Event Grid Setup

Event Grid subscriptions are created automatically when the trigger is set up. SuperPlane will:

1. Create an Event Grid subscription at the Azure subscription scope
2. Configure it to forward Microsoft.Resources.ResourceActionSuccess events to the trigger webhook
3. Apply subject filters based on the configured resource group and resource type
4. Handle the Event Grid validation handshake automatically

No manual setup is required.

Notes

• The trigger fires when a stopped/deallocated VM is explicitly started
• It does not fire on initial VM creation (use On VM Deleted’s write counterpart for that)
• It does not fire on VM restart — restart uses a separate restart/action operation
• Failed start operations do not trigger the workflow
• The trigger processes events from Azure Event Grid in real-time
• Multiple triggers can share the same Event Grid subscription if configured correctly

Example Data

{
  "data": {
    "data": {
      "operationName": "Microsoft.Compute/virtualMachines/start/action",
      "resourceProvider": "Microsoft.Compute",
      "resourceUri": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01",
      "status": "Succeeded",
      "subscriptionId": "12345678-1234-1234-1234-123456789abc",
      "tenantId": "12345678-1234-1234-1234-123456789abc"
    },
    "dataVersion": "2",
    "eventTime": "2026-02-11T10:30:00Z",
    "eventType": "Microsoft.Resources.ResourceActionSuccess",
    "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "metadataVersion": "1",
    "subject": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01/start",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc"
  },
  "timestamp": "2026-02-11T10:30:00Z",
  "type": "azure.vm.started"
}

On VM Stopped

The On VM Stopped trigger starts a workflow execution when an Azure Virtual Machine is powered off.

Use Cases

• Cost alerts: Notify teams when VMs are stopped but still allocated (still incurring compute charges)
• Shutdown workflows: Run cleanup scripts or save state when a VM is powered off
• Compliance monitoring: Track VM power-off events for audit trails
• Scheduling validation: Verify that VMs are being stopped according to schedule

How It Works

This trigger listens to Azure Event Grid events for Virtual Machine power-off actions. When a VM power-off action succeeds (status: Succeeded), the trigger fires and provides the full Azure Event Grid event payload.

Azure fires Microsoft.Resources.ResourceActionSuccess with operation name Microsoft.Compute/virtualMachines/powerOff/action when a VM is powered off. This stops the VM OS but keeps the compute allocation — the VM still incurs compute charges. To fully release compute resources, use deallocate instead.

Important: This trigger fires on power-off (stop without deallocation), not on deallocate. Use the “On VM Deallocated” trigger for deallocate events.

Configuration

• Resource Group (optional): Filter events to only trigger for VMs in a specific resource group. Leave empty to trigger for all resource groups in the subscription.
• VM Name Filter (optional): A regex pattern to filter VMs by name. Only VMs whose name matches the pattern will trigger the workflow. Leave empty to trigger for all VM names.

Event Data

Each VM stop event includes the full Azure Event Grid event:

• id: Unique event ID
• topic: The Azure subscription topic
• subject: The full ARM resource ID of the VM (with /powerOff appended)
• eventType: The event type (Microsoft.Resources.ResourceActionSuccess)
• eventTime: The timestamp when the event occurred
• data: The event data including operationName, status, resourceProvider, resourceUri, subscriptionId, tenantId

Azure Event Grid Setup

Event Grid subscriptions are created automatically when the trigger is set up. SuperPlane will:

1. Create an Event Grid subscription at the Azure subscription scope
2. Configure it to forward Microsoft.Resources.ResourceActionSuccess events to the trigger webhook
3. Apply subject filters based on the configured resource group and resource type
4. Handle the Event Grid validation handshake automatically

No manual setup is required.

Notes

• The trigger fires when a VM is powered off (stopped without deallocation)
• The VM still incurs compute charges after a power-off — use deallocate to release resources
• It does not fire on deallocate — use the “On VM Deallocated” trigger for that
• Failed power-off operations do not trigger the workflow
• The trigger processes events from Azure Event Grid in real-time
• Multiple triggers can share the same Event Grid subscription if configured correctly

Example Data

{
  "data": {
    "data": {
      "operationName": "Microsoft.Compute/virtualMachines/powerOff/action",
      "resourceProvider": "Microsoft.Compute",
      "resourceUri": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01",
      "status": "Succeeded",
      "subscriptionId": "12345678-1234-1234-1234-123456789abc",
      "tenantId": "12345678-1234-1234-1234-123456789abc"
    },
    "dataVersion": "2",
    "eventTime": "2026-02-11T10:30:00Z",
    "eventType": "Microsoft.Resources.ResourceActionSuccess",
    "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
    "metadataVersion": "1",
    "subject": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm-01/powerOff",
    "topic": "/subscriptions/12345678-1234-1234-1234-123456789abc"
  },
  "timestamp": "2026-02-11T10:30:00Z",
  "type": "azure.vm.stopped"
}

Create Virtual Machine

The Create Virtual Machine component creates a new Azure VM with full configuration options.

Use Cases

• Infrastructure provisioning: Automatically create VMs as part of deployment workflows
• Development environments: Spin up temporary VMs for testing and development
• Auto-scaling: Create VMs in response to load or events
• Disaster recovery: Quickly provision replacement VMs

How It Works

1. Validates the VM configuration parameters
2. Initiates VM creation via the Azure Compute API
3. Waits for the VM to be fully provisioned (using Azure’s Long-Running Operation pattern)
4. Returns the VM details including ID, name, and provisioning state

Configuration

• Resource Group: The Azure resource group where the VM will be created
• Name: The name for the new virtual machine
• Location: The Azure region (e.g., “eastus”, “westeurope”)
• Size: The VM size (e.g., “Standard_B1s”, “Standard_D2s_v3”)
• Admin Username: Administrator username for the VM
• Admin Password: Administrator password for the VM (must meet Azure complexity requirements)
• Virtual Network / Subnet: The network for the VM
• Network Interface ID: Optional existing NIC (overrides VNet/Subnet)
• OS Image: Select from common presets (Ubuntu, Debian, Windows Server)

Output

Returns the created VM information including:

• id: The Azure resource ID of the VM
• name: The name of the VM
• provisioningState: The provisioning state (typically “Succeeded”)
• location: The Azure region where the VM was created
• size: The VM size

Notes

• The VM creation is a Long-Running Operation (LRO) that typically takes 2-5 minutes
• The component waits for the VM to be fully provisioned before completing
• The admin password must meet Azure’s complexity requirements (12+ characters, mixed case, numbers, symbols)
• If Network Interface ID is empty, a NIC is created automatically from the selected VNet/Subnet

Example Output

{
  "data": {
    "id": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm",
    "location": "eastus",
    "name": "my-vm",
    "provisioningState": "Succeeded",
    "size": "Standard_B1s"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.vm"
}

Deallocate Virtual Machine

The Deallocate Virtual Machine component deallocates an existing Azure VM, stopping it and releasing its compute resources.

Use Cases

• Cost optimization: Deallocate VMs to stop compute charges during off-hours
• Scheduled shutdown: Deallocate VMs on a schedule to reduce costs
• Pre-resize operations: Deallocate a VM before changing its size
• Environment teardown: Deallocate VMs without deleting them

How It Works

1. Validates the VM parameters
2. Initiates VM deallocation via the Azure Compute API
3. Waits for the VM to be fully deallocated (using Azure’s Long-Running Operation pattern)
4. Returns the VM details including ID and name

Configuration

• Resource Group: The Azure resource group containing the VM
• VM Name: The name of the virtual machine to deallocate

Output

Returns the deallocated VM information including:

• id: The Azure resource ID of the VM
• name: The name of the VM
• resourceGroup: The resource group containing the VM

Notes

• Deallocation stops the VM and releases compute resources — compute charges stop
• Only storage charges remain for the VM’s disks
• Dynamic public IP addresses are released on deallocation
• The operation is a Long-Running Operation (LRO) that typically takes 1-3 minutes
• The component waits for the VM to be fully deallocated before completing
• To power off without releasing compute resources, use the “Stop Virtual Machine” action

Example Output

{
  "data": {
    "id": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm",
    "name": "my-vm",
    "resourceGroup": "my-rg"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.vm"
}

Delete Virtual Machine

The Delete Virtual Machine component deletes an existing Azure VM.

Use Cases

• Infrastructure teardown: Remove VMs as part of decommissioning workflows
• Cost optimization: Delete unused or idle VMs to reduce costs
• Environment cleanup: Remove temporary VMs after testing or development
• Auto-scaling: Delete VMs in response to reduced load

How It Works

1. Validates the VM deletion parameters
2. Initiates VM deletion via the Azure Compute API
3. Waits for the VM to be fully deleted (using Azure’s Long-Running Operation pattern)
4. Returns the deleted VM details including ID and name

Configuration

• Resource Group: The Azure resource group containing the VM
• VM Name: The name of the virtual machine to delete
• Delete Associated Resources: When enabled, also deletes the VM’s OS disk, data disks, network interfaces, and public IPs

Output

Returns the deleted VM information including:

• id: The Azure resource ID of the deleted VM
• name: The name of the deleted VM
• resourceGroup: The resource group that contained the VM

Notes

• The VM deletion is a Long-Running Operation (LRO) that typically takes 1-3 minutes
• The component waits for the VM to be fully deleted before completing
• When “Delete Associated Resources” is enabled, Azure cascade-deletes OS disk, data disks, NICs, and public IPs along with the VM
• Shared resources like virtual networks, subnets, and network security groups are never deleted
• This operation is irreversible

Example Output

{
  "data": {
    "id": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm",
    "name": "my-vm",
    "resourceGroup": "my-rg"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.vm"
}

Restart Virtual Machine

The Restart Virtual Machine component restarts an existing Azure VM in place.

Use Cases

• Apply updates: Restart VMs after applying OS or software updates
• Troubleshooting: Restart VMs to recover from transient issues
• Configuration changes: Restart VMs after configuration changes that require a reboot
• Automated maintenance: Restart VMs as part of maintenance workflows

How It Works

1. Validates the VM parameters
2. Initiates VM restart via the Azure Compute API
3. Waits for the VM to be fully restarted (using Azure’s Long-Running Operation pattern)
4. Returns the VM details including ID and name

Configuration

• Resource Group: The Azure resource group containing the VM
• VM Name: The name of the virtual machine to restart

Output

Returns the restarted VM information including:

• id: The Azure resource ID of the VM
• name: The name of the VM
• resourceGroup: The resource group containing the VM

Notes

• The VM is rebooted in place — it keeps its compute allocation and IP addresses
• The operation is a Long-Running Operation (LRO) that typically takes 1-3 minutes
• The component waits for the VM to be fully restarted before completing
• This performs a graceful restart of the VM

Example Output

{
  "data": {
    "id": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm",
    "name": "my-vm",
    "resourceGroup": "my-rg"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.vm"
}

Start Virtual Machine

The Start Virtual Machine component starts a stopped or deallocated Azure VM.

Use Cases

• Resume workloads: Start VMs that were previously stopped or deallocated
• Scheduled startup: Start VMs as part of scheduled workflows
• Auto-scaling: Start pre-provisioned VMs to handle increased demand
• Disaster recovery: Start standby VMs as part of failover workflows

How It Works

1. Validates the VM parameters
2. Initiates VM start via the Azure Compute API
3. Waits for the VM to be fully started (using Azure’s Long-Running Operation pattern)
4. Returns the VM details including ID and name

Configuration

• Resource Group: The Azure resource group containing the VM
• VM Name: The name of the virtual machine to start

Output

Returns the started VM information including:

• id: The Azure resource ID of the VM
• name: The name of the VM
• resourceGroup: The resource group containing the VM

Notes

• The VM must be in a stopped or deallocated state to be started
• The operation is a Long-Running Operation (LRO) that typically takes 1-3 minutes
• The component waits for the VM to be fully started before completing
• Once started, the VM will begin incurring compute charges

Example Output

{
  "data": {
    "id": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm",
    "name": "my-vm",
    "resourceGroup": "my-rg"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.vm"
}

Stop Virtual Machine

The Stop Virtual Machine component powers off an existing Azure VM without deallocating it.

Use Cases

• Temporary shutdown: Stop a VM temporarily while keeping its compute allocation
• Maintenance windows: Power off VMs during maintenance periods
• Pre-deallocate workflows: Stop VMs before performing other operations

How It Works

1. Validates the VM parameters
2. Initiates VM power-off via the Azure Compute API
3. Waits for the VM to be fully powered off (using Azure’s Long-Running Operation pattern)
4. Returns the VM details including ID and name

Configuration

• Resource Group: The Azure resource group containing the VM
• VM Name: The name of the virtual machine to stop

Output

Returns the stopped VM information including:

• id: The Azure resource ID of the VM
• name: The name of the VM
• resourceGroup: The resource group containing the VM

Notes

• The VM is powered off but compute resources remain allocated — you still incur compute charges
• To fully release compute resources and stop charges, use the “Deallocate Virtual Machine” action
• The operation is a Long-Running Operation (LRO) that typically takes 1-2 minutes
• The component waits for the VM to be fully powered off before completing

Example Output

{
  "data": {
    "id": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm",
    "name": "my-vm",
    "resourceGroup": "my-rg"
  },
  "timestamp": "2026-03-16T10:00:00Z",
  "type": "azure.vm"
}