## Enforcing ServiceNow-Based Approvals with Rafay

Enterprises often require **explicit approvals** before critical actions can proceed especially when provisioning infrastructure or making configuration changes. With Rafay’s **out-of-the-box (OOB) workflow handlers**, customers can easily integrate with popular ITSM systems such as **ServiceNow (SNOW)**.

This post explains how to configure and use Rafay’s **ServiceNow Workflow Handler** to enforce approval gates.

* * *

### Workflow Handlers in Rafay

Rafay enables platform teams to attach **Workflow Handlers** to key actions as **pre-hooks** or **post-hooks**:

- **Pre-hook Handlers**: Triggered _before_ an action (e.g., pause provisioning until approval is received)
- **Post-hook Handlers**: Triggered _after_ an action (e.g., notify stakeholders after infrastructure (environment) creation)

* * *

### Typical Scenarios

Here are a few use cases where ServiceNow-based approvals come into play:

- Developers request a **vCluster** to test their app before raising a PR
- Platform admins initiate a **Kubernetes upgrade** for a fleet of clusters that requires approval

## Simplifying Blueprint and Add-on Management with Draft Versions

Managing infrastructure at scale demands both agility and precision—especially when it comes to version control. At Rafay, we have long supported versioning for key configuration objects such as **Blueprints** and **Add-ons**, enabling platform teams to roll out changes systematically and maintain operational consistency.

However, as many teams have discovered, managing these versions during testing and validation phases can introduce unnecessary complexity. We are excited to announce a major usability enhancement: **Support for Draft Versions**.

### Why Versioning Matters

Versioning in Rafay’s platform delivers several key advantages:

- **Change Tracking**: Keep a historical record of changes made to Blueprints and Add-ons over time
- **Staged Rollouts**: Gradually deploy updates across environments and clusters to minimize risk
- **Compliance Assurance**: Demonstrate adherence to organizational policies and track Day-2 changes in a controlled way

These capabilities are especially crucial for teams responsible for maintaining secure, production-grade Kubernetes environments

### The Challenge: Version Sprawl During Testing

While versioning is powerful, it has traditionally introduced friction during the **testing and validation phase**. Each time a platform engineer made a minor change to an Add-on or Blueprint, a **new version** needed to be created—even if the version wasn’t production-ready.

This led to:

- **Version fatigue**, with large volumes of partially validated versions cluttering the system
- Increased **manual overhead** and inefficiency for platform teams
- Risk of **accidental usage** of incomplete configurations in downstream projects

## Cluster Blueprints and Drift Detection

Around three years back, we noticed many of our customers struggling with enterprise wide **standardization** of their Kubernetes clusters. Every cluster in their Organization was a **snowflake** and they were looking for a way to enforce that every cluster had a "baseline set of add-ons". This prompted us to develop [Cluster Blueprints](https://docs.rafay.co/blueprints/overview/) which has turned out to be one of the most heavily used features in our platform.

In this blog, we will describe a **superpower** setting in the cluster blueprints feature that we see customers use heavily for their production clusters to **secure against** unplanned drift.