> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/internal-developer-portal/use-idp/self-service-workflows/workflow-library/available-workflows.md). # Available Workflows Browse every pre-built Workflow in the Harness IDP Workflow Library, grouped by category, with the developer inputs, pipeline steps, and admin inputs for each one. The Workflow Library ships the Workflows listed below. Each one installs as a Workflow paired with the backing pipelines it needs. Go to [Install a workflow from the library](/internal-developer-portal/use-idp/self-service-workflows/workflow-library/install-a-workflow.md) to install any of them. The library grows over time, so the **Library** tab in your account is the authoritative list for what is available to you right now. Use the category filters on the left of that tab to narrow the list, or select **All Library** to see everything. To check a Workflow in your own account, open it in the **Library** tab and select **Preview & Install**. The preview page lists what you set during install under **Configure at install time**, and what must already be in place under **Prerequisites**. Select **Preview Now** to see the full Workflow and the form developers fill in. *** ## Deployment workflows Pipeline execution, rollback, day-2 cluster operations, incident management, and issue creation. | Workflow | What it does | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | [**Manage PagerDuty Incident**](#manage-pagerduty-incident) | Triggers, acknowledges, or resolves a PagerDuty incident through the Events API v2. | | [**Kubernetes Day-2 Ops**](#kubernetes-day-2-ops) | Runs day-2 `kubectl` verbs against a cluster, including get, list, describe, logs, scale, restart, and delete. | | [**Create ServiceNow Incident**](#create-servicenow-incident) | Creates a ServiceNow incident using the native ServiceNowCreate step. | | [**Trigger CI-CD Pipeline**](#trigger-ci-cd-pipeline) | Triggers an existing Harness pipeline, with optional runtime inputs. | | [**Rollback Service**](#rollback-service) | Rolls a service back to a previous known-good version. | | [**Create GitHub Issue**](#create-github-issue) | Creates a GitHub issue from the developer portal without direct GitHub access. | ### Manage PagerDuty Incident Lets developers trigger, acknowledge, or resolve a PagerDuty incident directly from the developer portal. {% hint style="warning" %} **Prerequisites** * A PagerDuty service with an Events API v2 integration configured. * The Harness delegate must have outbound HTTPS access to `events.pagerduty.com`. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The action to take: trigger, acknowledge, or resolve. * For trigger: the incident summary, severity, and source. * For acknowledge or resolve: the `dedup_key` of the incident. #### What the pipeline does The pipeline performs the following steps: 1. Calls the PagerDuty Events API v2 with the selected action, using a native HTTP step. 2. Returns the incident status and the `dedup_key`. #### Admin inputs | Field | Details | | -------------------------------- | ---------------------------------------------------------------------------------------------------- | | **PagerDuty Routing Key Secret** | Harness secret holding the Events API v2 integration (routing) key for the target PagerDuty service. | ### Kubernetes Day-2 Ops Lets developers run common `kubectl` operations on a Kubernetes cluster without direct cluster access or `kubectl` configured locally. {% hint style="warning" %} **Prerequisites** * A Harness delegate with `kubectl` installed and RBAC permissions on the target cluster. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The action: get, list, describe, logs, scale, restart, or delete. * The resource type and name. * A namespace (optional). #### What the pipeline does The pipeline performs the following steps: 1. For a delete, waits for approval from the **Approver User Group** through a HarnessApproval step. 2. Runs the `kubectl` command on the delegate that matches the **Kubernetes Delegate Selector**. That delegate already has access to the cluster. 3. Returns the command output. #### Admin inputs | Field | Details | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Kubernetes Delegate Selector** | Tag or selector of a delegate with `kubectl` access to the target cluster. Match the selector of a Kubernetes connector that uses `InheritFromDelegate`, for example `my-cluster-delegate`. | | **Approver User Group** | Reference of the user group that must approve `kubectl delete` operations. | ### Create ServiceNow Incident Lets developers create ServiceNow incidents directly from the developer portal, without ServiceNow console access. {% hint style="warning" %} **Prerequisites** * A ServiceNow instance with the Incident table accessible. * The Harness delegate must have network access to the ServiceNow instance. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * A short description. * A description. * The urgency: 1-High, 2-Medium, or 3-Low. #### What the pipeline does The pipeline performs the following steps: 1. Creates the incident using the native ServiceNowCreate step. 2. Returns the incident number and `sys_id`. #### Admin inputs | Field | Details | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | **ServiceNow Connector** | Harness ServiceNow connector with permission to create incidents. The connector carries the instance URL and credentials. | ### Trigger CI-CD Pipeline Lets developers trigger any existing Harness pipeline directly from the developer portal, without access to the Harness CI/CD UI. {% hint style="warning" %} **Prerequisites** * The target pipelines must exist and accept the runtime inputs provided. * The API key must have pipeline execute permission in the target project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The identifier of the pipeline to trigger (optional). If the developer leaves it blank, the Workflow triggers the **Default Pipeline Identifier** set at install. * Runtime inputs as YAML (optional). #### What the pipeline does The pipeline performs the following steps: 1. Calls the Harness execute API through a native HTTP step. 2. Returns the execution ID of the triggered run. #### Admin inputs | Field | Details | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Default Pipeline Identifier** | Identifier of the pipeline to trigger when the developer leaves the pipeline identifier blank. Developers can override it in the form. | | **Harness Base URL** | Base URL of your Harness cluster, for example `https://app.harness.io`. | | **Harness API Key Secret** | Harness secret holding an API key or token with execute permission on the target pipelines. | ### Rollback Service Lets developers roll a service back to a previous known-good version, with an approval gate for production. The Workflow does not perform the rollback itself. It triggers an existing rollback or redeploy pipeline that you select at install. {% hint style="warning" %} **Prerequisites** * An existing rollback or redeploy pipeline configured for the target service. * The API key must have pipeline execute permission in the target project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The service name. * The environment. * The target version. * The reason for the rollback. #### What the pipeline does The pipeline performs the following steps: 1. For a production environment, waits for approval from the **Approver User Group** through a HarnessApproval step. 2. Triggers the pipeline set in **Rollback Pipeline Identifier** through the Harness execute API, passing runtime inputs. 3. Returns the execution ID. #### Admin inputs | Field | Details | | -------------------------------- | -------------------------------------------------------------------------------------------------- | | **Approver User Group** | Reference of the user group that approves production rollbacks. | | **Rollback Pipeline Identifier** | Identifier of the existing pipeline that performs the actual rollback or redeploy for the service. | | **Harness Base URL** | Base URL of your Harness cluster, for example `https://app.harness.io`. | | **Harness API Key Secret** | Harness secret holding an API key or token with execute permission on the rollback pipeline. | ### Create GitHub Issue Lets developers create GitHub issues directly from the developer portal, without direct GitHub access. {% hint style="warning" %} **Prerequisites** * The GitHub connector token must have the `issues:write` scope (fine-grained) or `repo` scope (classic). * The Harness delegate must have outbound HTTPS access to `api.github.com`. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * A title. * A body. * Labels. * Assignees. #### What the pipeline does The pipeline performs the following steps: 1. Creates the issue using the GitHub Issues API. 2. Returns the issue URL and number. #### Admin inputs | Field | Details | | ---------------------------- | --------------------------------------------------------------------------------------------------- | | **GitHub Connector** | GitHub connector with API access enabled and `issues:write` permission in the target repos. | | **GitHub Token Secret** | Harness secret holding a GitHub token with `issues:write` (fine-grained) or `repo` (classic) scope. | | **Default Repository Owner** | GitHub org or user that owns the repos. | *** ## Governance workflows Dashboards and alert rules. | Workflow | What it does | | --------------------------------------------------------- | ------------------------------------------------------------------------------ | | [**Create Alerts**](#create-alerts) | Creates a Grafana alert rule using the Grafana provisioning HTTP API. | | [**Create Grafana Dashboard**](#create-grafana-dashboard) | Creates a Grafana dashboard from a dashboard model using the Grafana HTTP API. | ### Create Alerts Lets developers create Grafana alert rules directly from the developer portal, without Grafana admin access. {% hint style="warning" %} **Prerequisites** * Grafana 9 or later with the provisioning API enabled. * The Harness delegate must have network access to the Grafana instance. * The alert-rule JSON must reference a valid `folderUID` that exists in Grafana. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * A full Grafana alert-rule JSON model. The model must include `title` and `folderUID`. #### What the pipeline does The pipeline performs the following steps: 1. Sends the alert rule to the Grafana provisioning API in a POST request. 2. Returns a direct link to the created alert in Grafana. #### Admin inputs | Field | Details | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | **Grafana URL** | Base URL of your Grafana instance, for example `https://grafana.example.com`. The pipeline appends `/api/v1/provisioning/alert-rules`. | | **Grafana API Token Secret** | Harness secret holding a Grafana service account token with alert-rule write access. | ### Create Grafana Dashboard Lets developers create Grafana dashboards from an exported JSON model, without Grafana admin access. {% hint style="warning" %} **Prerequisites** * Grafana 9 or later with the HTTP API enabled. * The Harness delegate must have network access to the Grafana instance. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * An exported dashboard JSON model that includes a title. To get one, export an existing dashboard in Grafana from **Share** > **Export** > **JSON**. * Whether to overwrite an existing dashboard with the same title. #### What the pipeline does The pipeline performs the following steps: 1. Sends the model to the Grafana `/api/dashboards/db` endpoint in a POST request, using a native HTTP step. 2. Returns the UID and direct URL of the created dashboard. #### Admin inputs | Field | Details | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Grafana URL** | Base URL of your Grafana instance, for example `https://grafana.example.com`. The pipeline appends `/api/dashboards/db`. | | **Grafana API Token Secret** | Harness secret holding a Grafana service account token or API key with dashboard write access. | *** ## Infrastructure workflows Cloud and platform resources provisioned with Terraform in a Harness Custom stage. | Workflow | What it does | | --------------------------------------------------------- | -------------------------------------------------------------------- | | [**Provision RDS Database**](#provision-rds-database) | Provisions an RDS database with Terraform. | | [**Create Kafka Topic**](#create-kafka-topic) | Provisions a Kafka topic with Terraform. | | [**Create S3 Bucket**](#create-s3-bucket) | Provisions AWS S3 infrastructure with Terraform. | | [**Create EKS Cluster**](#create-eks-cluster) | Provisions an EKS cluster with Terraform. | | [**Spin Up EC2 Instance**](#spin-up-ec2-instance) | Provisions EC2 infrastructure with Terraform. | | [**Provision Cloud SQL**](#provision-cloud-sql) | Provisions a Cloud SQL instance with Terraform. | | [**Spin Up GCE VM**](#spin-up-gce-vm) | Provisions a GCE virtual machine with Terraform. | | [**Create PubSub Topic**](#create-pubsub-topic) | Provisions a PubSub topic with Terraform. | | [**Create GKE Cluster**](#create-gke-cluster) | Provisions a GKE cluster with Terraform. | | [**Create GCS Bucket**](#create-gcs-bucket) | Provisions a GCS bucket with Terraform. | | [**Create SQS Queue**](#create-sqs-queue) | Provisions an AWS SQS queue with Terraform. | | [**Create GKE Cluster (WIF)**](#create-gke-cluster-wif) | Provisions a GKE cluster using Workload Identity Federation. | | [**Create GCS Bucket (WIF)**](#create-gcs-bucket-wif) | Provisions a GCS bucket using Workload Identity Federation. | | [**Create PubSub Topic (WIF)**](#create-pubsub-topic-wif) | Provisions a PubSub topic using Workload Identity Federation. | | [**Spin Up GCE VM (WIF)**](#spin-up-gce-vm-wif) | Provisions a GCE virtual machine using Workload Identity Federation. | | [**Provision Cloud SQL (WIF)**](#provision-cloud-sql-wif) | Provisions a Cloud SQL instance using Workload Identity Federation. | ### Shared admin inputs Most Infrastructure Workflows ask for the same admin inputs. Each Workflow entry below lists the fields it uses, and this table explains the shared ones. | Field | Used by | Details | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Every Infrastructure Workflow except Create Kafka Topic | Harness Git connector pointing at the repo that holds the Terraform/OpenTofu module. For the Workflows without **(WIF)** in the name, point it at a copy of the `terraform-examples/` folder from `ootbWorkflowLibrary`, or at your own repo with the same folder layout. Each entry below names the module folder. | | **Terraform Repo Branch (optional)** | Every Infrastructure Workflow except Create Kafka Topic | Branch of the Terraform repo to fetch the module from. The field is pre-filled with `main`. | | **AWS Access Key ID Secret** and **AWS Secret Access Key Secret** | Provision RDS Database, Create S3 Bucket, Create EKS Cluster, Spin Up EC2 Instance, Create SQS Queue | Harness secrets holding the AWS access key ID and the AWS secret access key. Select the secrets. The pipeline resolves them with `secrets.getValue()` automatically, so you do not type an expression. | | **GCP Service Account JSON Secret** | Provision Cloud SQL, Spin Up GCE VM, Create PubSub Topic, Create GKE Cluster, Create GCS Bucket | Harness secret holding a GCP service account JSON key. The pipeline resolves it with `secrets.getValue()` automatically, so you do not type an expression. | | **GCP Connector (Workload Identity / IAM)** | Create GKE Cluster (WIF), Create GCS Bucket (WIF), Create PubSub Topic (WIF), Spin Up GCE VM (WIF), Provision Cloud SQL (WIF) | Harness GCP connector that uses Workload Identity Federation or a delegate-attached service account. These variants do not use a static service account JSON key. | | **Approver User Group** | Provision RDS Database, Create EKS Cluster, Provision Cloud SQL, Create GKE Cluster, Create GKE Cluster (WIF), Provision Cloud SQL (WIF) | Harness user group identifier, for example `account._account_all_users` or a scoped group, whose members can approve the Terraform apply for these expensive or slow resources. | {% hint style="info" %} To use IAM role-based authentication for the AWS Workflows, such as instance profiles or IRSA, modify the pipeline after installation to remove the AWS key environment variables so Terraform uses the delegate's IAM role. For the GCP Workflows, install the **(WIF)** variant if you prefer Workload Identity Federation over a static service account JSON key. {% endhint %} ### Provision RDS Database Lets developers provision an RDS database through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions an RDS instance. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The DB identifier. * The region. * The engine: PostgreSQL, MySQL, or MariaDB. * The instance class. * The storage size. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan. 2. Waits for approval from the **Approver User Group**, since database creation is expensive and slow. 3. Applies using the native TerraformApply step. 4. Returns the endpoint and port. #### Admin inputs | Field | Details | | ------------------------------------ | ----------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/rds-database`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **AWS Access Key ID Secret** | Harness secret holding the AWS access key ID. The key needs permission to create RDS instances. | | **AWS Secret Access Key Secret** | Harness secret holding the AWS secret access key. | | **Approver User Group** | User group whose members can approve the Terraform apply. | ### Create Kafka Topic Provisions a Kafka topic by running Terraform/OpenTofu from a ShellScript step inside a Harness Custom stage, so no CD or IaCM license is required. {% hint style="warning" %} **Prerequisites** * A Harness delegate with `git` installed. * A `tofu` or `terraform` binary on the delegate. The pipeline downloads one automatically if it is absent. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The Terraform repo URL. * The working directory. * Terraform variables, such as the broker list, topic name, and partitions. * Whether to plan or provision (apply). #### What the pipeline does The pipeline performs the following steps: 1. Clones the Terraform repo using the **Git Token (Secret)**. 2. Runs a Terraform/OpenTofu plan, or an apply if the developer chose to provision. Terraform's Kafka provider uses the Kafka SASL secrets. #### Admin inputs | Field | Details | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Git Token (Secret)** | Harness secret holding a Git token used to clone the Terraform repository. For a public repo, use a secret with any placeholder value. | | **Kafka SASL Username (Secret)** | Harness secret holding the Kafka SASL username used by Terraform's Kafka provider. For a PLAINTEXT cluster, use a secret with any placeholder value. | | **Kafka SASL Password (Secret)** | Harness secret holding the Kafka SASL password used by Terraform's Kafka provider. For a PLAINTEXT cluster, use a secret with any placeholder value. | ### Create S3 Bucket Lets developers provision an S3 bucket through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions an S3 bucket. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The bucket name. * The region. #### What the pipeline does The pipeline performs the following steps: 1. Validates the bucket name format. 2. Runs a Terraform plan and apply using the native TerraformApply step. 3. Returns the bucket URL and ARN. #### Admin inputs | Field | Details | | ------------------------------------ | -------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/s3-bucket`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **AWS Access Key ID Secret** | Harness secret holding the AWS access key ID. The key needs permission to create S3 buckets. | | **AWS Secret Access Key Secret** | Harness secret holding the AWS secret access key. | ### Create EKS Cluster Lets developers provision an EKS cluster through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions an EKS cluster. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The cluster name. * The region. * The Kubernetes version. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan. 2. Waits for approval from the **Approver User Group**, since cluster creation is expensive and slow. 3. Applies using the native TerraformApply step. 4. Returns the cluster name, the endpoint, and an `aws eks update-kubeconfig` command. EKS cluster creation can take 15 to 20 minutes. The pipeline timeout is set to 45 minutes. #### Admin inputs | Field | Details | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/eks-cluster`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **AWS Access Key ID Secret** | Harness secret holding the AWS access key ID. The key needs permission to create EKS clusters, VPCs, and IAM roles. The pipeline injects the keys as environment variables. | | **AWS Secret Access Key Secret** | Harness secret holding the AWS secret access key. | | **Approver User Group** | User group whose members can approve the Terraform apply. | ### Spin Up EC2 Instance Lets developers spin up an EC2 instance through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions an EC2 instance. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The instance name. * The region. * The instance type. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. The latest Amazon Linux 2 AMI is resolved automatically at apply time. 2. Returns the instance ID, the public IP, and an SSH command. #### Admin inputs | Field | Details | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/ec2-instance`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **AWS Access Key ID Secret** | Harness secret holding the AWS access key ID. The key needs permission to create EC2 instances and VPC resources. | | **AWS Secret Access Key Secret** | Harness secret holding the AWS secret access key. | ### Provision Cloud SQL Lets developers provision a Cloud SQL instance through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a Cloud SQL instance. * A Harness delegate with Terraform/OpenTofu capabilities. * The Cloud SQL Admin API must be enabled in the target GCP project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The instance name. * The region. * The database version: PostgreSQL or MySQL. * The tier. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan. 2. Waits for approval from the **Approver User Group**, since database creation is expensive and slow. 3. Applies using the native TerraformApply step. 4. Returns the connection name, the instance IP, and the database username. #### Admin inputs | Field | Details | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/cloud-sql`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Service Account JSON Secret** | Harness secret holding the GCP service account JSON key. The service account needs permission to create Cloud SQL instances. | | **Approver User Group** | User group whose members can approve the Terraform apply. | ### Spin Up GCE VM Lets developers spin up a GCE VM through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a GCE VM. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The instance name. * The zone. * The machine type. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. 2. Returns the instance ID, the external IP, and an SSH command. #### Admin inputs | Field | Details | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/gce-vm`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Service Account JSON Secret** | Harness secret holding the GCP service account JSON key. The service account needs permission to create Compute Engine instances. | ### Create PubSub Topic Lets developers create a GCP Pub/Sub topic through a self-service form, without GCP console access. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a Pub/Sub topic. * A Harness delegate with Terraform/OpenTofu capabilities. * The Pub/Sub API must be enabled in the target GCP project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The topic name. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. 2. Returns the topic ID. #### Admin inputs | Field | Details | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/pubsub-topic`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Service Account JSON Secret** | Harness secret holding the GCP service account JSON key. The service account needs permission to create Pub/Sub topics. | ### Create GKE Cluster Lets developers provision a GKE Autopilot cluster on GCP through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a GKE cluster. * A Harness delegate with Terraform/OpenTofu capabilities. * The GKE API must be enabled in the target GCP project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The cluster name. * The region. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan. 2. Waits for approval from the **Approver User Group**, since cluster creation is expensive and slow. 3. Applies using the native TerraformApply step. 4. Returns the cluster name and a `gcloud get-credentials` command. Cluster creation can take 10 to 15 minutes. The pipeline timeout is set to 45 minutes. #### Admin inputs | Field | Details | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/gke-cluster`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Service Account JSON Secret** | Harness secret holding the GCP service account JSON key. The service account needs permission to create GKE clusters, VPCs, and IAM bindings. | | **Approver User Group** | User group whose members can approve the Terraform apply. | ### Create GCS Bucket Lets developers provision a GCS bucket through a self-service form, without GCP console access or Terraform expertise. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a GCS bucket. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The bucket name. * The region. #### What the pipeline does The pipeline performs the following steps: 1. Validates the bucket name format. 2. Runs a Terraform plan and apply using the native TerraformApply step. 3. Returns the bucket URL. #### Admin inputs | Field | Details | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/gcs-bucket`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Service Account JSON Secret** | Harness secret holding the GCP service account JSON key. The service account needs permission to create and manage GCS buckets. | ### Create SQS Queue Lets developers provision an SQS queue through a self-service form. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions an SQS queue. * A Harness delegate with Terraform/OpenTofu capabilities. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The queue name. * The region. * Whether to use FIFO ordering. * Whether to create a dead-letter queue. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. 2. Returns the queue URL and ARN. #### Admin inputs | Field | Details | | ------------------------------------ | -------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the module at `terraform-examples/sqs-queue`. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **AWS Access Key ID Secret** | Harness secret holding the AWS access key ID. The key needs permission to create SQS queues. | | **AWS Secret Access Key Secret** | Harness secret holding the AWS secret access key. | ### Create GKE Cluster (WIF) The Workload Identity Federation (WIF) variant of [Create GKE Cluster](#create-gke-cluster). It authenticates with WIF instead of a static service account JSON key. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a GKE cluster. * A Harness delegate with Terraform/OpenTofu capabilities and `TERRAFORM_TASK_NG_V10` support. * Workload Identity Federation configured between the delegate's identity provider and GCP. * The GKE API enabled in the target GCP project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The cluster name. * The region. * The Kubernetes version. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan. 2. Waits for approval from the **Approver User Group**, since cluster creation is expensive and slow. 3. Applies using the native TerraformApply step. 4. Returns the cluster name, the endpoint, and a `gcloud get-credentials` command. GKE cluster creation can take 10 to 15 minutes. The pipeline timeout is set accordingly. #### Admin inputs | Field | Details | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the GKE module. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Connector (Workload Identity / IAM)** | GCP connector that uses WIF, with an OIDC provider bound to a GCP service account, or a delegate-attached service account. The service account needs permission to create GKE clusters, VPCs, and IAM bindings. | | **Approver User Group** | User group whose members can approve the Terraform apply. | ### Create GCS Bucket (WIF) The Workload Identity Federation (WIF) variant of [Create GCS Bucket](#create-gcs-bucket). The delegate's identity is federated to GCP through an OIDC provider, instead of using a static service account JSON key. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a GCS bucket. * A Harness delegate with Terraform/OpenTofu capabilities and `TERRAFORM_TASK_NG_V10` support. * Workload Identity Federation configured between the delegate's identity provider and GCP. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The bucket name. * The region. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. 2. Returns the bucket URL. #### Admin inputs | Field | Details | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the GCS bucket module. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Connector (Workload Identity / IAM)** | GCP connector that uses WIF, with an OIDC provider bound to a GCP service account, or a delegate-attached service account. The service account needs permission to create GCS buckets. | ### Create PubSub Topic (WIF) The Workload Identity Federation (WIF) variant of [Create PubSub Topic](#create-pubsub-topic). It authenticates with WIF instead of a static service account JSON key. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a Pub/Sub topic. * A Harness delegate with Terraform/OpenTofu capabilities and `TERRAFORM_TASK_NG_V10` support. * Workload Identity Federation configured between the delegate's identity provider and GCP. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The topic name. * The region. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. 2. Returns the topic name and ID. #### Admin inputs | Field | Details | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the Pub/Sub module. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Connector (Workload Identity / IAM)** | GCP connector that uses WIF, with an OIDC provider bound to a GCP service account, or a delegate-attached service account. The service account needs permission to create Pub/Sub topics. | ### Spin Up GCE VM (WIF) The Workload Identity Federation (WIF) variant of [Spin Up GCE VM](#spin-up-gce-vm). It authenticates with WIF instead of a static service account JSON key. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a GCE VM. * A Harness delegate with Terraform/OpenTofu capabilities and `TERRAFORM_TASK_NG_V10` support. * Workload Identity Federation configured between the delegate's identity provider and GCP. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The instance name. * The zone. * The machine type. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan and apply using the native TerraformApply step. 2. Returns the instance name, the external IP, and an SSH command. #### Admin inputs | Field | Details | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the GCE module. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Connector (Workload Identity / IAM)** | GCP connector that uses WIF, with an OIDC provider bound to a GCP service account, or a delegate-attached service account. The service account needs permission to create Compute Engine instances. | ### Provision Cloud SQL (WIF) The Workload Identity Federation (WIF) variant of [Provision Cloud SQL](#provision-cloud-sql). It authenticates with WIF instead of a static service account JSON key. {% hint style="warning" %} **Prerequisites** * A Git repository containing a Terraform module that provisions a Cloud SQL instance. * A Harness delegate with Terraform/OpenTofu capabilities and `TERRAFORM_TASK_NG_V10` support. * Workload Identity Federation configured between the delegate's identity provider and GCP. * The Cloud SQL Admin API enabled in the target GCP project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The project ID. * The instance name. * The region. * The database version. * The machine tier. #### What the pipeline does The pipeline performs the following steps: 1. Runs a Terraform plan. 2. Waits for approval from the **Approver User Group**, since database creation is expensive and slow. 3. Applies using the native TerraformApply step. 4. Returns the connection name and IP address. #### Admin inputs | Field | Details | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terraform Repo Git Connector** | Git connector for the repo that holds the Cloud SQL module. | | **Terraform Repo Branch (optional)** | Branch to fetch the module from. Pre-filled with `main`. | | **GCP Connector (Workload Identity / IAM)** | GCP connector that uses WIF, with an OIDC provider bound to a GCP service account, or a delegate-attached service account. The service account needs permission to create Cloud SQL instances. | | **Approver User Group** | User group whose members can approve the Terraform apply. | *** ## Service lifecycle workflows Creating new services and repositories, and managing feature flags. | Workflow | What it does | | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | [**Create GitHub Repository**](#create-github-repository) | Creates a GitHub repository, seeds it with an initial README, and optionally applies branch protection. | | [**Scaffold Microservice**](#scaffold-microservice) | Creates a new microservice from a template, including the Git repository, a CI pipeline, a catalog entry, and a Slack notification. | | [**Toggle Feature Flag**](#toggle-feature-flag) | Creates a Harness Feature Flag, toggles it using a flag configuration, and verifies the resulting state. | ### Create GitHub Repository Lets developers create a GitHub repository directly from the developer portal, without GitHub org admin access. Supports both organization and personal accounts. {% hint style="warning" %} **Prerequisites** * The GitHub connector token must have the `repo` scope, or `admin:org` for org-level creation. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The repo name. * The visibility: public or private. * A description (optional). * The GitHub org (optional). If the developer does not specify one, the repo is created in the **Default GitHub Org** set at install. #### What the pipeline does The pipeline performs the following steps: 1. Creates the repository using the IDP CreateRepo step, which runs on Harness Cloud. 2. Seeds an initial README using the **GitHub Token Secret**. A new repo has no commits or branches until something is pushed. 3. If **Enable Branch Protection on Create** is `true`, applies a minimal branch protection rule that requires 1 PR approval on the default branch. 4. Returns the repository URL. #### Admin inputs | Field | Details | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **GitHub Connector** | GitHub connector with API access enabled that can create repos in the target org. | | **Default GitHub Org** | GitHub org to create repos in when the developer does not specify one. | | **Personal GitHub Account** | Set to `true` if the connector token belongs to a personal user account, in which case repos are created through `/user/repos`. Set to `false` for an organization. This value is fixed per install, and developers cannot toggle it per run. | | **GitHub Token Secret** | Harness secret holding a GitHub token with **Contents** and **Administration** permissions (fine-grained) or `repo` scope (classic). Always used to seed the initial README, and also used for branch protection if enabled. | | **Enable Branch Protection on Create** | Set to `true` to apply a minimal branch protection rule (require 1 PR approval) to the default branch right after the README is seeded. | ### Scaffold Microservice Lets developers scaffold a brand-new microservice from a language or framework template directly from the developer portal. {% hint style="warning" %} **Prerequisites** * A Cookiecutter-compatible template repository for each supported language or framework. * The Git connector token must have permission to create repos and push code. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The service name. * The language or framework. * The owning team. * The repo org. * The visibility. #### What the pipeline does The pipeline performs the following steps: 1. Renders a Cookiecutter template. 2. Creates the Git repo and pushes the rendered code. 3. Writes a `catalog-info.yaml` and registers the new entity in the IDP catalog. 4. Creates a CI pipeline declaratively. 5. Notifies the owning Slack channel. #### Admin inputs | Field | Details | | ----------------------------- | ----------------------------------------------------------------------------------------------------- | | **Git Connector** | Git connector with org-level write access for repo creation. | | **Cookiecutter Template URL** | Cookiecutter template URL, keyed by language. For example, a GitHub repo with the template structure. | ### Toggle Feature Flag Lets developers create a boolean Harness Feature Flag and toggle it on or off directly from the developer portal. {% hint style="warning" %} **Prerequisites** * The Harness Feature Flags module enabled in the account. * The API key must have CF Admin permissions in the target project. {% endhint %} #### Developer inputs The Workflow collects the following inputs from the developer: * The flag name and identifier. * The target environment. * The desired state: on or off. #### What the pipeline does The pipeline performs the following steps: 1. Creates the flag through the Feature Flags admin API. 2. Toggles the flag using the native FlagConfiguration step (`SetFeatureFlagState`). 3. Verifies the final state. If the Feature Flags project or environment does not exist yet, the pipeline bootstraps it automatically. #### Admin inputs | Field | Details | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Harness Base URL** | Base URL of your Harness cluster, for example `https://app.harness.io`. | | **Harness API Key Secret** | Harness secret holding an API key that can create and read Feature Flags in the org and project where you install the Workflow. | *** ## Team people workflows Onboarding and access management. | Workflow | What it does | | ------------------------------------------- | ------------------------------------------------------------------------------- | | [**Onboard Developer**](#onboard-developer) | Adds a new developer to a GitHub organization and team, after manager approval. | ### Onboard Developer Lets managers or leads onboard a new developer into a GitHub organization directly from the developer portal. Supports both github.com and GitHub Enterprise Server (GHES). {% hint style="warning" %} **Prerequisites** * The GitHub token must have `write:org` permission to invite members to the target org. * The Harness delegate must have network access to the GitHub API endpoint. {% endhint %} #### Developer inputs The manager or lead running the Workflow provides the following about the new developer: * The developer's email. * The developer's GitHub username. * The GitHub org. * The team. * The access level. #### What the pipeline does The pipeline performs the following steps: 1. Requests manager approval from the **Approver User Group** through a HarnessApproval step. 2. Adds the developer to the GitHub org using the GitHub API. 3. Returns the membership state. #### Admin inputs | Field | Details | | ----------------------- | ------------------------------------------------------------------------------------------------------ | | **Approver User Group** | Reference of the user group of team managers who approve onboarding. | | **GitHub API URL** | `https://api.github.com` for github.com, or `https:///api/v3` for GitHub Enterprise Server. | | **GitHub Token Secret** | Harness secret holding a GitHub token with `admin:org` (`write:org`) scope, used to add org members. | *** ## Next steps Explore the following pages next: * Go to [Install a Workflow](/internal-developer-portal/use-idp/self-service-workflows/workflow-library/install-a-workflow.md) to install a Workflow from the library. * Go to [Customize an Installed Workflow](/internal-developer-portal/use-idp/self-service-workflows/workflow-library/customize-an-installed-workflow.md) to change a Workflow after you install it.