Dr. Pranay Jha

You added the content source. The import shows twelve cloud templates. The tenant admin opens the catalog and sees nothing. That is the most common Service Broker ticket I get on a fresh VCF Automation build, and it is not a defect. Importing a content source and publishing a catalog item are two separate actions, and the gap between them is where most self-service rollouts stall on day one.

This Part walks the full publishing pipeline in VCF Automation 9 (the product formerly known as VMware Aria Automation, and before that vRealize Automation). I am writing against VCF 9.1, which shipped in May 2026 and is the current release at the time of writing, with the 9.0 behavior called out where it differs. The mechanics are the same whether you click through the UI or drive the API: get a template into a shape Service Broker can see, register it as a source, and then explicitly grant a project access to it.

Where Service Broker sits in the request flow

Two services split the work. Automation Assembler is where you author and iterate on VMware Cloud Templates. Automation Service Broker is where those templates, plus Orchestrator workflows and other sources, become governed catalog items that end users request without ever seeing the YAML. The split matters because the two have different audiences and different permissions. An automation engineer lives in Assembler. A tenant consumer lives in Service Broker and should never need an Assembler login. If you are fuzzy on how the services connect, the architecture Part lays out the full path from request to deployment.

The publishing pipeline, step by step

Here is the sequence I run on every new environment, in order. Each step has a failure mode that produces the same visible symptom, an empty or stale catalog, so doing them in order saves you guessing later.

Step 1: Release a template version in Assembler

A cloud template you are still editing is invisible to Service Broker. The Templates content source imports released versions only. In Assembler, open the template, click Version, give it a version string, and tick Release. That released version is the contract Service Broker imports. If you edit the template afterwards, the catalog keeps serving the old released version until you release a new one. That is by design, and it is also the second most common confusion after the empty catalog: someone fixes a bug in the template, never releases it, and wonders why the catalog still deploys the broken build.

A minimal template that is worth publishing looks like this. Note the flavor and image values are mapping names, not raw vSphere objects. Those mappings come from the infrastructure work in earlier Parts.

formatVersion: 1
inputs:
  size:
    type: string
    enum: [small, medium]
    default: small
    title: VM size
resources:
  app-vm:
    type: Cloud.vSphere.Machine
    properties:
      image: ubuntu-2404
      flavor: '${input.size}'
      networks:
        - network: '${resource.app-net.id}'
  app-net:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing

# In Assembler: Version -> set version 1.0 -> tick Release.
# Only released versions are importable by the Templates content source.

Step 2: Add a content source in Service Broker

In the VCF Automation UI, Service Broker exposes a Content & Policies area that holds Content Sources, Content, Policies, and Notifications. Under Content Sources, create a new source, pick the type (for a cloud template you choose the VCF Automation Templates type), select the project the source is anchored to, and create it. Service Broker discovers and imports the released items. The page shows the count of discovered and imported items, which is your first sanity check: if the count is zero, the problem is upstream in Step 1, not in your sharing.

You can import all items from a source or curate individual ones. On a real platform I import the whole source per logical bundle (a team, an application family) rather than mixing unrelated templates into one source, because the source is the unit you later reference in sharing policies. Mixed sources make least-privilege sharing painful.

Step 3: Share the content with a content sharing policy

This is the step people miss. Importing a source makes items known to Service Broker; a content sharing policy makes them requestable by a project. Under Content & Policies, open Policies, create a Content Sharing policy, set the scope to the target project, and add either the whole content source or specific catalog items. Save it, and the items appear in that project catalog for the users and groups you named. No policy, no catalog. Every time.

What you can actually publish

Cloud templates are the obvious source, but Service Broker publishes several content types, and each behaves slightly differently in the catalog. Knowing the set up front stops you from building an Orchestrator workflow when a template would do, or the reverse.

Content source type	What it publishes	When I reach for it
VCF Automation Templates	Released cloud template versions	Standard VM and multi-resource deployments. The default.
VCF Operations Orchestrator workflows	Selected workflows as catalog items	Operational tasks (decommission, reconfigure, integrations) that are logic, not infrastructure.
Terraform configurations	HCL embedded as a deployable item	Teams already standardized on Terraform modules you want to expose as self-service.
Content libraries	VM images (OVA/OVF, ISO)	The image backing for templates, not a catalog item on its own. Provider, org, or project scoped.

