Letting requesters skip
By default, the customer portal holds a request back until every check is met, however many times the requester tries. Some teams would rather take an incomplete request than lose it: a requester who has checked three times and still misses a check may simply not know the answer. The skip rule lets requesters send the request anyway, at once or after a number of failed checks. It belongs to one version of one standard, so you set it per work type.
Why a desk uses it
A strict standard can lose a request whose requester cannot answer a check. The skip rule trades that loss for an incomplete request that arrives labelled, with the checks not met recorded in the run log, so reviewers know what to ask for. "After N failed checks" keeps the standard firm for requesters who can meet it with a little more effort. "Immediately" turns the checklist into guidance on the portal while every incomplete request is still flagged.
The three settings
Open the draft on the Checks tab. The skip rule sits in the footer, under the word minimum.
| Setting | What it does |
|---|---|
| Allow requesters to skip the checks and send the request | A checkbox. Left unticked, the standard has no skip rule. This is the default. |
| When | "Immediately" or "after N failed checks". Ticking the box selects "after N failed checks". |
| N= | The number of failed checks, a whole number from 1 to 99. It starts at 3. |
A helper line under the row describes the option you chose. For "immediately" it reads "Requesters see the checks but can always send the request. Requests that do not meet every check are labelled intake-unverified." For "after N failed checks" it reads "A text under the minimum words does not count as a failed check. Requests that do not meet every check are labelled intake-unverified."
An N outside the range shows "N must be a whole number between 1 and 99." Unticking the box keeps your choice for the rest of the edit but saves no rule. Enabled and retired versions show the rule read-only as Skip checks: "Not allowed", "Immediately" or, for example, "After 3 failed checks".
How the count works
With "immediately", requesters may skip from the start. With "after N failed checks", the portal field counts:
- A failed check is a fresh run in which the model, Atlassian-hosted AI (Forge LLMs), judged the text and found at least one check not met.
- A text under the word minimum does not count. The model never read it, and counting it would let a requester reach N without writing anything worth reading.
- An unverified result neither counts nor resets the count.
- Checking unchanged text reuses the earlier result and does not count again.
- A pass resets the count to 0.
When the count reaches N, the check that reached it is let through at once: its value is saved and the portal's Send becomes available. From then on the requester may skip for as long as the form stays open, even if a later edit turns a pass back into a fail. The count lives in the requester's browser and starts at 0 every time the page loads.
At Fernhill Logistics, a fictional company, the access desk sets "after 2 failed checks". A requester writes 9 words, which is under the minimum, so nothing counts. They add detail and check: two checks are not met, the count is 1, and the request is still held back. They add one more fact and check again: one check is still not met, the count reaches 2, and they can send the request.
What the requester sees
Requesters hear nothing about the rule until it applies. Then the messages change and the box loses its red border. For a standard with six checks and a minimum of 40 words:
| Situation | Title | Before the rule applies | Once it applies |
|---|---|---|---|
| A check not met | Some information is still missing | Cover the checks marked Not met, then check again. The request can be sent once every check is met. | You can send the request without meeting every check. The support team may contact you for more information. |
| Under the minimum | Add a little more detail | Write at least 40 words so the check can run. Cover the 6 checks next to the box. | Write at least 40 words so the check can run, or send the request as it is. The support team may contact you for more information. |
The messages for a pass, an unverified result, a check under way and edited text do not change.
What happens to a request sent this way
A request sent under the skip rule is stored as a fail, like any request that did not meet every
check. On the work item the field shows Incomplete, the label intake-unverified brings it into a
review queue that filters on that label, "Intake details".Status = fail finds it in JQL, and its
run on the Run log tab is linked to the request key.
The internal note names the bypass, so agents see that the requester used the rule rather than a plain failure:
Intake Standards: the user bypassed the completeness check after 3 failed attempts as permitted by intake standard v4 for work type Service request.
With "immediately", the note leaves out the attempts clause: "…bypassed the completeness check as permitted by intake standard v4 for work type Service request." The number in the note is the rule's own threshold, read from the stored version, because nothing on the server can confirm a count the browser reports. It can understate how often the requester tried. If the version cannot be read, does not belong to the work item's project and work type, or carries no rule, the note is the usual one for a request that did not pass.
Changing the rule
The rule is part of the version. You set it in the draft, and it takes effect when you enable that version. Compare lists a changed rule the way it lists a changed minimum, for example "Before: Not allowed · After: After 3 failed checks". To remove the rule, untick the box in the draft and enable that version. A form that is already open keeps the rule of its version until the page is reloaded. Templates and Start empty carry no rule, so a new standard never starts with one.
The agent view and advisory mode
The skip rule acts on the customer portal only. The agent view never blocks, so an agent creating or editing a work item is never held back by a check, with or without a skip rule. In advisory mode, nothing blocks on the portal either, and the rule has nothing to add: requesters can always send, and the failing check tells them reviewers will probably come back with questions.