Environment Requests

Environment Requests are formal provisioning requests for environments that don't exist yet. Users submit a request describing what they need; once approved, a Provisioner or Admin creates the environment from the request, which links back to it.

Overview

Use an Environment Request when you need infrastructure that isn't available yet — as opposed to booking an environment that already exists. A request goes through review and approval before any environment is created, and once an environment is created from it, the two records stay linked.

---

Request Keys

Every environment request has a short, readable key of the form ENV-142. 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, so ENV-142 means one specific request within your organisation. Bookings and decommission requests have their own independent numbering (BKG-903, DEC-018), so ENV-1 and BKG-1 can both exist without ambiguity.

Use a key wherever you need to refer to a request precisely — in a chat message, a change record, or a conversation with an approver. You can find a request by its key from the search box on the Environment Requests page, or from the global search bar in the header, where typing ENV-142 jumps straight to that request. Typing just the number works too, though it may match a booking or decommission request with the same number.

Numbers are assigned in the order requests are raised.

Approval emails carry the key in the subject line, as [ENV-142] Approval Required: ..., so they thread and search cleanly in your mail client.

---

Submitting a Request

1. Navigate to Environment Requests in the sidebar
2. Click New Request
3. Fill in the request form:

4. Submit — if a matching approval workflow is configured for the selected Environment Type, it starts automatically; otherwise the request stays Pending for direct admin review

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

An approver may attach an additional form asking for more detail before deciding, instead of rejecting outright — see Additional Forms for how that round-trip works.

If the ServiceNow integration is configured and enabled for your organisation, a ServiceNow card appears on the form with a toggle (on by default). You can turn it off before submitting if you do not want a ticket created. When left on, the ticket is created as part of the submission and the resulting ticket number and link are stored on the request record.

---

Saving a Draft

You don't have to finish a request in one sitting. Once you've entered a Title, 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 ENV- 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, an environment name still has to use allowed characters — but fields you haven't reached yet are simply ignored, including required custom fields. Only Title is needed, so you have something to find it by.

A draft does not reserve an environment name. The name is only checked for availability when you submit, so a name that's free today may be taken by someone else before you finish. The form's live availability check still warns you as you type.

The form also 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 any documents 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.

---

Request Statuses

The Provisioning and Provisioned statuses only appear when the request's approval workflow has a provisioning stage configured — without one, the request goes straight from Approved to Completed when the environment is created.

---

Request Views

The Environment Requests page shows:

• Scope tabs — All, Approvals (with a live pending-count badge), My Requests
• Summary cards — counts for Pending, Awaiting Info, Approved, and Completed
• Search — by title, software, or requester
• List view — filterable by status
• Calendar view — requests plotted on a calendar by submission date

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, 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, provisioning, 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
• 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:

• Status changes — submitted, approved, rejected, cancelled, expired, sent for provisioning, marked provisioned, closed — each showing the status it moved from and to
• Approvals — every approver's decision, the level they decided at, and their notes. A decision made directly by an administrator (on a request with no workflow) says so, rather than reading as though an approval chain had run
• Stages — who the request was handed to for provisioning, who marked the work done, and the environment that closing it created
• Comments — each post in the Comments tab also appears here
• Additional forms — attached, answered, and withdrawn, including who each was routed to
• Emails — every notification the request sent and who received it, including any that failed to deliver. If a rule matched but resolved to nobody, administrators see that too — it is usually the explanation for "why was nobody told?"
• Edits — which fields changed, expandable to show old and new values

Use the chips along the top to filter to one kind of entry.

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.

---

Creating the Environment

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 a request is Approved, whoever is authorized (see Access Control) sees a Create Environment action on the request.

With a provisioning stage — the request goes through hand-off and build first:

1. Send for Provisioning — an approver of the request hands it over once approval is done. The request moves to Provisioning and the stage's assignees are notified
2. Mark as provisioned — the assigned person confirms the build work is finished. The request moves to Provisioned
3. Create Environment — the final step, as below

In both flows, Create Environment is what finishes the request. It opens the environment creation form pre-filled from the request — including the reserved Environment Name and anything collected on additional forms along the way. Creating the environment links it back to the request, which moves the request to Completed.

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

What carries over

• Always — the environment name, the description, the environment type, and the requested software.
• Any request field group an administrator has marked to inherit. Its values arrive already filled in and become part of the environment's own details, so they stay visible and editable long after the request is closed. See Carrying request details onto the environment for how to set this up.
• Submitted additional forms collected during approval. A form that was attached but never submitted does not carry over, and where the same form was completed more than once, only the latest round does.

Anything pre-filled can be changed before the environment is saved. Those edits apply to the environment only — the request keeps its original values as a record of what was asked for.

---

Managing Requests

• Edit — the requester (or an Admin) can edit a request while it's Pending or Awaiting Info — but only before an environment has been created from it. While the request is Provisioning, only the stage's assigned person and Admins can edit — the requester can't. From Provisioned onwards nobody can
• Cancel — the requester (or an Admin) can cancel a request while it's Pending or Awaiting Info, and only before an environment has been created from it. Cancelling from Awaiting Info withdraws the request without completing the outstanding additional forms, and stops the approval workflow
• Delete — an Admin or Super Admin can permanently delete a request, as long as no environment has been created from it yet and it hasn't entered the provisioning stage — once a request is Provisioning or Provisioned, real build work is underway on the back of it and it can no longer be deleted. This is an admin cleanup action, not something a plain requester can do to their own request. If the request has an associated ServiceNow ticket, deleting it does not close or affect that ticket
• Clone — anyone who can raise requests can clone any request, whatever its status, into a new pre-filled one. Title, environment name, type, description, justification, software list and custom field values are carried over; attachments are not, since they belong to the original record. The reserved environment name comes across too — the live availability check will flag it if someone has taken it since. The original request is never modified
• Comments — the requester, the request's workflow approvers (on past, current, or upcoming levels), and whoever is named for the provisioning or closure stage can post; the thread stays open after the request is decided. Posting emails the requester and every approver the request has already reached, minus whoever wrote it — upcoming levels are emailed once the request reaches them, and levels assigned by role rather than to named people are not emailed
• Download documents — attached files can be downloaded from the request detail page
• Export PDF — see below

See Approvals for how request approval workflows are configured.

---

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 ticket, or hand to an auditor.

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, requester, dates, the linked environment once one exists, and any ServiceNow ticket
• The request form — every custom field group the form asks for, laid out under the same tabs as the form itself. Groups and fields left blank are printed too, marked as not provided, so the archived document says the same thing as the page it was exported from
• Software requirements — each requested package with its category, name, version and notes
• Supporting documents — listed as clickable links
• Additional forms — the forms attached during approval and what was entered in them

Only the final round of each form is included. If an approver 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. The practical consequence: if you forward the PDF to someone outside Realm9, they'll 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 Provisioning — the request's own approvers (the people who appear on its approval steps)
• Mark as provisioned — the person or role assigned to the workflow's provisioning stage
• Create Environment — 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 provisioning it once approved — not rewriting, withdrawing, or deleting it

---

Next Steps

• Manage Environments
• Configure Approvals
• Additional Forms
• Decommission an Environment