Content libraries deserve a flag because VCF Automation 9.1 reworked them. There are now three library scopes: a Provider Content Library available across all tenants, an Organization Content Library inside one tenant, and a new Project Content Library that supports namespace capture and per-project read/write permissions. 9.1 also adds a Canonical Content Library, a VMware-managed subscription that syncs certified Ubuntu images straight into your environment. If you are publishing templates that reference images, get the library scope right first, because a template that references an image the project cannot see will import fine and then fail at request time.

Sharing scope: provider, organization, project

Content sharing in VCF Automation happens at the project level. All users and groups associated with a project can be granted access to specific catalog items through a content sharing policy. You can grant access to everyone in the project, or name individual users and groups for finer control, and you can scope a policy to a whole content source or to individual items.

The constraint that surprises people: to share the same template with more than one project, you create a separate content sharing policy for each project. There is no single policy that fans out across projects. On a platform with twenty projects and a shared library of standard templates, that is a lot of policies. This is the design tax of per-project governance, and it is worth confronting before it sprawls.

Publishing as code: the VCF Automation API

Clicking through the UI is fine for the first source. For anything you need to reproduce across instances, drive it through the VCF Automation API so dev, test, and prod stay identical. The two endpoints you care about are the Catalog API for sources and items, and the Policy API for the sharing policy. The content sharing policy uses a fixed typeId, com.vmware.policy.catalog.entitlement, and it always carries a projectId.

Below is the shape of it. Token acquisition is its own topic and gets a full treatment later in the series; here I assume you already hold a bearer access token.

# 1. List the catalog sources visible to a project (confirm the source ID).
curl -s -k -X GET 
  'https://automation.example.local/catalog/api/admin/sources?projectId=PROJECT_ID' 
  -H 'Authorization: Bearer ACCESS_TOKEN'

# 2. Create a content sharing policy that entitles one project to that source.
curl -s -k -X POST 
  'https://automation.example.local/policy/api/policies' 
  -H 'Authorization: Bearer ACCESS_TOKEN' 
  -H 'Content-Type: application/json' 
  -d '{
        "name": "share-web-tier-to-payments",
        "typeId": "com.vmware.policy.catalog.entitlement",
        "enforcementType": "HARD",
        "projectId": "PROJECT_ID",
        "definition": {
          "entitlements": [
            { "id": "CATALOG_SOURCE_ID", "type": "CatalogSourceIdentifier" }
          ]
        }
      }'

# Expected: HTTP 201 with the new policy id.
# Common failure: 400 if entitlements is empty or the type is wrong;
# or a 201 that still yields an empty catalog because the template
# version was never released (fix Step 1 first).

For full infrastructure-as-code against an All Apps organization, the vmware/vcfa Terraform provider manages content libraries and related catalog objects declaratively, and it is the cleaner choice once you are past one-off setup. That provider gets its own Part later. Re-verify its current version on the Terraform Registry before you pin it, since it is moving quickly in the 9.x line.

VM Apps and All Apps: same catalog, different plumbing

The publishing flow above holds in both organization types, but the underlying model differs. A VM Apps organization stays close to the Aria Automation 8.x behavior, including the familiar Content Library support carried forward. An All Apps organization is built entirely on the content-library model and the Kubernetes-style architecture, so library scope and namespace capture matter more there. The Policies UI even splits along these lines: the path for setting up policies in a VM Apps org is not the same page as managing policies for an All Apps org. Before you start publishing, confirm which org type you are operating in, because copy-pasting a runbook written for the other type is a reliable way to waste an afternoon.

What I’d Do

Publish one thing end to end before you automate anything. Release a single template version, add one content source, write one content sharing policy scoped to one project, and request the item as an actual tenant user. That round trip proves the whole chain and gives you the reference pattern to script. My recommendation is to share at the content-source level with a strict naming convention, because per-item sharing feels precise on day one and becomes unmanageable by project ten. I would not share per item unless a single source genuinely mixes content with different audiences, in which case the real fix is to split the source. Validate first that the template version is released and the backing image is visible to the project, because those two omissions cause the empty catalog far more often than the policy itself does.

Stand up that one source-to-request round trip in a lab project this week, then come back and script it with the API. If your catalog comes up empty, walk the four-step debug order from the gotcha box before you touch anything else.

References

• Broadcom TechDocs — Add VCF Automation templates to the catalog
• Broadcom TechDocs — Managing policies in VCF Automation
• Broadcom TechDocs — Create a content sharing policy (API)
• vrealize.it — VCF Automation 9 content libraries (Christian Ferber)
• VCF Blog — Self-service private cloud with VCF 9.1

About The Author