Request presets & templates

Two things speed up creating requests: templates define what is collected, and presets define how a request is set up.

Field templates

A template sets which fields the subject fills in. Everything they enter, usernames included, is encrypted in their browser, and each field is shown separately with its own copy button when you reveal.

The built-in templates include:

Username and password — username, password and an optional website or system.
Windows password — the password, with an optional username.
Email account and Microsoft 365 / Entra account — the sign-in address and password.
Remote desktop / server login and VPN access — the address, username and password.
BitLocker recovery key — the 48-digit key. The hyphens are added as the person types, a pasted key works with or without them, and each group is checked against the key’s built-in check digits before it’s sent, so a mistyped digit is caught on the spot.
Wi-Fi passphrase, API key / token and Software licence key.
Custom — a single field you name when you create the request (for example Door code). It’s typed into a hidden box with a Show button.

Password fields get a strength meter and show/hide. You pick a template when creating a request.

Preview next to a template (on the new request form, presets, campaigns and Settings → Field templates) shows the secure page exactly as the person will see it, with your client’s branding. Nothing you type in the preview is sent.

The default template

New requests start on your organisation’s default template unless a preset picks another. A new organisation starts on Custom. An Owner or Admin can choose a different one under Settings → Field templates with Make default; the current default is marked Default.

Your own templates

An Owner or Admin can add templates under Settings → Field templates: give it a name and up to 12 fields, each a text, password or multi-line field, required or optional, in the order you want them. A text field can use the BitLocker recovery key format, which formats and checks it as above. Duplicate copies a built-in template as a starting point. Your templates appear in the template list for everyone in your organisation, and presets can use them.

Editing a template that has already been used saves a new version: requests already sent keep the fields they were sent with, and presets switch to the new version. A template a preset uses can’t be removed until the preset uses another one.

Presets

A preset is a saved bundle of request options — field template, justification, expiry, verification, extra recipients, attachments and delivery method — so you don’t set them each time. Everything stays editable after you apply one.

Presets are managed by an Owner or Admin under Settings → Request presets, and can be scoped to a specific client. A preset is checked against your policy when it’s saved: its expiry must be one of the allowed options and its verification at least the minimum. They’re what makes two things possible:

One-step requests — apply a preset and just add the subject and ticket.
Request from a ticket — a ticket link opens the New request form with a named preset applied, or a helpdesk automation fires a named preset to create the request with no one opening SafeHanded.

The preset’s slug

Each preset gets a slug generated from its name — Password reset becomes password-reset (a second preset with the same name gets password-reset-2). Ticket links, helpdesk automations and the API refer to a preset by its slug, for example /app/requests/new?preset=password-reset or "preset": "password-reset".

The slug is fixed when the preset is created: renaming the preset doesn’t change it, so existing links and automations keep working. Each preset’s slug is shown next to it on Settings → Request presets, with a copy button — copy it from there when you set up a ticket link.

Default presets

When a request is started without naming a preset — a ticket link without &preset=, the New request button, the API or a ticket automation — SafeHanded uses the client’s default preset, then the organisation default, and otherwise the policy defaults. If a ticket automation has its own default preset, that comes first for the requests the automation creates.

Organisation default: choose it on Settings → Policy → Requests & reveal → Default preset for new requests. Ticking Organisation default when editing a preset, or Set default on the Presets page, sets the same thing. Only organisation-wide presets can be the organisation default.
Client default: a preset scoped to a client can be that client’s default.

Example presets

“Password reset” — short expiry, either code, email the link to the subject.
“New starter setup” — longer expiry, both codes, the onboarding team as extra recipients.