Verify a Ticket Secret Key
Build a form that only updates a ticket when the visitor supplies both the ticket number and a secret key that matches a custom field on that ticket. Anyone can open the form, but only the person who received the key for a specific ticket can submit against it.
This pattern gives you per-ticket verification without accounts or logins. It pairs well with password protection, which controls who can open the form at all.
Overview
| Piece | Purpose |
|---|---|
| Ticket custom field | Holds a unique key for each ticket. |
ticket_number and secret_key fields | What the visitor supplies. |
Verify ticket access workflow | Queries for a ticket that matches both values. |
ticket_title field | Calculated. Confirms a successful match. |
| Submission condition | Blocks the submission unless the query matched. |
Related pages:
Before You Start
- Connect Autotask. See Autotask Connections.
- Create a user-defined field on the Autotask Ticket entity to hold the key, for example
Portal Key. - Decide how each ticket gets a key. A common approach is to generate one when the ticket is created and include it in the customer's confirmation email. See Generate a Random String.
Step 1: Add the Visitor's Fields
Select the Input tab and add three fields.
| Field | Value |
|---|---|
| Name | ticket_number |
| Label | Ticket number |
| Type | String |
| Required | Checked |
| Field | Value |
|---|---|
| Name | secret_key |
| Label | Access key |
| Type | Password |
| Required | Checked |
| Description | The access key from your ticket confirmation email. |
| Field | Value |
|---|---|
| Name | note |
| Label | Your update |
| Type | Textarea |
| Required | Checked |
Using Password for the key masks it in history records.
Step 2: Create the Verification Workflow
Select the Pre-Submission Workflows tab, then select Add Workflow.
| Field | Value |
|---|---|
| Name | Verify ticket access |
| Run this workflow on | Field change |
| Recalculate when these fields change | ticket_number, secret_key |
Select Add Action and add API: Query for One Object.
| Setting | Value |
|---|---|
| Store the results in variable | ticket |
| Autotask Entity Type to Query | Ticket |
| Query conditions | All of these (AND): TicketNumber equals {{input.ticket_number}}, and UDF: Portal Key equals {{input.secret_key}} |
Leave Generate an exception if no results unchecked. A mismatch should return nothing rather than fail the workflow.
Select Save Workflow.
Because the workflow watches two fields, it waits until the visitor has filled in both before it runs.
Put both values in the query instead of comparing the key in a condition afterward. The query returns a ticket only when the number and the key belong to the same record, and the key never travels back to the browser.
Step 3: Confirm a Match to the Visitor
Return to the Input tab and add a calculated field.
| Field | Value |
|---|---|
| Name | ticket_title |
| Label | Verified ticket |
| Type | String |
| Populate this field with a Pre-Submission Workflow output | Checked |
| Pre-Submission Workflow | Verify ticket access |
| Property | custom.ticket.Title |
The visitor sees the ticket title as soon as both values are correct, and sees nothing when they are not.
Step 4: Block Submissions That Did Not Verify
Select the Advanced tab.
- Select Restrict submission with a condition.
- Set Submission behavior to Allow only if condition matches.
- Add a rule:
Workflow: Verify ticket access / custom.ticket.idis not empty.
The check runs on the server, so a visitor cannot bypass it by editing the page. A failed verification shows "This form cannot be submitted with the current values." and no actions run.
Step 5: Update the Ticket
Select the Actions tab and add the action that applies the update, such as API: Create an Object for a TicketNote on {{input.ticket_number}}.
Because the submission condition already guaranteed the match, your actions can trust the ticket number they receive.
Save the form.
Step 6: Test It
| Test | Expected result |
|---|---|
| Correct ticket number and correct key | The verified ticket title appears and the submission succeeds. |
| Correct ticket number, wrong key | No title appears and the submission is blocked. |
| Wrong ticket number, correct key | No title appears and the submission is blocked. |
| Both correct, then the key edited in the browser before submitting | The submission is blocked, because the server re-verifies. |
Hardening Notes
- Use a long random key. Twelve or more mixed characters from Generate a Random String is a reasonable starting point.
- Issue a new key per ticket. Do not reuse one key across tickets or customers.
- Public form endpoints are rate-limited per IP address, which slows down guessing, but a short key is still guessable given time.
- Add password protection when the form itself should not be publicly readable.
Next Steps
- Show a help message when verification fails, using a text field with Conditional Visibility that checks the workflow property is empty.
- Apply the same pattern to other records by querying a different entity and custom field.