- Notifications are the half of governance that decides whether tenants trust the platform. A lease that deletes a deployment is fair only if the owner was warned.
- There are two channels: outbound email, driven by scenarios, and in-UI consumption reports, infrastructure alerts and critical notifications.
- Email is outbound-only and scenario-based: request completed, approval required, lease expiring soon, and lease expired just before destruction.
- The provider controls which alerts and reports tenants see, and via VCF Operations you can send cost, bill, quota and capacity-threshold notifications to tenant email.
- My recommendation: configure the email server on day one, send to real owners not shared mailboxes, and treat every notification as signal. Noise gets filtered, and then the one that mattered gets filtered with it.
Governance without notice feels like sabotage. A lease that deletes a deployment is fair if the owner got three warnings and ignored them. It is an incident if the only warning went to a mailbox nobody reads. Notifications are the half of governance that decides whether tenants trust the platform or fight it, and they are usually an afterthought bolted on after the first angry ticket. They should not be. This Part closes the series on the consumer experience: how VCF Automation tells people what is happening to the things they own.
Two channels, two jobs
VCF Automation reaches consumers two ways, and they do different jobs. Outbound email is the push channel: it fires on events, so it is how you warn someone that their lease is about to expire or that their request needs an approval. The in-UI surface is the pull channel: consumption reports, infrastructure alerts and critical operation notifications shown inside the interface, where someone goes to see the current state. Email is for the thing that cannot wait for a login; the UI is for the thing they review when they choose to. Use both, for the right things.
Email server and scenarios
Nothing emails until you configure an outbound server. You provide the server name and a sender address, and a username and password if the server requires authentication. It is outbound only; VCF Automation sends, it does not receive. Get this in place early, because every scenario notification depends on it and the absence is silent: policies still fire, but the warnings never go out.
# VCF Automation outbound email for notifications (SMTP, outbound only)
Server: smtp.corp.local
Port: 587
Sender address: vcfa-noreply@corp.local
Authentication: required
Username: vcfa-smtp
Password: REDACTED
# Drives lease, approval and request-completion notificationsOnce the server is set, notifications fire on scenarios, the named events VCF Automation knows how to send. The ones that matter most are tied to the policies from earlier in this series: a lease expiring soon, a lease expired and minutes from destruction, a catalog request completing, and a request that needs an approval. The lease scenarios are the ones that turn the lease trap from an incident into a fair process.
| Scenario | When it fires | Channel |
|---|---|---|
| Request completed | On successful provisioning | |
| Approval required | When a request needs sign-off | |
| Lease expiring soon | Around three days before expiry | |
| Lease expired, pre-delete | Minutes before destruction | |
| Cost / quota / capacity | Thresholds and schedules (VCF Operations) | Email + in-UI |
In-UI reports and what tenants are allowed to see
Inside the interface, consumers get consumption reports, infrastructure alerts and critical operation notifications. The control that matters here is that the provider decides which alerts and reports are visible to tenants. That is not a limitation, it is the multi-tenancy boundary doing its job: a tenant should see their own consumption and the alerts relevant to them, not the provider's whole operational picture. Curate deliberately. Show tenants the reports that help them self-manage, such as their own utilization and cost, and withhold the platform-wide noise that would only confuse or alarm them.
Cost, quota and capacity through VCF Operations
The financial and capacity notifications come through the VCF Operations integration. Org admins can configure email notifications for alerts, cost reports, bills and quota usage, and tenants can be sent immediate email when they cross a capacity threshold or when pricing information changes. Providers tailor the consumption, utilization and cost breakdowns per tenant and deliver them to tenant email. This is the notification side of the cost and showback story: a showback report nobody receives changes no behavior, while a quota-threshold email lands before the overspend rather than after.
Final Thoughts
Configure the email server before you turn on a single lease policy, send to real owners, curate the in-UI reports tenants see, and wire cost and quota alerts through VCF Operations so the warning beats the overspend. The reason is trust: every governance control in this series, leases, approvals, quotas, showback, only feels fair when the people affected were told in time and could act. Notifications are cheap to set up and expensive to skip, because the cost shows up as eroded trust and a support queue rather than a line item. When would I dial it back? Never to zero, but ruthlessly prune low-value emails so the important ones survive the inbox. Treat the warning that precedes a destroy as the most important message your platform sends, because to the person losing a deployment, it is. That closes the VCF Automation series: from what the product is, through provider and tenant setup, governance and extensibility, to the consumption layer and the experience that makes it usable. Which of your governance actions currently fires with no warning attached, and how soon can you fix that one?
References
- Add an email server in VCF Automation to send notifications (Broadcom TechDocs)
- Send Email Notifications to Users in VCF Automation (Broadcom TechDocs)
- Notifications in VCF Operations (Broadcom TechDocs)
About The Author
