Hardware
Request
A catalogue item allowing Crestline employees to request hardware equipment — with a manager approval gate before any fulfilment task is generated, and three branded notification emails covering submission, approval, and rejection.
CompleteOverview
The Hardware Request is the second catalogue item built for the Crestline IT Requests catalogue. It allows employees to request hardware equipment and introduces a manager approval gate — no fulfilment task is created until a manager explicitly approves the request. Three branded notification emails cover the full lifecycle: submission, approval, and rejection.
What I built
01
Catalogue item & variables
Six variables covering the requester, hardware type, specification, business justification, required by date, and additional information — with auto-populate and conditional mandatory logic.
02
UI Policy — conditional mandatory
When Hardware Type is set to Other, the Specification field becomes mandatory — ensuring the IT team always have enough information to fulfil the request.
03
Flow Designer — approval workflow
A Flow Designer flow with Ask for Approval, If/Else branching, Create Catalog Task on approval, and Update Record on rejection — demonstrating a complete approval chain.
04
Three branded notification emails
Submitted, Approved, and Not Approved notifications — each following Crestline brand guidelines with navy header, teal callout section, and consistent footer.
05
Catalogue category structure
Hardware Request sits under IT Requests > Hardware in the catalogue hierarchy — giving the portal a logical, scalable structure alongside Account & Access.
06
Client Script auto-populate
An onLoad Client Script pre-populates the Requested for field with the logged-in user — consistent with the Password Reset item and reducing form friction.
Variable design
| # | Variable | Type | Notes |
|---|---|---|---|
| 1 | Requested for | Reference | References sys_user table. Auto-populated via onLoad Client Script. Mandatory.
Editable so managers can request on behalf of others. |
| 2 | Hardware type | Select Box | Six choices: Laptop, Desktop computer, Monitor, Keyboard & Mouse, Headset, Other (specify below). Mandatory.
Controls the conditional mandatory state of the Specification field. |
| 3 | Specification | Single Line Text | Optional by default. Becomes mandatory when Hardware Type = Other via UI Policy with Reverse if false.
Allows users to specify a preferred model or describe non-standard requirements. |
| 4 | Business justification | Multi Line Text | Mandatory. Gives the approving manager the context needed to make an informed decision.
Surfaces on the approval task so managers can see justification without opening the full request. |
| 5 | Required by date | Date | Optional. Allows IT to prioritise time-sensitive requests and plan procurement accordingly. |
| 6 | Additional information | Multi Line Text | Optional free-text field for any further context the user wants to provide. |
Form — portal view
Screenshot 01
Hardware Request form — default state
The form on load — Requested for pre-populated, Hardware Type defaulting to Laptop, Specification hidden, Business Justification mandatory, date picker for Required by date.
Screenshot 02
Hardware Request form — conditional state
Hardware Type changed to "Other (specify below)" — the Specification field appears and becomes mandatory, driven by the Catalog UI Policy with Reverse if false.
Screenshot to be added
Hardware Type = Other — Specification visible and mandatory
Design decision
The Specification field is optional for standard hardware types where the IT team can make sensible default choices. It only becomes mandatory for Other — where without a description the request cannot be fulfilled. A single UI Policy with Reverse if false handles both states cleanly.
Screenshot 03
Order confirmation
The portal confirmation screen after submitting — showing the request reference number and confirming it has been logged and sent for manager approval.
Screenshot to be added
Order confirmation with request reference
Fulfilment — Flow Designer
Screenshot 04
Hardware Request Fulfilment flow
The Flow Designer canvas showing the complete approval and fulfilment flow — triggered by a Service Catalog submission, with an Ask for Approval action followed by If/Else branching to handle approval and rejection paths independently.
Flow structure
Trigger — Service Catalog
Fires when any Service Catalog request is submitted. The flow is scoped to Hardware Request via the Process Engine tab on the catalogue item.
Service Catalog triggerAsk For Approval
Sends an approval request to the requester's manager. The flow pauses here until the manager approves or rejects. Approval reason, approval field, and journal field all configured.
Anyone approves ruleIf — Approval State is Approved
Branches based on the Approval State output from the Ask for Approval action. If approved, the flow continues to task creation. If not, it falls to the Else branch.
Flow Logic — If/ElseCreate Catalog Task (approved path)
Creates a fulfilment task assigned to the IT Service Desk with instructions and all submitted variable values visible on the task record.
Approval pathUpdate Requested Item Record (rejection path)
Updates the request stage to cancelled and adds a work note explaining the request was not approved — keeping the record clean and auditable.
Rejection pathNotification approach
User notifications for all three states (submitted, approved, rejected) are handled by separate Notification records rather than Send Email flow actions. This keeps the flow focused on business logic and makes notification templates independently maintainable — consistent with the approach used on the Password Reset item.
Notifications — three branded emails
Screenshot 05
Submitted notification
Sent immediately on submission — confirms the request has been received and is awaiting manager approval. Sets clear expectations about the timeline and next steps.
Screenshot to be added
Submitted notification preview
Screenshot 06
Approved notification
Sent when the manager approves the request — confirms approval and notifies the user that the IT Service Desk will be in touch to arrange fulfilment.
Screenshot to be added
Approved notification preview
Screenshot 07
Not approved notification
Sent when the manager rejects the request — acknowledges the decision without being confrontational and provides three clear next steps for the user to follow.
Screenshot to be added
Not approved notification preview
Communication design
The rejection email deliberately avoids the word "rejected" — using "not approved" instead. This is a real consideration in service desk communication design: reducing friction and anxiety for users while still being clear about the outcome. The three numbered next steps give the user a clear path forward rather than leaving them with no guidance.
Catalogue structure
Screenshot 08
IT Requests catalogue page
The catalogue page showing both Hardware Request and Password Reset under the IT Requests parent category — demonstrating a structured, scalable catalogue hierarchy with subcategories for Account & Access and Hardware.
