IDP Workflow Patterns and Examples

Practical IDP workflow patterns and examples for common platform team use cases

Workflows turn Harness pipelines into self-service actions in the Internal Developer Portal. This page outlines repeatable patterns many platform teams automate (onboarding, infrastructure, feature flags, secrets, and Kubernetes operations), with example inputs, typical pipeline steps, and links to the Harness docs that define each step.

For rollout and adoption context, see the IDP adoption playbook. For hands-on setup, see the Self-Service Workflows overview, configure the Harness pipeline backend, the Workflow YAML reference, and Managing workflows.

Common workflow use cases

Use workflows for recurring tasks that need consistency and auditability, such as onboarding or offboarding, new services, infrastructure requests, and routine operational changes.

Below are seven examples this page expands on:

1. Service onboarding

2. Infrastructure provisioning

3. Toggling feature flags

4. Rotating secrets

5. Rolling back deployments

6. Scaling for traffic

7. Restarting services

Service onboarding

Service onboarding is one of the highest-value IDP use cases: scaffolding repositories, standard Dockerfiles, tests, configs, and layout before application code lands. A follow-on Harness pipeline can standardize build, test, scan, and deploy.

A common pattern is a pipeline that creates a pipeline: scaffold the repo, register the service in the IDP catalog, create a CI/CD pipeline (often via the Harness Terraform provider through a Create Resource step), and notify the team on Slack.

Service onboarding flow (scaffold, catalog, pipeline, notify)

Harness pipeline

Harness pipeline screenshot for service onboarding

Pipeline steps

Step	Harness step (type)	Description
Cookiecutter	CookieCutter	Scaffold repo code from a template
CreateRepo	CreateRepo	Create the repository in your Git provider
CreateCatalog	CreateCatalog	Create catalog-info.yaml for catalog registration
DirectPush	DirectPush	Push generated code to Git
RegisterCatalog	RegisterCatalog	Register the entity in Harness IDP
Create pipeline for service	CreateResource	Run an OpenTofu module (Harness Terraform provider) to create a CI/CD pipeline or other Harness entities; often from a template
Notify Team	SlackNotify	Post a Slack message (for example, using outputs from prior IDP steps)

Example workflow form fields

Project Name	Name of project
Repository type	Public or Private
Repository description	Description
Email for notification	Email for Slack notification
Template url	Cookiecutter template url
owner	Repo owner (Harness User/Group)
stack	Tech Stack

Example workflow (IDP)

Service onboarding - workflow form in IDP

Related documentation: Onboard a GitHub repository with a workflow, Service onboarding with the IDP stage, Create a Service from a workflow, and Set up the Harness IDP pipeline.

Infrastructure provisioning

Infrastructure provisioning is a natural fit for IDP: it replaces ad hoc tickets and manual checks with a governed pipeline while preserving approvals and audit history.

A typical flow creates a change ticket, runs Terraform through IaCM, gates on approval, evaluates policy on the plan output, and updates the ticket. You might add scheduled runs to review or tear down resources.

Infrastructure provisioning flow (change management, IaCM, and governance)

Harness pipeline

Harness pipeline screenshot for infrastructure provisioning

Pipeline steps

Stage	Diagram	Harness step (type)	Description
Change Management		JiraCreate	Create a Jira issue for traceability (see tutorial YAML)
Infra as Code Provisioning (plan)		IACM stage: IACMTerraformPlugin, optional lint Plugin (for example tfsec)	Init, lint, security scan, drift detection, and Terraform plan in the IaCM workspace as in the provision tutorial
Infra as Code Provisioning (apply)		Run (export plan), IACMApproval, IACMTerraformPlugin (apply)	Export the plan for downstream checks, gate on approval, then apply infrastructure changes as in the provision tutorial
Governance Management		Policy, JiraUpdate	Evaluate OPA on the exported plan payload; update Jira with results

Example workflow form fields

Owner	Harness User/Group
iacm_workspace	IaCM Workspace
Jira Project	Jira Project
Jira Issue Summary	Jira Issue Summary for infrastructure
Cloud Provider	GCP, AWS, etc
Instance Type	Enum for supported instances
AMI	Amazon Machine Image
Subnet	Deployed Subnet
VPC	Deployed VPC
Instance Count	Instance count

Example workflow (IDP)

Infrastructure provisioning - workflow form page 1 (request context)

Infrastructure provisioning - workflow form page 2 (infrastructure details)

Related documentation: Provision infrastructure using IDP and IaCM, Policy as code in IDP, and the Jira plugin.

Examples

These are smaller, frequent operations that benefit from the same guardrails: workflow RBAC, approvals, and a single place to see execution history.

