# Work your whole Terraform approval queue from one board

> Every Terraform run that needs a human, across every workspace, on one board with approve, discard, and plain English plan summaries.

- Workflow type: app
- Services: HCP Terraform (Terraform Cloud), Jira
- Categories: Engineering, Operations
- Published: 2026-08-24

## What it does

- Pulls every run across your whole Terraform organization into a single board, grouped into needs approval, errored, and stuck in progress, oldest first
- Shows the workspace, the project, and who queued each run on the card, so you know whose change you are looking at before you touch it
- Puts approve, discard, and force execute buttons directly on the card, so an approver never has to open a workspace one at a time
- Gives every run awaiting approval a Review this plan button that writes a plain English summary of what the apply will actually change, calling out anything being destroyed or replaced
- Tracks how long each run has been waiting, so approvals quietly sitting for days stop being invisible
- Files a Jira ticket from any card in one click, prefilled with the error and a link back to the run

## What you'll need

- An HCP Terraform account with permission to view and approve runs in your organization
- The name of the Terraform organization you want the board to cover
- A Jira account and a project where infrastructure tickets should be filed
- Approver permissions for anyone who will use the approve, discard, or force execute buttons

## Prompt

Build me an app my platform team opens every morning to work the Terraform run queue across our entire HCP Terraform organization, instead of clicking into workspaces one at a time. HCP Terraform's own UI is workspace scoped, so there is no single screen that answers "what needs my approval right now" across the org. That screen is this app.

The main view is one board of every run that currently needs a human. Load it with List Organization Runs against our organization name, which is a setting on the app. The runs that need a human are the non_final and discardable status groups plus anything errored, so use filter[status_group] to pull non_final and discardable and also pull errored runs, then merge and de-duplicate by run id. Enrich each run with Show Run for its full status, timestamps, status timestamps, plan relationship and available actions, and with Show Workspace for the workspace name and the project it belongs to. Page through the results rather than showing only the first page, since a busy org will have more than one page of runs.

Group the board into three sections in this order: Needs approval, Errored, and Stuck in progress. Needs approval is runs sitting at planned, policy_override, or policy_soft_failed, meaning a plan finished and is waiting on a person to confirm. Errored is runs in the errored status. Stuck in progress is everything still moving or queued, such as pending, fetching, plan_queued, planning, cost_estimating, policy_checking, confirmed, apply_queued, and applying. Sort every group oldest first, so the run that has been waiting longest is the first thing an approver sees. Show a count next to each group heading.

Each card shows the workspace name, the project the workspace belongs to, who queued the run, the run message or commit message, the current status as a badge, and the run id. Include a link out to the run in HCP Terraform for anyone who wants the raw logs. Make the card readable at a glance: a person should be able to scan twenty of these and know which ones matter.

Waiting time is the headline element on every card, because approvals quietly sitting for days is the real pain this app fixes. Compute how long the run has been in its current waiting state from the run's timestamps and display it prominently in human terms, like "waiting 3 days" or "waiting 4 hours". Escalate the card visually as it ages, for example neutral under a day, amber past a day, and red past three days, and make those thresholds configurable. Sorting oldest first plus the age on the card is what stops old approvals from being invisible.

Every card carries inline action buttons so an approver never leaves the page. Apply Run confirms and applies a planned run. Discard Run throws it away. Force Execute Run jumps a pending run past the workspace queue. Only show each button when it is actually valid for that run's status, using the actions HCP Terraform reports on the run: apply and discard belong on runs awaiting confirmation, force execute belongs on runs stuck behind a queue. Ask for a short confirmation before applying or discarding, show the button in a pending state while the action runs, surface any error returned by the API on the card itself, and refresh that card's state afterwards so the board reflects what just happened.

Each card also gets a File a ticket button that creates a Jira issue with Create Issue. Prefill the summary with the workspace name and what went wrong, and prefill the description with the run's error message, the status, the workspace and project, who queued it, and a link back to the run in HCP Terraform. Let the person confirm or edit the project, issue type, and summary before it is filed, then show the resulting issue key on the card so nobody files the same ticket twice. Filing is always a deliberate click, never automatic.

Every card waiting for approval gets a Review this plan button that kicks off a background agent. The agent reads the run with Show Run, reads the plan with Show Plan for the change counts, and reads the machine readable plan with Get Plan JSON Output for the actual per resource actions. It then writes a plain English summary of what the apply will really do, in a few sentences an approver can read in ten seconds. It must explicitly call out any resource being destroyed or replaced, naming those resources, and lead with that when it finds any, since a replace on a database or a stateful resource is the thing an approver most needs to catch. If nothing is destroyed or replaced it should say so plainly.

The agent's verdict lands back on the card, stored against the run id so it persists and is visible to whoever opens the board next. Show the review inline on the card above the Apply button, so the approver reads the verdict before clicking Apply rather than after. Show the review's state on the card while it is running, and stamp it with when it was generated. Let a person re-run the review, and make it easy to review every waiting card at once rather than clicking each one.

Add a refresh control for the whole board and show when the data was last loaded, since this is a screen people leave open. When a group is empty, say so in a way that reads as good news rather than as an error, for example "Nothing waiting on approval".

## How to customize

- Change which groups appear on the board, for example hiding stuck in progress runs and keeping only approvals and failures
- Set the waiting time thresholds that turn a card amber or red, so your team's idea of overdue matches the board
- Choose the Jira project, issue type, and default assignee that new tickets are filed against
- Point the board at a single Terraform project instead of the whole organization if one team owns the queue

## FAQ

### Will this approve anything on its own?

No. Nothing is applied, discarded, or force executed unless a person clicks the button on the card. The plan summary is written for you to read first, and approving is always a deliberate human action.

### Does this work across all my workspaces at once?

Yes, and that is the point. HCP Terraform's own screens are built around one workspace at a time, so a queue spread across dozens of workspaces means a lot of clicking. This board pulls the whole organization into one list.

### Do I still need to open HCP Terraform?

For everyday approvals, usually not. Each card links back to the run in HCP Terraform whenever you want the full logs or the raw plan output, but the summary, the waiting time, and the buttons are all on the board.

### Can I trust the plain English plan summary?

Treat it as a fast first read, not a replacement for judgement. It reads the run's plan detail and flags anything being destroyed or replaced so a risky apply is obvious at a glance, and the full plan is one click away when a change deserves a closer look.

### What if we do not use Jira?

The board works without it. The file a ticket button is a convenience for turning a failed run into tracked work, and you can leave it off or point it at a different project than the rest of your engineering tickets.

### Why does the waiting time matter so much?

Because a run waiting for approval does not chase anyone. Changes routinely sit for days simply because nobody was looking at that particular workspace, and putting the age on every card is what makes that visible.

Use this prompt in General Input: https://www.generalinput.com/prompts/work-your-whole-terraform-approval-queue-from-one-board