> 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/release-orchestration/use-release-orchestration/release-orchestration-activities/activity-types/manual-activities.md).

# Manual Activities

Learn about manual activities and how to configure them for human intervention in release processes

Manual activities require human intervention and provide checkpoints where team members must perform actions, provide approvals, or complete tasks. These activities pause the release execution and wait for designated users to take action before proceeding.

### What you will learn from this topic

* Understand [what a manual activity is](#what-are-manual-activities) and how the [manual activity workflow](#manual-activity-workflow) works
* How to identify the [types of manual activities](#types-of-manual-activities) supported in Release Orchestration
* How to [configure](#configuration) a manual activity and its [approval workflows](#approval-workflows) and [notifications](#notifications)
* How to apply the [best practices](#best-practices) for manual activities

### What are manual activities? <a href="#what-are-manual-activities" id="what-are-manual-activities"></a>

A manual activity lets you create tasks, record inputs, and finalize them. Manual activities require human intervention and provide checkpoints where team members must perform actions, provide approvals, or complete tasks.

Manual activities enable human oversight at critical decision points where automated execution is not appropriate. They support manual tasks that cannot be automated, such as complex validations or decisions that require human judgment.

These activities also handle required sign-offs and approvals, code or configuration reviews, and allow users to record their inputs and finalize them manually. Users can provide sign-offs with QA inputs or other documentation, creating an audit trail of decisions and validations.

### Manual activity workflow <a href="#manual-activity-workflow" id="manual-activity-workflow"></a>

When a manual activity is encountered during release execution, the workflow follows a structured process. The activity enters a "waiting for input" or "on hold" state, pausing the release. Notifications are sent to the activity owner or assigned users, alerting them that their action is required.

Users need to review the activity requirements, create tasks as needed, record their inputs, and finalize them manually. Users can provide sign-offs, such as stating "I'm signing off this release with the QA inputs," recording QA inputs and test results, or providing approval comments that explain their decision.

Once inputs are finalized and sign-off is provided, the activity is completed, and the release continues to the next step.

### Types of manual activities <a href="#types-of-manual-activities" id="types-of-manual-activities"></a>

**Manual tasks**

Manual tasks require user action that cannot be automated. These include manual data entry, where users must input information; manual configuration changes that require human verification; and manual verification steps that require visual inspection or judgment.

Manual documentation tasks that need human review and completion are also part of this category.

**Approval activities**

Approval activities require explicit sign-off from designated approvers. These include deployment approvals, where stakeholders must approve before deployments proceed, and release approvals for the overall release go-ahead.

Change approvals for configuration or process changes, and go/no-go decisions where teams jointly decide whether to proceed with a release, are also common approval activity types.

**Review activities**

Review activities require human review and validation. These include code review checkpoints where developers must review code changes, and configuration review where settings must be validated.

Security review, where security teams assess risks, and compliance review, where compliance teams verify that regulatory requirements are met, are also important types of review activity.

**Testing activities**

Manual testing tasks require human testers to perform validation. These include user acceptance testing, in which end users validate functionality, and exploratory testing, in which testers manually explore the system.

Manual performance validation, where teams verify performance characteristics, and manual integration checks, where teams verify system integration points, are also common testing activities.

### Configuration <a href="#configuration" id="configuration"></a>

**Example (YAML)**

This example shows a manual activity in a process, including a dependency on a prior activity.

```yaml
phase:
  id: build_phase
  name: Build Phase
  activities:
    - activity: ManualTest
      id: AutoIioo
      name: Auto_deploy
      description: doc
      depends-on:
        - AutoPipe12
```

### Approval workflows <a href="#approval-workflows" id="approval-workflows"></a>

**Single approval**

One person must approve:

```yaml
activity:
  name: "Deployment Approval"
  type: "manual"
  approval_type: "single"
  approver: "${release_manager}"
```

**Multiple approvals**

Multiple people must approve:

```yaml
activity:
  name: "Release Approval"
  type: "manual"
  approval_type: "multiple"
  approvers:
    - "${release_manager}"
    - "${security_lead}"
    - "${operations_lead}"
  required_approvals: 2
```

**Sequential approvals**

Approvals in sequence:

```yaml
activity:
  name: "Cascading Approval"
  type: "manual"
  approval_type: "sequential"
  approvers:
    - "${team_lead}"
    - "${department_head}"
    - "${vp_engineering}"
```

### Notifications <a href="#notifications" id="notifications"></a>

**Assignment notifications**

Notify when assigned:

```yaml
activity:
  name: "Manual Task"
  type: "manual"
  notifications:
    on_assignment: true
    channels: ["email", "slack"]
```

**Reminder notifications**

Send reminders:

```yaml
activity:
  name: "Pending Approval"
  type: "manual"
  reminders:
    - after: "4 hours"
    - after: "12 hours"
    - after: "24 hours"
```

### Best practices <a href="#best-practices" id="best-practices"></a>

**Clear instructions**

Provide detailed instructions that explain what needs to be done, why it is needed, what to check, and how to complete the activity.

Clear instructions reduce confusion and ensure users can complete manual activities efficiently without needing to ask questions or make assumptions about what is required.

**Appropriate timeouts**

Set reasonable timeouts that balance urgency with practicality. Timeouts should not be too short, which forces rushed decisions, or too long, which unnecessarily blocks releases.

Consider time zones when setting deadlines, and account for weekends and holidays when releases might span non-business days.

**Owner assignment**

Assign owners who are appropriate for the task, available during the release window, and have the necessary permissions to complete the activity.

Designate backup assignees who can step in if the primary owner is unavailable, preventing releases from stalling due to a single person's absence.

**Documentation**

Document manual activities thoroughly, including their purpose and context, expected outcomes, common issues that arise, and escalation procedures for when things go wrong.

Good documentation helps users understand what they are approving or validating and provides guidance for handling edge cases or problems.

### Related topics <a href="#related-topics" id="related-topics"></a>

* [Activities Overview](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md)
* [Automated Activities](/release-orchestration/use-release-orchestration/release-orchestration-activities/activity-types/automated-activities.md)
* [Capturing Sign-off](/release-orchestration/use-release-orchestration/release-orchestration-collaboration/manual-approvals.md)

{% @harness-feedback/feedback %}
