---
title: "Ad hoc Approval"
description: "Explore the efficiency of an Ad hoc Approval workflow, enabling spontaneous, single-step approvals for streamlined decision-making. (Gitana 4.0)"
product: "Gitana"
version: "4.0"
url: "/documentation/gitana/4.0/engine/workflow/sample-workflows/adhoc-approval"
---

# Ad hoc Approval

Let's take a look at an `Ad hoc Approval` workflow. The term `Ad hoc` is used in the workflow world to refer to a one-step approval process that can be initiated at any time for straight forward approval.

```
{
    "id": "sample:adhoc",
    "title": "Sample Adhoc Approval",
    "nodes": {
        "start": {
            "type": "start",
            "transitions": {
                "start": "step1"
            }
        },
        "step1": {
            "type": "participant",
            "title": "Please approve the attached documents",
            "description": "The provided documents require your approval",
            "swimlane": "approver",
            "transitions": {
                "approve": "approve",
                "reject": "reject"
            }
        },
        "approve": {
            "type": "passthru",
            "transitions": {
                "end": "end"
            }
        },
        "reject": {
            "type": "passthru",
            "transitions": {
                "end": "end"
            }
        },
        "end": {
            "type": "end"
        }
    },
    "swimlanes": {
        "approver": {
            "principals": []
        }
    }
}
```

## How it works

1.  The workflow model begins in the `start` state.
2.  It immediately transitions to the `step1` state.
3.  The `step1` state is of type `participant` and so it requires user interaction to continue. The workflow will wait in this state until a user who belongs to the `approver` swimlane triggers one of the transitions.
4.  If the `approve` transition is triggered, the workflow advances to the `approve` state. Otherwise, if the `reject` transition is triggered, the workflow advances to the `reject` state.
5.  Both the `approve` and `reject` states are of type `passthru`. They simply advance the first available transition and go to the `end` state.
6.  The `end` state is of type `end` and so it ends the workflow.

## Notes

This workflow intentionally leaves the `approver` swimlane empty. The user who launches this workflow will be prompted to provide one or more principals to occupy the swimlane. The swimlane could be occupied by a single user, multiple users, a group, many groups or any combination of the aforementioned.

Anyone who is a member of the `approver` swimlane will have the option to work on the workflow when it is in the `step1` state.

If the `approver` swimlane has exactly 1 user, the user will be auto-assigned to `step1`. On the other hand, if the `approver` swimlane has multiple users or groups, the participant state identified by `step1` will not be auto-assigned. Instead, a member of the swimlane will need to first Claim the Task.