Password
Reset
A self-service catalogue item allowing Crestline employees to request a password reset without contacting the service desk directly — with dynamic form logic, automated fulfilment, and a branded notification email.
CompleteOverview
The Password Reset catalogue item is the first item built under the Account & Access subcategory in the Crestline IT Requests catalogue. It allows any Crestline employee to submit a password reset request directly from the self-service portal — covering their network login, email, VPN, or a specific application.
The form uses dynamic variable logic to show or hide the Application Name field depending on what account type the user selects — keeping the form clean and only asking for information that is actually needed. On submission, a fulfilment task is automatically created and assigned to the IT Service Desk, and the user receives a branded notification email that also signposts them to a self-service password manager for future use.
This item demonstrates the full end-to-end lifecycle of a service catalogue request — from what the end user sees, through to automated task creation and user communication.
What I built
01
Catalogue item & variables
Five variables covering the requester, account type, application name, urgency, and additional information — with sensible defaults and mandatory field validation.
02
Dynamic UI Policy
A Catalog UI Policy shows and hides the Application Name field based on the Account Type selection — with Reverse if false handling both states from a single policy.
03
Client Script auto-populate
An onLoad Client Script pre-populates the Requested for field with the logged-in user — reducing friction for the most common use case while keeping the field editable for managers.
04
Flow Designer fulfilment
A Flow Designer flow triggered by Service Catalog submission automatically creates a Catalog Task assigned to the IT Service Desk with fulfilment instructions and all submitted variable values.
05
Branded notification email
A ServiceNow Notification record sends a branded HTML email on submission — confirming the request and signposting the user to a self-service password manager to reduce future contacts.
06
Catalogue structure
The item sits within a structured catalogue hierarchy — IT Requests > Account & Access — giving the portal a logical navigation structure that scales as more items are added.
Variable design
| # | Variable | Type | Notes |
|---|---|---|---|
| 1 | Requested for | Reference | References sys_user table. Auto-populated via onLoad Client Script with the current logged-in user. Mandatory.
Editable so managers can request on behalf of others. |
| 2 | Account Type | Select Box | Four choices: Network / Windows login, Email (Microsoft 365), VPN, Application (specify below). Defaults to Network. Mandatory.
Controls the conditional display of the Application Name field. |
| 3 | Application Name | Single Line Text | Hidden by default. Shown and made mandatory only when Account Type = Application via UI Policy.
Demonstrates conditional variable logic — a key catalogue design skill. |
| 4 | Urgency | Select Box | Three choices: Normal, Urgent, Account locked out. Defaults to Normal. Mandatory.
Allows the IT team to prioritise locked out accounts without any manual triage. |
| 5 | Additional Information | Multi Line Text | Optional free-text field for any additional context the user wants to provide. |
Form — portal view
Screenshot 01
Password Reset form — default state
The form on load — Requested for pre-populated with the logged-in user, Account Type defaulting to Network / Windows login, and Application Name hidden. Urgency defaults to Normal.
Screenshot 02
Password Reset form — conditional state
Account Type changed to "Application (specify below)" — the Application Name field appears and becomes mandatory, driven by the Catalog UI Policy with Reverse if false enabled.
Design decision
A single UI Policy with Reverse if false handles both show and hide states — keeping the configuration lean. A separate hide policy would work but adds unnecessary complexity for a binary condition.
Screenshot 03
Order confirmation
The portal confirmation screen after clicking Order Now — showing the request reference number and confirming the submission was received.
Fulfilment — Flow Designer
Screenshot 04
Password Reset Fulfilment flow
The Flow Designer canvas showing the complete fulfilment flow — triggered by a Service Catalog submission, with a single Create Catalog Task action that assigns the task to the IT Service Desk with fulfilment instructions and all submitted variable values.
Architecture decision
User notification is handled by a separate Notification record rather than a Send Email flow action. This keeps the flow lean and makes the notification independently maintainable — changes to the email template don't require editing or reactivating the flow.
Notification — branded email
Screenshot 05
Notification email
The branded HTML notification email rendered in the ServiceNow notification preview — showing the Crestline header, REQUEST RECEIVED label, centred heading, intro text, the teal self-service callout box with CTA button, three-step self-service guide, and the Crestline navy footer.
Self-service deflection
The notification deliberately signposts users to a self-service password manager — a real ITSM strategy that reduces repeat contacts to the service desk. The email confirms the request is being handled while simultaneously encouraging the user to self-serve next time. This mirrors what a mature service desk would actually deploy.
Up next
Next →
Hardware Request
Conditional variable sets and a manager approval gate before fulfilment tasks are generated.
Later →
New Starter Request
Multi-team fulfilment with parallel tasks assigned to IT, HR, and Facilities via Flow Designer.