- Authoring a template and delivering it are separate jobs. A content source imports authored templates and workflows; content sharing puts them in front of a project.
- The Content Sources page discovers and imports items and shows the counts. Nothing reaches a consumer until it is both imported and shared.
- Sharing is project-scoped: share to all members of a project, or to selected users and groups. The catalog a consumer sees is the sum of what their project was shared.
- VCF 9.1 adds the Project Content Library for sharing artifacts like ISO images, OVF files and VM templates within a project or between selected projects.
- My recommendation: treat content delivery as a pipeline with an owner. The two silent failures are imported-but-not-shared and shared-but-never-resynced.
A team spends a week perfecting a cloud template, and a month later nobody has used it. It is not broken. It was never imported as a content source, and it was never shared to a project, so it does not exist anywhere a consumer can see it. Authoring content and delivering content are two different jobs in VCF Automation, and the second one is where good templates quietly go to die. Part 14 covered publishing a single catalog item; this is the content-source and sharing machinery that feeds the catalog at scale.
Content does not reach the catalog by magic
There is a chain between a template someone authored and a consumer clicking request, and every link has to be in place. A template is authored in Automation Assembler. A content source imports it, discovering and importing the items it contains. The imported content is then shared to one or more projects. Only then does it appear in the catalog for the members of those projects. Break any link and the symptom is identical: an empty or incomplete catalog, with no error to explain why.
Content sources: the import side
A content source connects the catalog to a place where content is authored. When you add one, it discovers the items available and imports them, and the Content Sources page reports the number of discovered and imported items so you can see at a glance whether a source is pulling what you expect. The two content sources you will use most are Automation Assembler cloud templates and VCF Operations Orchestrator workflows. A content source is the unit you re-sync when content changes, which matters: editing the underlying template does not update the catalog until the source is synced again.
# What a content source imports: an Automation Assembler cloud template
formatVersion: 1
inputs:
size:
type: string
enum: [small, medium]
default: small
resources:
app-vm:
type: Cloud.vSphere.Machine
properties:
flavor: '${input.size}'
image: ubuntu-2204Expected result: after the source syncs, this template shows as an imported item, ready to share. Failure mode: you edit the template, the catalog still serves the old version, and you waste an afternoon before remembering the source needs a re-sync. Make re-sync part of your content release process, not a thing you remember to do.
| Content source | What it imports | Authored in |
|---|---|---|
| Cloud templates | VM and application blueprints | Automation Assembler |
| Orchestrator workflows | Workflow-backed catalog items | VCF Operations Orchestrator |
| Other source types | Additional item types per build | Varies; verify in docs |
Content sharing: the delivery side
Importing makes content available to share; it does not show it to anyone. Sharing is what puts an item in a catalog, and it is scoped to the project. You can share content with all users and groups in a project, or with selected users and groups, which is how you keep a sensitive or expensive template in front of only the teams allowed to use it. The catalog any one consumer sees is simply the sum of what their projects have been shared. That is the whole access model, and it is cleaner than it sounds once you stop thinking about a single global catalog and start thinking per project.
The Project Content Library in 9.1
Content sources and sharing handle catalog items. VCF 9.1 adds a different sharing primitive for raw artifacts: the Project Content Library. It exists to share content within a project or between selected projects, and it can hold ISO images, OVF files, VM templates, vApps, scripts, applications and more. The point is to stop every project duplicating the same base images and templates, which reduces both storage and administrator overhead. Think of it as the difference between sharing a finished catalog item and sharing the building blocks teams assemble from.
The Short Version
Treat content delivery as a pipeline with a named owner, not a one-time setup. The chain is author, import as a content source, share to projects, and re-sync on change, and the platform will not warn you when a link is missing. My recommendation is to standardize on a small set of content sources, share broadly for general templates and narrowly for sensitive ones, and keep approved base artifacts in a shared Project Content Library so teams stop duplicating images. When would I do less? For a tiny single-team org, one content source shared to one project is all the ceremony you need. For anything multi-tenant, the discipline of a content release checklist is what keeps the catalog trustworthy. The catalog is a product surface; treat stale or missing content as a defect, because to the consumer that is exactly what it is. When did you last re-sync your content sources, and do you know what is shared to whom?
References
- Add VCF Automation templates to the catalog (Broadcom TechDocs)
- Getting Started with the Self-Service Catalog in VCF Automation (Broadcom TechDocs)
- VCF Automation 9 Content Libraries (vrealize.it)
About The Author
