In addition to the Cloud Assembly cloud template resources that you use when you create cloud templates, you can also create your own custom resources.

Custom resources are vRealize Orchestrator or extensibility action objects that you manage through vRealize Automation with the lifecycle actions defined in the custom resource. The cloud template service automatically calls up the appropriate vRealize Orchestrator workflows or extensibility actions when the operation associated with a specific lifecycle action is triggered. You can extend the functionality of the resource type by also selecting vRealize Orchestrator workflows or extensibility actions that can be used as day 2 operations.

This use case uses built-in workflows that are provided in the vRealize Orchestrator library. It includes prescriptive values or strings to demonstrate how to perform the process. You can modify them to suit your environment.

For reference purposes, this use case uses a project named DevOpsTesting. You can replace this sample project with any project in your environment.


  • Verify that you configured a vRealize Orchestrator integration. See Configure a vRealize Orchestrator integration in Cloud Assembly.
  • Verify that the workflows that you are using for the create, update, destroy, and day 2 actions exist in vRealize Orchestrator and run successfully from there.
  • In vRealize Orchestrator, locate the resource type used by the workflows. The workflows included in this custom resource must all use the same resource type. In this use case, the resource type is AD:User. For more information on resource type validation, see Custom resource types for Cloud Assembly cloud templates.
  • By using the built-in Active Directory workflows in your vRealize Orchestrator integration, configure an Active Directory server.
  • Verify that you know how to configure and deploy a machine cloud template.


  1. Create an Active Directory custom resource for adding a user in a group.
    This step adds the custom resource to the cloud template design canvas as a resources type.
    1. In Cloud Assembly, select Design > Custom Resources, and click New Custom Resource.
    2. Provide the following values.

      Remember, except for the workflow names, these are sample values.

      Setting Sample Value
      Name AD user

      This is the name that appears in the cloud template resource type palette.

      Resource Type Custom.ADUser

      The resource type must begin with Custom. and each resource type must be unique.

      Although the inclusion of Custom. is not validated in the text box, the string is automatically added if you remove it.

      This resource type is added to the resource type palette so that you can use it in the cloud template.

    3. To enable this resource type in the cloud template resource type list, verify that Activate option is toggled on.
    4. Select the Scope setting that makes the resource type available to any project.
    5. Under Based on, verify that vRO Inventory is selected as the lifecycle action provider.
    6. Select the workflows that define the resource and the day 2 actions.
      Note: The selected day 2 workflows must have an input parameter that is of the same type as the external type. The external type input is not displayed in the day 2 custom form requested by the user, as it is automatically bound to the custom resource.
      Setting Sample Value
      Lifecycle Actions - Create Select the Create a user with a password in an organizational unit workflow.

      If you have multiple vRealize Orchestrator integrations, select the workflow on the integration instance you use to run these custom resources.

      After selecting the workflow, the external type drop-down menu becomes available and is automatically set to AD:User.

      Note: An external source type can be used only once if shared and once per project. In this use case, you are providing the same custom resource for all the projects. It does mean that you cannot use AD:User for any other resource types for all projects. If you have other workflows that require the AD:User type, you must create individual custom resources for each project.
      Lifecycle Actions - Destroy Select the Destroy a user workflow.
      Additional Actions Select the Change a user password workflow.

      On the Add Action window, add a name for the action, such as password_change and click Add.

      To modify the action request form that the user responds to when they request the action, click the icon in the Request Parameters column.
      Note: For additional action workflows, verify that the workflow has a input parameter that is of the same type as the external type.

      In this example, there is no appropriate application of an update workflow. A common example of an update workflow, which makes changes to the provisioned custom resource, is scaling in or scaling out a deployment.

    7. Review the schema key and type values in the Properties tab so that you understand the workflow inputs so that you can configure the inputs in the cloud template.
      The schema lists the required and optional input values defined in the workflow. The required input values are included in the cloud template YAML.

      In the Create a user workflow, accountName, displayName, and ouContainer are required input values. The other schema properties are not required. You can also use the schema to determine where you want to create bindings to other field values, workflows, or actions. Bindings are not included in this use case.

    8. To finish creating your custom resource, click Create.
  2. Create a cloud template that adds the user to a machine when you deploy it.
    1. Select Design > Cloud Templates, and click New from > Blank canvas.
    2. Name the cloud template Machine with an AD user.
    3. Select the DevOpsTesting project and click Create.
    4. Add and configure a vSphere machine.
    5. From the custom resource list on the left of the cloud template design page, drag the AD user resource type onto the canvas.
      Note: You can select the custom resource by either scrolling down and selecting it from the left pane, or searching for it in the Search Resource Types text box. If the custom resource does not appear, click the refresh button next to the Search Resource Types text box.
    6. On the right, edit the YAML code to add the mandatory input values and the password.
      Add an inputs section in the code so that users can provide the name of the users that they are adding. In the following example, some of these values are sample data. Your values might be different.
          type: string
          title: Account name
          encrypted: true   
          type: string
          title: Display name   
          type: string
          title: Password
          encrypted: true 
          type: string
          title: Password
          encrypted: true   
          type: object
          title: AD OU container
          $data: 'vro/data/inventory/AD:OrganizationalUnit'
                  type: string
                  type: string    
    7. In the resources section, add ${input.input-name} code to prompt for the user selection.
          type: Custom.ADUser
              accountName: '${input.accountName}'
              displayName: '${input.displayName}'
              ouContainer: '${input.ouContainer}'
              password: '${input.password}'
              confirmPassword: '${input.confirmPassword}'       
  3. Deploy the cloud template.
    1. On the cloud template designer page, click Deploy.
    2. Enter the Deployment Name AD User Scott.
    3. Select the Cloud Template Version and click Next.
    4. Complete the deployment inputs.
    5. Click Deploy.
  4. Monitor the provisioning request on the Deployments page to ensure that the user is added to Active Directory and that the deployment is successful.

What to do next

When your tested cloud template is working, you can then begin using the AD user custom resource with other cloud templates.