Known issues

This page lists what you, your agents or your requesters may notice in Intake Standards, why it happens and what to do about it. Some of it comes from limits of the Atlassian platform and of Forge UI Kit, in which the app's screens are built; the rest is known behaviour of the app. What happens when the model, Atlassian-hosted AI (Forge LLMs), cannot answer a check is on When the check cannot run.

On the settings page

Fast typing loses characters

When you type very quickly into a check's label, met-when rule or hint, characters can be lost. Every keystroke in a UI Kit text field makes a round trip between the page and the app, and keys typed faster than about 100 ms apart can be dropped. Type at a normal pace or paste the text in, and read it back before you save.

A save takes a few seconds to show

After you save a draft or enable or disable a version, the page takes 3 to 5 seconds to show the change: the write and the list read after it are separate round trips. Wait for the flag before you act again.

Focus moves to Reload after a change on the Versions tab

After a change on the Versions tab, such as enabling a version, keyboard focus lands on Reload in the toolbar. Nothing inside a UI Kit table cell can take focus, so the page moves it to a control outside the table. Continue from Reload with Tab.

A narrow window scrolls sideways

The page has minimum widths and does not wrap. In a column narrower than 596 pixels it scrolls sideways; the Versions table needs 600 pixels and the Run log 700. Widen the window or zoom out.

Evaluate stops at 200 a day

The Evaluate tab refuses further checks after 200 in one calendar day (UTC) for your installation. Every run counts, including one that fails or is under the word minimum. It draws on the same model allowance as your requesters. The count starts again at 00:00 UTC.

On the customer portal

An open form keeps its version

After you enable a new version, a requester whose form was already open is checked against the version that form loaded, and the run log records that version. The form takes the new version when it is reloaded. No action is needed.

Not saved, although the text was saved

After Send, the field can show "Not saved". The portal takes a field's value from a save made during Send, so the field saves its value again on every Send. When that repeat save fails, the notice appears although the same value was already saved. The same notice also shows when a first save fails, so a requester who sees it should check again and send, as the notice asks.

Earlier text is still saved

When a requester edits text that has already passed, the field takes the saved value back. If the portal refuses that, the field shows "Earlier text is still saved", and the earlier, complete text is what will be sent unless the requester restores it or the new text passes.

A skip rule that arrives late

When the form receives the standard's skip rule only after the first check has run, that check shows the blocking message and red border although the standard lets requesters skip. The rule applies from the next check or Send. The count of failed checks is kept, so only the wording is affected.

In advisory mode, a Send straight after an edit

While advisory mode is on, a requester may edit the text and press Send before the check that started when they left the box has finished. The request is then sent with the text from before the edit, because Send waits for the running check instead of starting a new one. Sientus Solutions switches advisory mode on during an incident. Requesters who wait for the checklist to update are not affected.

The same words twice above the box

The request form shows the field's display name, and the standard supplies the label above the box. When the two match, the same words show twice. Keep the display name short and different from the box label; "Intake details", as shipped, works.

In the agent view

A slow check on the create dialog or a transition screen

On the agent create dialog and on transition screens the field submits its value only once the check has finished, and Jira waits only a limited time, about 10 seconds by our reading, for a field to supply its value. A check that needs its second attempt can take longer, and its value may then not be saved with the work item. Let the checklist show its result before you press Create or move the work item on. On these screens the checklist is guidance only and never blocks.

With other Jira features

JSM Forms

Forge fields cannot be linked to JSM Form questions, so a Form cannot carry Intake details. Keep any Form attached to the request type clear of Description, which stays hidden on the request form.

Jira Customer Service Management

Its portal does not render Forge fields yet, so Intake details cannot appear there. Intake Standards works on the Jira Service Management customer portal.

Automation rules that write Description

On creation the app reads whether Description is empty a few round trips before it writes the text there. An Automation rule that writes Description in between is overwritten; a rule that wrote it before the app's read keeps its text. Avoid rules that set Description on creation for these request types. The requester's text stays in Intake details either way.

Reporting a problem

Report anything not listed here through Support. Say which screen you were on, the work type, when it happened and, for a request, its key.