Step 4: Add Entries to Catalog

A service can consist of anything from a single VM to a combination of service components, such as:

  • Multi-cloud templates
  • VM templates
  • Amazon Marketplace AMIs
  • Virtual service templates
  • Cloud templates (CloudFormation and ARM templates)
  • OVA/OVF templates
  • Custom components — used to represent both non-virtual assets (such as a phone) as well as tasks that modify existing assets (such as the installation of a database instance on an existing server)

A service can be predefined (for example, as a vApp in vCenter) or built from individual components in Commander.

Multi-cloud templates are the recommended service catalog building block. With multi-cloud templates, you can create a single service that can be deployed on multiple datacenters, as well as multiple private, public or hybrid clouds. Multi-cloud templates also make it easier to keep the service catalog up to date.

Configuring a Multi-Cloud Template in Commander

Blueprints enable you to configure default settings for each component in your service catalog. You can configure options related to:

  • Infrastructure—such as a name, description, and customization specification
  • Post-provisioning completion workflows, which allow you to install and configure applications
  • Resources—such as CPU count, memory, instance type, storage and networking
  • Custom attributes—metadata such as project code and cost center
  • Groups—such as expiry, rightsizing, power schedule and maintenance groups
  • Third-party integrations—such as Puppet classes and groups

Blueprints also enable you to create component-specific request forms, as shown in the image below.

Service Catalog Blueprint

Design considerations

When adding services to the catalog, consider the following:

  • Will all services be globally available to all organizations, or will you create some custom services for each organization (or group)?
  • Will services be predefined or customizable? Will your catalog contain exactly what your users want, or more generic services that your users can customize at request time? A smaller service catalog that allows user customization of resources, integrations and applications requires less maintenance but can offer the same level of flexibility.
  • Do services need to be fenced (network isolation)?
  • Do deployed services require a defined naming convention? For example, you may want to name all SQL services requested by Development with a pattern such as DEV-SQL-PRD-001, DEV-SQL-PRD-002, and so on.
  • Will users be allowed to change the resource defaults, like adding extra disks, memory or CPUs?
  • If you integrate with Puppet or Chef, do you want to allow users to configure this information on the request form?
  • What custom metadata do you want to attach to services?

Best practices

  • Use multi-cloud templates as the building block for all services, even for single-cloud services, to create an easier-to-maintain service catalog.
  • Use the 80/20 rule for your service catalog: include the services that are most often requested.
  • Offer only those services relevant to each organization and each user by limiting visibility.
  • Name services appropriately.
  • Use meaningful icons to represent services.
  • Categorize services to make them easy to find.
  • Keep templates up-to-date in the service catalog with Commander's template replacement feature.


With the service catalog, you can:

  • Create a service that includes several instances of a database, and install the same base OS for each database by assigning the same completion workflow to each component in the service.
  • Create a service that contains everything a new hire needs, such as a desktop machine and installed software applications.
  • Create a lab service— everything required to set up a software testing lab environment.

Learn more


Add Multi-Cloud Services to the Catalog