Integrating Enterprise IT Service Management (ITSM) Workflows with Private Cloud Director

Overview

Enterprise IT teams, especially in regulated industries, need a consistent way to review, approve, and customize provisioning requests from self‑service users. This document outlines a reference architecture that connects an enterprise IT Service Management (ITSM) system to Platform9’s Private Cloud Director (PCD) through a workflow engine. The goal is to give IT centralized approval and extensibility while keeping self‑service fast and predictable.

Many organizations previously used VMware vCenter Orchestrator (now Aria Automation Orchestrator) to add approvals and custom steps to provisioning workflows. With licensing and platform shifts prompting customers to evaluate alternatives, this architecture shows how to achieve the same (or greater) control and flexibility using open, portable components.

Architecture

This solution uses Platform9’s Private Cloud Director (PCD) as the private cloud platform, ServiceNow as the ITSM (IT Service Management) system, and Apache Airflow as the workflow manager to enable extensibility and customization.

1. Platform9 Private Cloud Director (PCD): A private cloud platform offering VMware-like management for virtualized environments. PCD provides APIs for authentication, compute, storage , and networking, enabling integration with automation tools such as Terraform and Ansible.
2. ServiceNow (ITSM): ServiceNow provides a self‑service portal and catalog that end users can browse to request virtual infrastructure. The catalog can be extended with items that represent resources offered through PCD. ServiceNow includes its own workflow engine; in this design we delegate orchestration to Airflow for maximum flexibility while still using ServiceNow for intake, validation, and initial approvals.
3. Apache Airflow (workflow engine): Apache Airflow is a workflow manager used by many organizations to coordinate multi‑step processes. Workflows are defined as Directed Acyclic Graphs (DAGs) that sequence individual tasks with conditionals, serial/parallel execution, and retries. This makes it easy to add custom steps before or after provisioning.

Sample Workflow

This section outlines a sample provisioning workflow:

1. A user opens the ServiceNow catalog and initiates a provisioning request.
2. The catalog queries the private cloud environment and displays available resources (VM images, instance sizes, networks).
3. The user submits the request, which runs through ServiceNow’s validation rules.
4. If validated, the request is routed to an approver.
5. Upon approval, provisioning completes, and the user receives an email with resource details.
6. If denied, the user is notified by email.

Airflow Orchestration

The diagram below illustrates the integration flow between ServiceNow, Airflow, and Private Cloud Director.

1. Open the ServiceNow catalog item: When the user opens the catalog form, an OnLoad client script calls a small Flask application (a lightweight Python web framework). The Flask app reads a preconfigured clouds.yaml file and returns a list of available PCD environments. The form populates a “Cloud” dropdown with these options.

2. Select a cloud and discover options: When the user chooses a cloud, an OnChange client script calls the Flask app again (this time with the selected cloud) to fetch available:

   • Images (virtual machine templates),
   • Flavors (predefined compute sizes, similar to T‑shirt sizes), and
   • Networks (available virtual networks). The form updates these fields dynamically so the user can select the appropriate image, size, and network.

3. Submit the request and run initial approval: The user clicks Order Now. ServiceNow runs its standard validation rules and routes the request for approval based on your organization’s policies.

4. Send the request to Airflow (DAG trigger): After approval in ServiceNow, a Business Rule collects the form data, builds a JSON payload, and triggers an Airflow DAG via the Airflow REST API. The call includes appropriate headers.

5. Run the Airflow workflow and capture a final approval: The Airflow DAG receives the payload and begins task execution. As part of the DAG, an approval email is sent to a designated administrator with Approve and Deny action links. This allows you to add a final approval step outside of ServiceNow if required (for example, a platform owner or security reviewer).

6. Provision or notify

   • If approved in Airflow: the DAG provisions the requested virtual machine (VM) in the specified PCD environment and sends a success email to the requester with the resource details.
   • If denied in Airflow: the DAG sends a denial email to the requester and stops the workflow.