Create an issue in Jira through the Create form, completing the required fields before submitting. Check the saved ticket before sharing its link.
This guide covers creating a single ticket in Jira Cloud, with a copyable description, a worked bug example, and checks for common problems. Your administrator’s configuration and Jira product can change the fields and labels you see.
Check the saved Jira issue before sharing it
Completing the Create form is the start of the handoff. After submitting, open the saved work item and inspect the destination, description, evidence, and next owner. This prevents a clear report from becoming unusable because it was created in the wrong space or linked to inaccessible evidence.
| Check | What to confirm |
|---|---|
| Destination | The intended space/project and work type are saved. |
| Description | Starting state, steps, expected result, and observed result remain readable. |
| Evidence | The intended recipient can open the recording or attachment. |
| Ownership | Routing or assignment follows the team’s triage procedure. |
| Original case | The support ticket links to Jira and the Jira description references the case. |
This guide covers the visible Jira Cloud creation workflow. Creating a work item through the API is a separate automation task with its own authentication, payload, and error handling; do not paste an API example into the user-interface form. Use the bug-field guide to improve a defect description.
Jira issues, work items, tickets, and tasks
Atlassian’s current Jira Cloud documentation uses work item, space, and work type. You may still see issue, project, and issue type in your interface or team documentation. See Atlassian’s terminology update. “Ticket” is a common informal name; a task is a category of work rather than a different way to submit it.
How to create an issue in Jira Cloud
- Select Create (+) in the navigation.
- Check the Space and Work type in the dialog header. Older labels are Project and Issue type.
- Enter a Title, formerly Summary, and a Description.
- Complete required fields and relevant optional fields. Expand to the full form when you need additional fields.
- Select Create. Review prefilled values before using Create another.
These steps follow Atlassian’s creation guide. Its new Quick Create experience does not yet apply to Jira Service Management or Jira Product Discovery. Use your product’s visible form and administrator guidance when the interface differs.
Decide what the ticket should contain
Before entering details, ask: what does the next person need to understand the work and take an appropriate first action? A long description is not useful if it leaves the actual problem unclear.
| Detail | What to provide | Example |
|---|---|---|
| Title or summary | A specific action, failure, or outcome. | Export button returns an error for saved CSV reports. |
| Context | Where and when the problem occurs. | Reports page, test workspace, current release. |
| Expected result | What should happen. | A CSV file downloads with the selected columns. |
| Actual result | What you observed. | An error appears and no file downloads. |
| Impact | Who or what is affected, with known limits. | Reproduced in one test workspace; wider scope unknown. |
| Evidence | Relevant steps, images, recordings, or diagnostic details. | A short recording and the visible error text. |
| Next action | A clear request or completion condition. | Investigate export failure and verify a successful download. |
Follow your team’s rules for ownership and priority. Explain the observed impact instead of labeling every problem urgent. If you do not know the assignee, route the ticket through the agreed triage process.
Copyable Jira ticket description
Context: Requested outcome or problem: Environment / affected version: Starting state: Steps or work to complete: 1. 2. 3. Expected result: Actual result (for a bug): Observed impact and scope: Frequency / reproducibility: Evidence and related links: Known workaround or investigation: Completion / verification criteria: Open questions:
Adapt the template to the work. For a task, describe the deliverable and completion criteria. For a bug, preserve the starting state, reproduction steps, and expected versus actual behavior. Our bug-report templates provide more reporting formats.
Worked example: a reproducible export bug
The following is an illustrative report, not a real customer incident.
Title: Saved report fails to export as CSV Context: Reports page in a test workspace. Environment: Chrome on Windows; affected app release recorded in the ticket. Starting state: Signed in with access to a saved report containing test data. Steps: 1. Open Reports and select the saved report. 2. Select CSV as the export format. 3. Select Export. Expected: A CSV file downloads with the selected report data. Actual: An error message appears; no download starts. Frequency: Reproduced on three consecutive attempts in this test workspace. Impact: Export is blocked for this report; wider scope is not yet established. Evidence: Short recording, exact error text, and attempt timestamps. Workaround: None verified. Verification: Repeat these steps after the fix and check the downloaded file.
Do not infer a root cause from the symptom. “Export fails” is an observation; “the database is broken” is a hypothesis until the investigation supports it. For other examples, see our filled bug reports.
Add evidence without losing the written explanation
Jira supports attachments through the work item’s attachment control or by dragging a file onto it. Attachment permissions and configured file-size limits can affect uploads. Follow Atlassian’s attachment instructions if the control is missing or the file is rejected.
A short recording is useful for a sequence, timing problem, or confusing navigation. Keep the relevant starting state and result visible, include written steps, and remove unrelated customer information. Check that the recipient can open any linked recording.
Screendesk’s Jira recording workflow can help share visual evidence alongside an issue. The evidence should make the report easier to reproduce; it does not replace the description or guarantee a faster fix.
Check the ticket after creation
- Open the saved record and confirm that the title and description are complete.
- Check the destination team and work category.
- Verify that the evidence is available to the intended audience.
- Confirm who owns triage or the next action.
- Share the ticket link through your team’s usual handoff.
- Keep later findings in the same record, distinguishing tested results from assumptions.
Search for an existing report before creating a second ticket for the same problem. If a related record already exists, follow your team’s linking or duplicate-handling process and contribute any new evidence.
Troubleshooting ticket creation
| Problem | What to check |
|---|---|
| The destination is missing. | Confirm the Jira site and team destination, then ask the administrator to review your access. |
| The form will not submit. | Read the validation message and complete or correct the identified field. |
| A field is missing. | Check that you selected the intended work category and whether the full form exposes it. Ask the administrator about the configured fields. |
| An attachment fails. | Check the upload error, permitted size, and attachment access. Preserve the written report while investigating. |
| A saved ticket is not on the expected board. | Open its direct link and ask the board owner to check the board’s selection criteria before creating another ticket. |
Creation depends on appropriate access. Jira’s permissions can govern actions such as creating work items and adding comments; see Atlassian’s permission overview. Give your administrator the site, destination, attempted action, and exact error so they can investigate.
Frequently asked questions
How do I create a Jira ticket for a bug?
Use the creation steps above and the bug category your team has configured. Include reproducible steps, expected and actual results, environment details, impact, and evidence. Check the saved ticket and hand it to the agreed triage owner.
Why does my Jira say work item instead of issue?
Jira Cloud’s terminology has changed. The underlying purpose is still to describe and track work. Use the labels visible in your site and keep your team’s documentation consistent with them.
Should every ticket have a screenshot?
No. Add evidence that explains the work. A screenshot can show a static error; a recording can show a sequence. A clear written description is still useful when there is nothing visual to capture.
What should I do if I created the wrong ticket?
Follow your team’s correction or duplicate-handling process. Record what happened and preserve relevant discussion. Ask the destination owner or administrator for help when you cannot make the required change.
