- A subscription is the wiring: it binds an event topic to a runnable item, an ABX action or an Orchestrator workflow, optionally filtered by a condition.
- Blocking subscriptions make the deployment wait and can change or stop it. Non-blocking subscriptions run asynchronously with no guaranteed order. The choice drives everything.
- Blocking subscriptions run in priority order (0 is highest); ties break by reverse-alphabetical name. After all blocking subs finish, the event fans out to all non-blocking subs at once.
- Every subscription should carry a condition so it fires only when relevant. A condition-less blocking subscription on a hot event topic is the classic way to wedge every deployment.
- For anything multi-step, prefer one Orchestrator workflow over a chain of subscriptions. Subscriptions are wiring, not a workflow engine.
Who this is for: Automation engineers and platform admins wiring extensibility into VCF Automation, and architects designing event-driven integrations that have to stay reliable.
Prerequisites: A VCF Automation 9.x instance, at least one ABX action or Orchestrator workflow to run, and familiarity with the request-to-deployment flow. The extensibility menu in Automation Assembler.
The fastest way to take down a self-service catalog is a single blocking subscription with no condition and a slow runnable item. I have watched it happen: someone wires a blocking subscription to the compute provisioning topic, points it at an action that calls an external system, the external system is having a bad day, and now every deployment in the organization hangs behind a five-minute timeout. Nothing is broken in the platform. The wiring is just wrong.
Subscriptions are the Event Broker in VCF Automation 9 (the product formerly known as VMware Aria Automation, and before that vRealize Automation). They are the connective tissue between deployment lifecycle events and the ABX actions and Orchestrator workflows from the previous two Parts. Get the wiring right and extensibility is invisible. Get it wrong and it is the first thing that breaks. I am writing against the current 9.1 release.
What a subscription wires together
A subscription has three parts. An event topic decides when it fires, a runnable item decides what runs, and a condition decides whether it should run for this particular event. The topic is a category of lifecycle events, such as compute post-provision or deployment completed. The runnable item is either an ABX action or an Orchestrator workflow. The condition is an optional expression evaluated against the event payload. Leave the condition out and the subscription fires on every event of that topic, which is rarely what you want.
Blocking or non-blocking: the decision that matters
Event topics come in two kinds, and they behave very differently. Non-blocking topics only allow non-blocking subscriptions. These run asynchronously, the deployment does not wait for them, and you cannot rely on the order they fire in. They are for side effects: send a notification, write a record, update an external inventory. If one fails, the deployment still succeeds.
Blocking topics are different. A blocking subscription makes the deployment pause until the runnable item completes, and the item can change the request, for example injecting a hostname or an IP before the machine is built. Because the deployment waits, a blocking subscription that is slow or fails can stall or fail the request. That power is the whole point, and also the whole risk.
Priority and ordering
When several blocking subscriptions match the same event, they run in priority order, where 0 is the highest priority. If two share a priority, they run in reverse-alphabetical order by subscription name, which is a fragile thing to depend on. Once every blocking subscription has run, the event is delivered to all non-blocking subscriptions at the same time. So the mental model is: blocking subs in a deliberate sequence first, then non-blocking subs in a parallel burst.
A blocking subscription with no condition runs its runnable item on every matching deployment, and every deployment waits for it. If the item is slow or its target is down, you have coupled the availability of an external system to the availability of your catalog. Always add a condition, keep blocking runnable items fast and defensive, and set a timeout you have actually tested. Blocking is for changing the request, not for doing real work.
Conditions shrink the blast radius
A condition is an expression evaluated against the event data. If it returns true, the subscription runs; if false, it is skipped without running the runnable item at all. This is how you make a subscription fire only for the deployments that need it, instead of for everything. Use a custom property as a flag set on the template or the request, and gate the subscription on it. Below is a condition that runs only when a request explicitly opts in to DNS registration and only for vSphere machines.
# Subscription condition (evaluated against the event payload).
# Runs only when the request opted in AND the resource is a vSphere VM.
event.data['customProperties']['dns_register'] == 'true' &&
event.data['resourceType'] == 'Cloud.vSphere.Machine'
# No condition = fires on every event of this topic.
# A precise condition = fires only where it is needed.Common event topics
You do not need to memorize the full list, but you should know the handful you will use constantly and whether each supports blocking. The names below follow the platform topics; confirm exact availability against your version, since the topic set can shift between releases.
| Event topic | Fires when | Typical use |
|---|---|---|
| Compute allocation | Before placement, blocking | Assign hostname / IP from IPAM |
| Compute provision (pre) | Before the VM is built, blocking | Enrich or validate the request |
| Compute post-provision | After the VM exists | Register DNS, CMDB, config mgmt |
| Deployment completed | After the whole deployment | Notify, record, kick off downstream |
| Compute removal | On destroy / reclaim | Deregister DNS, clean up records |
Extensibility patterns that hold up
Most real integrations fall into two patterns, and naming them keeps designs honest.
Enrich-before (blocking)
When the deployment needs a value before it can proceed, a hostname, an IP from IPAM, a validated naming convention, use a blocking subscription on an allocation or pre-provision topic. The runnable item computes the value and returns it into the request. Keep it fast, make it fail safe, and give it a tested timeout, because the whole deployment is waiting on it.
Record-after (non-blocking)
When the work is a side effect that should not be able to fail the deployment, register DNS, update the CMDB, send a Slack message, use a non-blocking subscription on a post-provision or deployment-completed topic. If the external system is down, the deployment still succeeds and you reconcile the side effect later. Never put a side effect on a blocking topic just because it is convenient.
One workflow beats a chain of subscriptions
The anti-pattern I unwind most often is a sequence of subscriptions, each triggering the next by side effect, used to fake a multi-step process. Because non-blocking subscriptions have no guaranteed order and no shared state, this is fragile by construction. If you need steps with order, state, and error handling, that is a single Orchestrator workflow triggered by one subscription, not five subscriptions hoping to run in sequence. Subscriptions are wiring; the workflow is the logic.
You need IPAM allocation to happen before naming validation on the same pre-provision topic. Give the IPAM subscription priority 0 and the validation subscription priority 1, so IPAM runs first and validation sees the assigned address. Do not give both priority 0 and rely on the names, because the tie-break is reverse-alphabetical and a future rename silently reorders them.
Set each runnable item a timeout you have measured, say 30 seconds, not a guess. With two blocking subscriptions at 30 seconds each, a worst-case healthy run adds about a minute to provisioning. If that is unacceptable, the work does not belong on a blocking topic.
In practice: I name subscriptions with the pattern topic-action-blocking-or-not and document the priority of every blocking subscription in one place. The Event Broker has no global view of execution order that survives a rename, so the order lives in your design notes or it lives nowhere.
Disclaimer: Blocking subscriptions can stop or fail real deployments. Test new subscriptions as non-blocking against a throwaway project first, validate the condition matches only what you expect, and only promote to blocking once you have measured the runnable item’s latency and set a timeout.
When a subscription does not fire
The second most common Event Broker ticket, after the wedged deployment, is the opposite: a subscription that silently never runs. The symptom is identical to having no subscription at all, so people assume the platform is broken when the wiring is simply not matching. Debug it in a fixed order and you will find the cause every time.
First, check that the subscription is enabled and bound to the topic you think it is. It is easy to wire a side effect to deployment-completed when you meant post-provision, and the two fire at different moments with different payloads. Second, check the condition. A condition that references a custom property the request never sets evaluates to false and the subscription is skipped without a trace. The fastest way to prove this is to temporarily clear the condition in a test project and confirm the runnable item runs at all. Third, check the payload shape. Conditions read fields out of the event data, and if you reference resourceType when the event exposes a different key, the expression quietly fails. Inspect a real event payload before you write the condition, not after.
Fourth, check ordering assumptions. If a non-blocking subscription depends on a value another non-blocking subscription was supposed to set, it will work intermittently and fail under load, because non-blocking order is not guaranteed. That is not a bug to chase; it is a design that needs a blocking subscription with a priority, or a single workflow. The run history of the action or workflow is your evidence trail, so log enough on each run to reconstruct what the condition saw.
Treat subscriptions as code
Subscriptions drift. Someone adds one to fix a one-off, names it badly, and a year later nobody knows why a deployment calls an unfamiliar action. The fix is discipline, not tooling. Keep subscriptions under version control alongside the actions and workflows they trigger, export them as part of your content, and review the full set the way you would review firewall rules, because functionally that is what a blocking subscription is: a rule on the path of every matching deployment. Document the priority and the intended order of blocking subscriptions in one place, since the platform will not reconstruct your intent after a rename. A small, named, documented set of subscriptions is the difference between extensibility you can reason about and a pile of side effects you are afraid to touch.
Final Thoughts
Default to non-blocking, and reach for blocking only when the deployment genuinely needs a value before it can continue, because blocking couples your catalog’s reliability to whatever the runnable item touches. Put a condition on every subscription so it fires only where it should; an unconditioned subscription is the cheapest way to turn a small integration into a platform-wide dependency. I would not chain subscriptions to fake a process; the moment you need order and state, that is one Orchestrator workflow behind one subscription, and treating it that way will save you a debugging weekend. Validate the condition and the timeout before you trust a subscription in production, because those two are where event-driven extensibility quietly goes wrong.
Take one integration you want, write its condition first, wire it as a non-blocking subscription, and only promote it to blocking if it truly must change the request. Next in the series we leave the UI behind and drive all of this through the VCF Automation API.
References
- Broadcom TechDocs — Event subscriptions in VCF Automation
- Broadcom TechDocs — Event topics provided with VCF Automation
- Broadcom TechDocs — Creating a subscription (extensibility)
- Cloud Blogger — ServiceNow CMDB integration with conditions and workflows
About The Author
