Deployed resources and virtual services can be owned by one or more individual users and/or groups (either local accounts set up in Commander or directory service accounts). They can also be owned by organizations.
When deployed resources and virtual services are deployed as part of a requested service, the ownership of the service applies to its component resources and virtual services.
For Admin Portal users, ownership indicates who is responsible for a resource and virtual service. This is also the case for Service Portal users, but, for Service Portal users, ownership also affects whether users can see resources and virtual services.
User ownership
You can set the following types of ownership for a resource or virtual service to individual users or groups of users:
- Primary Owner — There can only be one Primary Owner per resource or virtual service.
- IT Contact — There can only be one IT Contact per resource or virtual service.
- Owner — An owner that isn't the Primary Owner or IT Contact. There can multiple owners other than Primary Owner and IT Contact can be assigned to a resource or virtual service.
Multiple users or group owners can be assigned ownership for a resource or virtual service, for example, you could assign a Primary Owner, an IT Contact, and another owner, such as a help desk representative. This allows the responsibility for management to be delegated to multiple people.
The first user or group assigned to a resource or virtual service automatically becomes the Primary Owner; any additional owners are automatically assigned as regular owners. However, you can later change an owner's status, but, again, only one Primary Owner and IT Contact are permitted.
Organization ownership
You can also set ownership of resources or virtual services to a single organization. Setting ownership for an organization can allow Service Portal users that are members of that organization to potentially view those resources or virtual services. Organization ownership also allows you to:
- Delegate administrative tasks when an organization has multiple users with permissions to manage an organization's resources.
- Configure resource-based and cost-based quotas for organization members.
Resource visibility in Service Portal
Users can see resources in the Service Portal in the following cases:
- When ownership of a resource or virtual service is specifically assigned to the Service Portal user as an individual user or as a member of a group of users, that resource or virtual service will be visible to them when they sign in.
- When a resource or virtual service is assigned to an organization, the resource or virtual service will be visible to a Service Portal user if they signed in as a member of that organization and the following conditions are met.
Is "Show All Organization Services" permission granted? To see a resource or virtual service... Yes
The organization must be assigned ownership.
or
The user must be Primary, IT Contact, or other owner.
No
The organization must be assigned ownership.
and
The user must be Primary, IT Contact, or other owner.
- A user can also be both an individual owner of a resource or virtual service and belong to a group or organization that owns the resource or virtual service. In this case, the higher level of permissions is always used. For example, if Jose is a member of the group Development, which is the Primary Owner of a particular VM, but Jose is also a regular owner of the VM, Jose will have Primary Owner permissions on that VM.
- By default, only the Manager role provides the "Show All Organization Services" permission. For more information about Service Portal permissions, see Customize Service Portal Roles for Users
Service requests and automatic ownership assignment
If an Admin Portal or Service Portal user requests a service, that user automatically becomes the Primary Owner of the resources or virtual services that are deployed for the service. In addition, if the requester is a Service Portal user that belongs to one or more organizations, the deployed resources or virtual services are also automatically assigned to that organization.
If the Primary Owner specified on the new service request form is not the requester, the deployed service is still assigned to the requester's organization. Also note that to see this service, the primary owner must be a member of the requester's organization. For more information about organizational roles, see Walk-through: Configuring Organizations.
Assign 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.
You can also set ownership information through a completion workflow with a Set Ownership step. However, to ensure that the proper values are set, it is 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.
Assign ownership through workflows
You can configure a completion workflow with a Set Ownership step to set the ownership through a new service or a change request. For more information, see Built-in Commander workflow steps.
When assigning ownership through a change request for an existing virtual service, application stack or auto scaling group, that ownership is automatically inherited by all of its children, and it will override any existing ownership set on child VMs. However, if required, you can add and remove non-primary owners to child VMs.
