Assigning Service Ownership Automatically Through Policies

You can use a Default Ownership policy to automatically assign ownership to new services that are:

  • created through automated and manual deployments

    When there is a Default Ownership targeting the selected destination, Commander applies the policy actions after they are combined with other metadata that may be inherited from a source template and supplied on the request form. For an automated deployment, Commander applies the combined values; for a manual deployment, Commander populates the wizard with the combined values.

  • created outside of Commander (that is, created directly in the cloud account or managed Kubernetes cluster)

A Default Ownership policy reduces the time required to set service ownership, and it ensures that services are always assigned to an owner who can manage them and the services are always visible to organization members.

Using a Default Ownership policy to automatically assign ownership to new services also allows you to track who's incurring service costs, and can be used to assign ownership to costs in public cloud billing data for the purposes of Cost Analytics.

Tip: You can also set ownership information through a completion workflow with a Set Ownership step. To ensure that the proper values are set, it's best to set metadata through policy or through a completion workflow, not both. The metadata values that are applied last are those that take effect.

Configuring Default Ownership policies

Access through:

Configuration > Policies

Available to:

Commander Role of Superuser and Enterprise Admin

Administrator Access Rights

To configure a Default Ownership policy:

  1. On the Configuration page, click Add.
  2. On the Choose a Policy page, select Default Ownership from the list of policies, then click Next.
  3. On the Policy Name/Description page, enter a name for the policy, and an optional description, then click Next.
  4. On the Choose a Target page, from the Target View Type list, choose Infrastructure or Applications.


    • If a service is deployed into a location where multiple policies target the Infrastructure view and the Applications view, the policy targeting the Infrastructure view takes precedence.
    • You can only select managed Kubernetes clusters as targets for an ownership policy through the Applications tree.
  5. To select the target for the policy, navigate to the appropriate infrastructure elements in the Infrastructure or Applications tree on the right, then click Next.

    Caution: Selecting the root Infrastructure or Applications object as the policy target will configure a system-wide policy. This means that the policy will be applied to all current and future Commander cloud accounts and Kubernetes clusters. If you don't want all cloud accounts and Kubernetes clusters to be automatically affected by the policy, instead of selecting Infrastructure or Applications as a target, you should select specific cloud accounts , infrastructure elements within cloud accounts, or Kubernetes clusters.

  6. On the Configure the Policy page, select Enable Policy for the policy to come into effect immediately after you finish configuring it.
  7. From Take Action, select from the options:
    • Notify Only: An alert is created to notify you when the policy has triggered, but no action is taken for the service. See also Subscribing to Policy Alerts.
    • Run [Workflow]: The selected command workflow will be triggered when the policy is triggered.

      The available workflows are listed by target type. You must choose a workflow with a target type that matches the target of the policy, otherwise, the workflow will fail. For example, if the selected workflow's target type is "VM", the workflow will fail if the policy targets a database. A workflow with a target type of "Any Inventory Type" can be run on all service types.


      • If you want to set up a new command workflow at this point, click Add Workflow.
      • A command workflow can't currently be run on Kubernetes namespaces or their child resources. Although you can select a workflow action for a target that includes managed Kubernetes clusters, a workflow won't be run on the clusters' namespaces or their child resources. If a policy targets both non-Kubernetes resources and Kubernetes clusters, the workflow will only be run on the non-Kubernetes resources.
  8. In the Default Owners area, do the following:
    • Select an organization. This will make new services visible to the users in that organization.

      If you also assign ownership to one or more organization members, their organization is automatically selected. For a service to be visible to an organization member, the service must be assigned to the organization.

    • To assign users to the new service, in the Username/Email field, enter a username or email address, then click Add. Each account you add must be a local user or group account set up within Commander or a directory services user or group account.

      The first owner that's added to the policy is automatically assigned as a primary owner; you can change that assignment and the IT contact assignment as required.

  9. If you want to allow children of the targets to have their own instance of the policy, enable For any children of the selected target(s)....

    Enabling this option allows other instances of this policy to be applied to any infrastructure elements and services that are children of the parent infrastructure element you have selected (an override). See Walk-Through: Configuring Organizations for an example of how this override can be useful.

    This option won't affect any managed Kubernetes clusters that are included with a target.
  10. On the Summary page, review the settings and click Finish.