Decommissions

Decommission Requests are the formal process for retiring an environment. A request goes through review, an optional checklist of shutdown tasks, and approval before the environment is actually marked as decommissioned — so nothing gets torn down without a paper trail.

Overview

A decommission request can be:

• Linked to an existing Environment, or
• Standalone — describing an environment or service to decommission by name, without linking a managed Environment record

Either way, the request moves through the same review/approval lifecycle, and a separate, explicit Confirm & Close action is what actually marks the environment as decommissioned — approval alone does not.

---

Request Keys

Every decommission request has a short, readable key of the form DEC-018. It appears next to the title in the request list and on the request's own page, where clicking it copies it to your clipboard.

Keys are numbered per organisation and never reused. Environment requests and bookings have their own independent numbering (ENV-142, BKG-903), so the prefix tells you which list to look in.

You can find a request by its key from the search box on the Decommissions page, or from the global search bar in the header, where typing DEC-018 jumps straight to it. Approval emails carry the key in the subject line as [DEC-018] Approval Required: ....

Numbers are assigned in the order requests are raised.

---

Submitting a Request

1. Navigate to Decommissions in the sidebar
2. Click New Decommission Request
3. Fill in Basic Details:

Once you pick an Environment Type, a live preview shows the approval workflow that will be used, or a notice that the request will go to direct admin review if no matching workflow is configured.

4. Complete any additional checklist groups your admin has enabled (see below)
5. Submit — if a matching approval workflow is configured, it starts automatically; otherwise the request stays Pending for direct admin review

Environment Type and the linked environment cannot be changed after submission — they determine which approval workflow applies.

Decommission Checklist

Admins can import a full decommission checklist template covering two tabs — Environment Checklist and Service Checklist — with items like Data Owner, retention decisions, backout plan, incident/problem/knowledge management sign-off, and more. If enabled, these appear on the request form below Basic Details, the same way custom fields appear on other request types. No checklist items are enabled by default — only the Basic Details section is required out of the box. See Field Mapping for how templates and custom fields work in general.

---

Saving a Draft

You don't have to finish a request in one sitting. Once you've entered an Environment Name, the form saves itself as a Draft, automatically as you work. A status next to the buttons tells you when the last save happened.

A draft is yours alone:

• Nobody else can see it — not admins, not approvers, not through search
• No approval workflow starts, so no approver is emailed and nothing appears in anyone's queue
• No request key is assigned — a discarded draft never leaves a gap in the DEC- sequence

Because a draft is private and unfinished, it's checked far more loosely than a submission. Anything you've filled in still has to be valid — a date has to be a real date, a number has to be in range — but fields you haven't reached yet are simply ignored, including required checklist items. Only Environment Name is needed, because the request is named after it.

The form still shows which approval workflow would apply, and updates it if you change Environment Type, so there are no surprises when you submit.

Drafts appear in My Requests with a Draft badge, and under the Draft status filter there. From the list or the form you can:

• Continue editing — pick up where you left off
• Discard draft — delete it permanently, along with anything you uploaded
• Submit Request — this is where full validation happens, and where the approval workflow finally starts

A draft's menu offers Continue editing rather than a read-only view — it exists to be finished, and the form already shows everything the detail page would, including which approval chain it would enter.

If something is still missing when you submit, the form marks the fields that need filling in and nothing is sent. The one-open-request-per-environment rule is also checked at this point rather than while you draft, so it's possible for someone else to claim an environment while your draft is sitting there.

---

Request Statuses

The Decommissioning and Decommissioned statuses only appear when the request's approval workflow has a decommissioning stage configured — without one, the request jumps straight from Approved to Completed when someone runs Confirm & Close.

Only one open decommission request is allowed per linked environment at a time — you can't submit a second one until the first reaches a terminal status (Completed, Rejected, Cancelled, or Expired).

---

List and Detail Views

The Decommissions page shows:

• Summary cards — counts for Pending, Awaiting Info, Approved, and Decommissioned
• Scope tabs — All, Approvals & IRs (items awaiting your action), My Requests
• Search — by title, environment name, environment type, or requester
• Status filter — filter the list by any status

The request's own details — who raised it, when, its current state, and the reviewer's notes once it has been decided — sit at the top of the page and stay visible whichever tab you are on, because they are the context you read everything else against. Below them are four tabs:

• Forms — everything that was filled in, Basic Details and the checklist, laid out under the tabs an administrator configured, plus one tab per additional form an approver attached. The whole form is shown, not just the parts that were filled in: an enabled section appears even when it was left blank, with its fields marked Not provided, and a tab appears even when every section on it is empty. An approver needs to tell "the requester skipped this" from "the form never asked for it", and a section that quietly disappears when empty makes those two look identical. The exception is a section that only appears under a condition — those show only when they were actually asked for, since a rule that never fired means the requester was never shown it
• Workflow — the request's progress card: which approval levels have been decided, by whom, and who can decide the ones still ahead — and, when configured, the hand-over, decommissioning, and closing stops with who's assigned and who acted. On a draft it shows the chain the request would go through
• Comments — the discussion thread on the request, open to the requester, the request's workflow approvers, and whoever is named for the decommissioning or closure stage, and it stays open after the request is decided. Posting emails the requester and every approver the request has already reached, minus whoever wrote it — levels assigned by role rather than to named people are not emailed
• Activity — a chronological record of everything that has happened to the request (see below)