Flip a feature flag

Changing a feature flag or its targeting is simple in the UI, but you may still want an auditable path: OPA on save, workflow RBAC, and pipeline checks so only allowed users change production targeting.

Harness Feature Management & Experimentation (FME) provides first-class pipeline steps for flag operations; combine them with a Policy step when you need to validate workflow inputs. Go to FME and Harness pipelines.

Feature flag governance and targeting flow

Harness pipeline

Harness pipeline screenshot for feature flag governance and targeting

Pipeline steps

Step	Harness step (type)	Description
Flag change governance	Policy	Validate workflow parameters (custom payload) against policy
Enable flag for target user	FmeFlagAddRemoveIndividualTargets	Conditionally add an individual target
Disable flag for target user	FmeFlagAddRemoveIndividualTargets	Conditionally remove an individual target

Example workflow inputs

Input	Description
Flag name	Feature flag identifier in your project
Target user key	Target id (for example, user or account key)
action	Enum for enable/disable
environment	FME environment for the change

Example workflow (IDP)

Feature flag change - workflow form in IDP

Related documentation: FME overview, Feature flags and pipelines, Targeting, Policy as Code for FME, and FME policies.

Rotate a token

Token rotation fits the same pattern: an approval, an Http call to your identity or API provider, then another HTTP call (or script) to store the new value in Harness secrets.

Using Harness HTTP steps you can mirror the feature-flag workflow: wrap sensitive API actions with governance and controls.

Secret rotation flow (approval and HTTP steps)

Harness pipeline

Harness pipeline screenshot for secret rotation

Pipeline steps

Step	Harness step (type)	Description
Approve Rotation	HarnessApproval	Require human approval before rotation
Rotate Token	Http	Call the provider API to rotate or issue a new token
Update secretText	Http	Call the Harness API (or your process) to update the stored secret value

Workflow inputs (account- or org-scoped secrets example)

Input	Description
Token identifier	Logical name or id for the token being rotated
Org for rotation API	Harness org id (or scope) used in the rotation API call
Service account identifier	Service account or principal the token belongs to
API Key identifier	API key or client id used to authenticate the rotation request
Secret identifier	Harness secret identifier to update after rotation
Secret scoped org	Org id when the secret is org-scoped
Secret display name	Human-readable name shown in the UI

Example workflow (IDP)

Token rotation - workflow form in IDP

Related documentation: Using a short-lived secret to trigger a workflow, HTTP step, and Add and use text secrets.

Roll back a deployment

When deployments are frequent, teams need a controlled rollback path. IDP can expose rollback to the right people with approvals and full execution history instead of ad hoc kubectl or UI-only changes.

Deployment rollback flow with approval

Harness pipeline

Pipeline steps

Step	Harness step (type)	Description
Approve rollback	HarnessApproval	Approve rollback of the selected workload
K8s rolling rollback	K8sRollingRollback	Roll back the Kubernetes workload to the last successful release

Example workflow inputs

Service Identifier	Service
Environment Identifier	Deployment Environment
Infradef	Infrastructure for environment

Example workflow (IDP)

Deployment rollback - workflow form in IDP

Related documentation: Rollback deployments and Kubernetes rollback.

Scale for traffic

Scaling workloads is another good workflow candidate: one standard pipeline, RBAC on who can run it, and traceability for every change.

Kubernetes scale flow with approval

Harness pipeline

Pipeline steps

Step	Harness step (type)	Description
Approve scale	HarnessApproval	Approve changing replica count
K8s Scale	K8sScale	Scale the workload in or out

Example workflow inputs

Service Identifier	Pipeline service identifier
Environment Identifier	Pipeline environment identifier
Infrastructure Definition	Pipeline infrastructure definition
Namespace	[namespace/]Kind/Name
Target Replicas	Desired replica count

Example workflow (IDP)

Scale workload - workflow form in IDP

Related documentation: Scale Kubernetes replicas.

Restart a service

Restarting is similar to scaling: approval plus a Kubernetes step that refreshes pods without a full redeploy.

Rolling restart flow with approval

Harness pipeline

Pipeline steps

Step	Harness step (type)	Description
Approve restart	HarnessApproval	Approve the restart
Rolling restart	K8sRollout (command: restart) or K8sPatch	Rolling restart or patch-based refresh of the workload

Example workflow inputs

Service Identifier	Pipeline service identifier
Environment Identifier	Pipeline environment identifier
Infrastructure Definition	Pipeline infrastructure definition
Namespace	[namespace/]Kind/Name

Example workflow (IDP)

Restart service - workflow form in IDP

Related documentation: Kubernetes Rollout restart and Kubernetes Patch step.