There are several key concepts and requirements, you must be aware of before onboarding a customer organization.

There is a significant amount of configuration involved in setting up IaaS infrastructure, so it can make resources available to end users. In vRealize Automation 7.x, configuration is done with business groups, reservations, and so on.

Many vRealize Automation users have automated onboarding for customers. Automated onboarding includes importing data from other systems and using specific naming conventions.

In vRealize Automation 8.x, the concepts for assigning resources and providing entitlements to content have changed. Now this is done with projects, zones, and flavors. All of these components are listed under the Infrastructure tab of Cloud Assembly.

vRealize Automation 8.x includes a guided setup wizard that guides you through the steps needed to create a cloud account, project, zone, and images by assigning a default configuration. To access this wizard, click Guided Setup on the top-right of the user interface.

While this wizard is useful for getting started, it does not address the organization onboarding scenario as some steps require end user inputs, external integrations and further granularity for some settings.

Configuring the onboarding organization infrastructure is done by automating the creation of the required objects, such as cloud accounts, projects, zones and others. This process can include the entire configuration or only the setting up the components where automation and integration provides more value.

This must be done by creating individual workflows or actions that create each object as needed. Afterwards, these objects are incorporated on a master workflow, that automates the whole process.

This process must follow as specific order, because some objects are dependant on other objects existing first. The order is as follows:

  1. Cloud account
  2. Zone
  3. Project
  4. Flavor mapping
  5. Image mapping
  6. Network profile
  7. Storage profile
Deleting objects must also follow a specific order, because you cannot delete an object that is being used or referenced by another object. This process also has more steps than the deployment workflow as it requires deleting all the objects that can possibly be created by end users, such as deployments, Code Stream pipelines and others. The following is a non-exhaustive list of objects based on deletion order.
  1. Integrations
  2. User operations
  3. Pipelines
  4. Endpoints
  5. Variables
  6. Action runs
  7. Workflow runs
  8. Subscriptions
  9. Extensibility actions
  10. Storage profiles
  11. Drafted cloud templates
  12. Deployed cloud templates
  13. Deployments and resources
  14. Projects
  15. Zones
  16. Cloud accounts
Note: The delete operation might not always finish before the deletion of the resources. It might be necessary, in case of deletion failure because of a dependent resource is not yet deleted, to wait further in the workflow before retrying deletion. Also, to delete a project, you must first patch it to remove the dependencies on all its zones.