Forms opens first.

The Activity tab

Newest first, grouped by day. It records the same things as an environment request's Activity tab, with the decommission's own wording: sent for decommissioning, marked decommissioned, and the closing action that retires the environment.

That closing action writes to both feeds — the request's, and the environment's own — so somebody looking at a retired environment can see which decommission request retired it without having to go looking for the request.

Requests raised before this feature shipped show their creation, approval decisions and closure, but not comments, emails or edits — none of that was being recorded at the time.

---

Approval Workflow

Decommission requests use the same approval workflow engine as Environment Requests and Bookings, configured per environment type. See Approvals for how workflows and approval levels are set up.

A workflow can also define what happens after approval: a decommissioning stage (who does the teardown) and a closure stage (who signs off with Confirm & Close), each assigned to named people or a role. See Completing a Decommission below for how those stages play out.

If no workflow is configured for a request's environment type, it isn't auto-approved — it simply routes to Admins for a direct approve/reject decision instead of going through workflow steps.

---

Completing a Decommission

What happens after approval depends on whether the request's approval workflow has post-approval stages configured (see Approvals).

Without stages — the classic flow. Once the request is Approved, an authorized reviewer runs Confirm & Close to finalize it in one step.

With a decommissioning stage — the request goes through hand-off and teardown first:

1. Send for Decommissioning — an approver of the request hands it over once approval is done. The request moves to Decommissioning and the stage's assignees are notified
2. Mark as decommissioned — the assigned person confirms the teardown work is finished. The request moves to Decommissioned
3. Confirm & Close — the final sign-off closes the request

In both flows, Confirm & Close is what actually finishes the request:

• The request moves to Completed
• If the request was linked to an environment, that environment's status is set to Decommissioned
• Standalone (unlinked) requests are simply marked complete, with no environment to update

The request's progress card shows each of these stops on the timeline — who they're assigned to, who acted, and when.

---

Managing Requests

• Edit — the requester (or an Admin) can edit a request while it's Pending or Awaiting Info; Environment Type and the linked environment can't be changed. While the request is Decommissioning, only the stage's assigned person and Admins can edit — the requester can't. From Decommissioned onwards nobody can
• Cancel — the requester (or an Admin) can cancel a request while it's Pending or Awaiting Info; this also stops any in-progress approval workflow. Cancelling from Awaiting Info withdraws the request without completing the outstanding additional forms
• Delete — available to Admins and Super Admins, for any request that hasn't entered the decommissioning stage. Once a request is Decommissioning, Decommissioned, or Completed, it can no longer be deleted — the record of who authorised the teardown has to survive it
• Clone — anyone who can raise requests can clone any request into a new pre-filled one, whatever its status. The checklist values and project details are carried over. The linked environment comes across only if it hasn't already been decommissioned — otherwise you pick one, since a destroyed environment can't be decommissioned again. The original request is never modified
• Comments & Information Exchange — both requesters and reviewers can communicate on a request without leaving the page
• Export PDF — see below

---

Exporting a Request as PDF

Export PDF is in the actions menu, on both the request cards in the list and the request detail page. It downloads the request as a document you can file, attach to a change record, or hand to an auditor — useful for decommissions in particular, since the record needs to outlive the environment it destroyed.

The PDF reads as a filled-in form rather than a screenshot of the page. It contains:

• Approval progress — the approval chain as a stepper across the top, showing which levels have been approved or rejected, who decided them, and — for levels the request hasn't reached yet — who will be able to approve them
• Request details — environment name and type, project code, service name, project manager, technical application owner, requester and dates
• The decommission checklist — every group the form asks for, laid out under the same tabs as the form itself, with file uploads as clickable links. Groups and items left blank are printed too, marked as not provided: "the requester skipped this" and "the form never asked" are different things, and an auditor reading the record months later needs to be able to tell them apart
• Additional forms — the forms attached during approval and what was entered in them

Only the final round of each form is included. If a reviewer asked for the same form more than once, earlier rounds are left out — the export records what was ultimately agreed, not the back-and-forth.

Anyone who can open the request can export it, so Viewers can too. What lands in the PDF is scoped to your own permissions: if a form is marked Sensitive and you're neither the requester nor an approver on the request's workflow, its values are replaced with a "hidden" placeholder rather than printed. Every export is recorded in the audit log.

Attachment links need you to be signed in. File links in the PDF point back at Realm9 rather than at the file store directly, so they keep working indefinitely and each click is checked against the permissions of whoever clicks it. If you forward the PDF outside Realm9, the recipient will see the request's contents but the attachment links will ask them to sign in.

---

Access Control

• Creating a request — available to any team member except read-only Viewers
• Approving — whoever is the current approver on the workflow step, or an Admin/Super Admin when no workflow applies
• Send for Decommissioning — the request's own approvers (the people who appear on its approval steps)
• Mark as decommissioned — the person or role assigned to the workflow's decommissioning stage
• Confirm & Close — the person or role assigned to the workflow's closure stage; when no closure assignee is configured, Provisioners, Admins, and Super Admins
• Editing, cancelling, or deleting someone else's request — Admins and Super Admins. A Provisioner's authority over another person's request is approving and rejecting it, and running Confirm & Close once it's ready — not rewriting, withdrawing, or deleting it

---

Next Steps

• Manage Environments
• Request a New Environment
• Configure Approvals
• Additional Forms