> 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/troubleshooting-and-resources/adoption-guide/why-workflows.md).
# IDP Workflow Patterns and Examples
**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](/internal-developer-portal/troubleshooting-and-resources/adoption-guide/adoption-playbook.md). For hands-on setup, see the [Self-Service Workflows overview](/internal-developer-portal/use-idp/self-service-workflows/overview.md), [configure the Harness pipeline backend](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md), the [Workflow YAML reference](/internal-developer-portal/use-idp/self-service-workflows/workflowyaml.md), and [Managing workflows](/internal-developer-portal/use-idp/self-service-workflows/manage-workflow-2o.md).
### 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](#service-onboarding)
2. [Infrastructure provisioning](#infrastructure-provisioning)
3. [Toggling feature flags](#flipping-a-feature-flag)
4. [Rotating secrets](#rotating-a-token)
5. [Rolling back deployments](#rolling-back-a-deployment)
6. [Scaling for traffic](#scaling-for-traffic)
7. [Restarting services](#restarting-a-service)
### 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.
**Harness pipeline**
**Pipeline steps**
| Step | Harness step (`type`) | Description |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Cookiecutter | [`CookieCutter`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#2-cookiecutter) | Scaffold repo code from a template |
| CreateRepo | [`CreateRepo`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#3-create-repo) | Create the repository in your Git provider |
| CreateCatalog | [`CreateCatalog`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#4-create-catalog) | Create `catalog-info.yaml` for catalog registration |
| DirectPush | [`DirectPush`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#5-direct-push) | Push generated code to Git |
| RegisterCatalog | [`RegisterCatalog`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#6-register-catalog) | Register the entity in Harness IDP |
| Create pipeline for service | [`CreateResource`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#8-create-resource) | Run an OpenTofu module (Harness Terraform provider) to create a CI/CD pipeline or other Harness entities; often from a template |
| Notify Team | [`SlackNotify`](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md#7-slack-notify) | 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)**
**Related documentation:** [Onboard a GitHub repository with a workflow](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/github-repo-onb.md), [Service onboarding with the IDP stage](/internal-developer-portal/troubleshooting-and-resources/idp-tutorials/service-onboarding-with-idp-stage.md), [Create a Service from a workflow](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/create-a-service.md), and [Set up the Harness IDP pipeline](/internal-developer-portal/use-idp/self-service-workflows/create-workflow/harness-pipeline.md).
### 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.
**Harness pipeline**
**Pipeline steps**
| Stage | Diagram | Harness step (`type`) | Description |
| ---------------------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Change Management |  | [`JiraCreate`](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md) | Create a Jira issue for traceability (see tutorial YAML) |
| Infra as Code Provisioning (plan) |  | [`IACM`](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md) stage: [`IACMTerraformPlugin`](/infrastructure-as-code-management/use-iacm/iacm-cli-commands/terraform-plugins.md), optional lint [`Plugin`](/infrastructure-as-code-management/use-iacm/iacm-cli-commands/terraform-plugins.md) (for example tfsec) | Init, lint, security scan, drift detection, and Terraform plan in the IaCM workspace as in the [provision tutorial](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md) |
| Infra as Code Provisioning (apply) |  | [`Run`](/continuous-integration/use-harness-ci/use-harness-ci/run-step-settings.md) (export plan), [`IACMApproval`](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md), [`IACMTerraformPlugin`](/infrastructure-as-code-management/use-iacm/iacm-cli-commands/terraform-plugins.md) (apply) | Export the plan for downstream checks, gate on approval, then apply infrastructure changes as in the [provision tutorial](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md) |
| Governance Management |  | [`Policy`](/harness-ai/use-harness-platform/governance/policy-as-code/add-a-governance-policy-step-to-a-pipeline.md), [`JiraUpdate`](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md) | 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)**
**Related documentation:** [Provision infrastructure using IDP and IaCM](/internal-developer-portal/use-idp/self-service-workflows/workflows-tutorials/provision-infrastructure-using-idp.md), [Policy as code in IDP](/internal-developer-portal/admin-and-customization/governance/opa-governance.md), and the [Jira plugin](/internal-developer-portal/use-idp/plugins/available-plugins/jira.md).
### Examples
These are smaller, frequent operations that benefit from the same guardrails: [workflow RBAC](/internal-developer-portal/admin-and-customization/rbac/workflow-rbac.md), 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)](/feature-management-experimentation/new-to-fme/get-started.md) provides first-class pipeline steps for flag operations; combine them with a [`Policy`](/harness-ai/use-harness-platform/governance/policy-as-code/add-a-governance-policy-step-to-a-pipeline.md) step when you need to validate workflow inputs. Go to [FME and Harness pipelines](/feature-management-experimentation/management-and-administration/pipelines.md).
**Harness pipeline**
**Pipeline steps**
| Step | Harness step (`type`) | Description |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Flag change governance | [`Policy`](/harness-ai/use-harness-platform/governance/policy-as-code/add-a-governance-policy-step-to-a-pipeline.md) | Validate workflow parameters (custom payload) against policy |
| Enable flag for target user | [`FmeFlagAddRemoveIndividualTargets`](/feature-management-experimentation/management-and-administration/pipelines.md#addremove-individual-targets) | Conditionally add an individual target |
| Disable flag for target user | [`FmeFlagAddRemoveIndividualTargets`](/feature-management-experimentation/management-and-administration/pipelines.md#addremove-individual-targets) | 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](/feature-management-experimentation/management-and-administration/environments.md) for the change |
**Example workflow (IDP)**
**Related documentation:** [FME overview](/feature-management-experimentation/new-to-fme/get-started.md), [Feature flags and pipelines](/feature-management-experimentation/management-and-administration/pipelines.md), [Targeting](/feature-management-experimentation/use-fme/feature-management/targeting/index.md), [Policy as Code for FME](/harness-ai/use-harness-platform/governance/policy-as-code/using-harness-policy-engine-for-fme.md), and [FME policies](/feature-management-experimentation/management-and-administration/policies.md).
#### Rotate a token
Token rotation fits the same pattern: an approval, an [`Http`](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/http-step.md) call to your identity or API provider, then another HTTP call (or script) to store the new value in Harness [secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md).
Using Harness HTTP steps you can mirror the feature-flag workflow: wrap sensitive API actions with governance and controls.
**Harness pipeline**
**Pipeline steps**
| Step | Harness step (`type`) | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Approve Rotation | [`HarnessApproval`](/harness-ai/use-harness-platform/approvals/approvals-tutorial.md) | Require human approval before rotation |
| Rotate Token | [`Http`](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/http-step.md) | Call the provider API to rotate or issue a new token |
| Update secretText | [`Http`](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/http-step.md) | 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)**
**Related documentation:** [Using a short-lived secret to trigger a workflow](/internal-developer-portal/troubleshooting-and-resources/idp-tutorials/using-secret-as-an-input.md), [HTTP step](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/http-step.md), and [Add and use text secrets](/harness-ai/use-harness-platform/secrets/add-use-text-secrets.md).
#### 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.
**Harness pipeline**
\
**Pipeline steps**
| Step | Harness step (`type`) | Description |
| -------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| Approve rollback | [`HarnessApproval`](/harness-ai/use-harness-platform/approvals/approvals-tutorial.md) | Approve rollback of the selected workload |
| K8s rolling rollback | [`K8sRollingRollback`](/continuous-delivery/use-continuous-delivery/manage-deployments/rollback-deployments.md) | 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)**
**Related documentation:** [Rollback deployments](/continuous-delivery/use-continuous-delivery/manage-deployments/rollback-deployments.md) and [Kubernetes rollback](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-rollback.md).
#### Scale for traffic
Scaling workloads is another good workflow candidate: one standard pipeline, RBAC on who can run it, and traceability for every change.
**Harness pipeline**
\
**Pipeline steps**
| Step | Harness step (`type`) | Description |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| Approve scale | [`HarnessApproval`](/harness-ai/use-harness-platform/approvals/approvals-tutorial.md) | Approve changing replica count |
| K8s Scale | [`K8sScale`](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/scale-kubernetes-replicas.md) | 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)**
**Related documentation:** [Scale Kubernetes replicas](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/scale-kubernetes-replicas.md).
#### Restart a service
Restarting is similar to scaling: approval plus a Kubernetes step that refreshes pods without a full redeploy.
**Harness pipeline**
\
**Pipeline steps**
| Step | Harness step (`type`) | Description |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| Approve restart | [`HarnessApproval`](/harness-ai/use-harness-platform/approvals/approvals-tutorial.md) | Approve the restart |
| Rolling restart | [`K8sRollout`](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-rollout-restart.md) (`command: restart`) or [`K8sPatch`](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-patch-step.md) | 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)**
**Related documentation:** [Kubernetes Rollout restart](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-rollout-restart.md) and [Kubernetes Patch step](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/kubernetes-patch-step.md).