The public request form

The portal is for contacts you’ve given access to. The public request form is for everyone else — a page a complete stranger can raise a ticket from, with no account, no invitation and no sign-in.

It’s the right answer for a “Contact support” link on your website. It’s the wrong answer for your existing customers, who should be in the portal where they can see the history.

What it asks

Deliberately little: name, company, email address, an optional partner name for requests coming through a reseller, and the product or service impacted. Depending on which product is picked, a few follow-up questions appear.

The product picker is doing more work than it looks. It’s what routes the request to the queue that handles that product, so the form’s own hint — “picking the right one gets your ticket to the team that handles it fastest” — is the literal truth rather than encouragement.

Submitting gives the requester a ticket number immediately, and the ticket lands in the routed queue like any other.

The product list is fixed

The products on this form are defined in the application, not in your settings — there’s no admin screen for them. If yours are different, that’s a change to the app rather than something you can configure, so raise it rather than looking for the setting.

It’s off until you turn it on

The form is disabled by default. An admin enables it with the support.public_intake_enabled feature flag, and the Service Desk module has to be on as well.

While it’s off, the URL responds exactly as an unknown organization’s would. That’s on purpose: an “off” response that differed from a “no such organization” response would let anyone with the URL confirm you’re a customer here.

What stops it being a spam funnel

An unauthenticated form that creates records is an obvious target, so there are two quiet gates:

• A honeypot field no human ever sees. Anything that fills it in was filling in every input on the page.
• A minimum time between loading the form and submitting it, proven by a signed stamp the page issues. A script POSTing straight at the endpoint has no stamp; a replayed one has expired.

Both respond with the same success page a real submission gets. Telling a bot which gate caught it is how the next version gets past it — and there’s no human being misled, because a human never trips either.

You don’t need to do anything to keep these working. It’s worth knowing they exist, though, if you’re ever testing the form yourself and wondering why a very fast submission didn’t appear: fill it in at human speed and it will.