# Jira issues from defects > Create or link Jira issues from Probara defects, and keep them in sync with Jira in both directions. When a project is mapped to Jira, every defect gets a **Jira** card. From it you can create a Jira issue prefilled with what the tester recorded, or link an issue that already exists. Afterwards the two stay in sync both ways: status, priority, severity and comments changed in Probara reach the Jira issue, and changes made in Jira come back to the defect. This assumes a Jira site is connected and the project maps at least one Jira project, with its own mapping or the organization's default mapping; see [Jira Cloud integration](https://docs.probara.net/en/guides/integrations/jira/). ## Who can do what | Action | Who | | --------------------------------------- | -------------------------------------------------------- | | See the Jira card and its linked issues | Anyone who can open the defect | | Create, link, refresh and unlink issues | Members, admins and owners (anyone who can edit defects) | | Connect sites and map projects | Owners and admins | All of it requires a paid plan. ## Create a Jira issue from a defect 1. Open the defect. The **Jira** card sits below **Affected cases**. 2. Select **Create Jira issue**. 3. Check the choices: - **Jira project** — the project's default mapping is preselected. - **Issue type** — the mapping's issue type is preselected. - **Result context** — the test result whose run, steps, environment and configuration go into the issue. The defect's most recent linked result is preselected; choose **No result** to leave them out. - **Include attachments** — checked by default. 4. Select **Create issue**. A confirmation appears with **Open in Jira**, and the issue is listed on the card. If Jira requires fields that the project's mapping does not fill, the dialog shows **Jira needs more fields** with exactly those fields. Fill them in and select **Create issue** again. If Jira refuses the issue for another reason, the dialog lists Jira's own messages. ### When Jira does not answer: "Confirming with Jira…" Sometimes Jira creates the issue but its answer never reaches Probara (a timeout or a network failure). Creating again could file the bug twice, so Probara does not. Instead: 1. The dialog shows **Confirming with Jira…** with a countdown. Meanwhile Probara searches Jira for the issue it asked for — after 30 seconds, 2 minutes and 10 minutes, because Jira's search can take a while to see a new issue. 2. If the issue turns up, Probara links it to the defect exactly as a normal create would, and the dialog shows it. 3. If it has not turned up when the countdown ends, the dialog offers **Check again** and **Create anyway**. **Create anyway** asks you to confirm, because it may create a duplicate if Jira did create the first issue. The same protection covers two people creating an issue for the same defect at once: the second one sees "A Jira issue is already being created for this defect." and should check the linked issues in a moment. ## Create it while reporting a defect from a run In the **Report defect** modal, when you report a defect against one result, check **Also create a Jira issue**. Its hint names the Jira project the issue goes into — the project's **default** Jira project, so the option appears only when the project has one. Probara remembers your choice for that project in this browser. The issue is filed right after the defect is saved, with that result and its attachments. If Jira fails, **the defect is still created**: a message explains why the Jira issue was not, and you can retry with **Create Jira issue** on the defect. If Jira's answer is lost, a message says the defect was created and Jira is still confirming its issue: check the defect's **Jira** card in a minute. The option is not offered when reporting against several results at once, or when adding the result to an existing defect. ## What the Jira issue contains | Part | Content | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Summary | The defect title (up to 255 characters). | | Description | The defect description; the defect number, severity and priority; who reported it via Probara. | | Test result (when a result is chosen) | The run (linked), the test case, the result status, environment, configuration, who executed it and when, and the tester's comment. | | Steps (when a result is chosen) | A table of every step with its action, expected and actual result and status; the failed step is highlighted. | | Link back | **View in Probara**, pointing at the defect. | | Priority, severity, other fields | As set in the project's mapping. | Jira limits a description to 32,767 characters. A longer defect is shortened to fit, and the issue says _Description truncated to fit Jira; the full defect is in Probara._ The issue also gets a **Probara** link in Jira's links section, pointing back to the defect. ### Attachments With **Include attachments**, Probara uploads the defect's attachments plus the chosen result's attachments and step attachments. Files larger than **32 MB** stay in Probara; the description says how many. Uploads happen in the background within a few moments of creating the issue, so they may appear in Jira slightly after the issue itself. ## Link an existing issue 1. On the **Jira** card, select **Link existing issue**. 2. Type words from the issue summary to search the Jira projects mapped to this project, or paste an issue key such as `WEB-12` and select **Link WEB-12**. 3. Pick the issue. Issues already linked to this defect are shown as **Already linked**. You can link several Jira issues to one defect. The search is plain text: it is not JQL, and only searches mapped, allowed projects. ## Refresh or unlink - **Refresh** reads the issue from Jira now and updates its summary, status, priority and type on the card. You rarely need it for that: Jira sends changes on its own. It is also the **Try again** for a **Sync error**: changes Probara had given up sending are queued again (the card then reads **Sync pending**), and ones that can never succeed — such as a file Jira refused — are cleared. If a change fails again, the card shows the error again; a refresh never hides one. - **Unlink** removes the link from the defect after you confirm. **The issue stays in Jira**; Probara removes its own link and marker from it. Deleting a defect unlinks all of its Jira issues the same way. An issue that was being created for it stays in Jira, without the Probara link. ## What the card tells you | Sync line | Meaning | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Synced** _time ago_ | The card shows Jira's values as of that time. | | **Sync pending** | A change is on its way. | | **This issue was deleted in Jira.** | The issue no longer exists. The defect is untouched; select **Unlink** to stop tracking it. | | **Sync error:** _reason_ | Probara gave up sending a change to Jira (for example, the app lost access to the project, or the workflow refused). Fix the reason, then **Refresh**. | ## What syncs back from Jira Jira sends Probara a notice whenever a linked issue changes, usually within seconds and at most a few minutes later. Probara applies only what actually changed: | Change in Jira | Effect in Probara | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Status | The defect status follows the project's status mapping. With the default mapping, moving to a Done status resolves the defect and, if it has no resolution yet, sets one from Jira's resolution ("Won't Do" and "Won't Fix" → Won't fix, "Cannot Reproduce" → Cannot reproduce, anything else → Fixed). Moving a resolved issue back reopens the defect. | | Priority | The defect priority follows the project's priority mapping. A Jira priority with no match changes nothing. | | Severity field | If the mapping carries severity in a Jira field, the defect severity follows it. | | Summary | Shown on the card. **The defect title does not change.** | | New or edited comment | Copied to the defect's comments. Comments restricted to a Jira group or role are never copied. | | Deleted comment | Its copy is deleted from the defect. | | Issue deleted | The link shows **This issue was deleted in Jira.**; the defect does not change. | Rules that keep the defect trustworthy: - If the project has **no mapping** for the issue's Jira project, the defect does not change; only the card updates. - Notices can arrive late or out of order. A notice older than the last one applied is ignored. - Changes from Jira appear in the defect's history as made by the system, marked as coming from Jira. A status change from Jira notifies the defect's reporter, like any other status change. - Comments copied from Jira show their author as "_Name_ (Jira)", or "Jira user" when Jira does not share the name. They can be edited only in Jira; owners and admins can still delete the copy in Probara. ## What Probara sends to Jira Changes made in Probara to a linked defect reach the Jira issue within moments: | Change in Probara | Effect in Jira | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Status | The issue moves to the Jira status the project's mapping names for the new status, through your Jira workflow. A status left on **Don't change** moves nothing. | | Priority or severity | The issue's priority, or the severity field, is set to the mapped value. A value with no match is not sent. | | New comment or reply | A Jira comment "_Your Name_ (via Probara):" followed by the text. Mentions read as `@Name`, and an image arrives as a link to it. | | Edited comment | The Jira copy is updated. | | Deleted comment | The Jira copy is deleted. | Rules that keep Jira trustworthy: - **Always the latest.** If you change the status twice in a row, only the last one reaches Jira. - **Your workflow decides.** If the Jira workflow has no transition to the mapped status from where the issue is, the issue stays put and the link is not marked as failed. - **No echo.** A change that came from Jira is never sent back, and Probara ignores the Jira events its own changes cause. - **Names, never emails.** Comments name people by first and last name only; a member Probara cannot name reads "Probara user". - **Only mapped, live issues.** Nothing is sent for an issue deleted in Jira, or once its Jira project is no longer mapped to the Probara project. - **A site that needs attention waits.** While Probara cannot use a site's credentials, changes wait and are sent once it can again, for up to 7 days. After a site is disconnected, nothing more is sent. ## Troubleshooting | Message | What to do | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | "This Jira project is not mapped to this Probara project." | An owner or admin maps it in the project's **Settings › Jira**, or in the organization's [default mapping](https://docs.probara.net/en/guides/integrations/jira/#set-a-default-mapping-for-the-organization) if the project has no mapping of its own. | | "This Jira project is not allowed for the site." | An owner or admin adds it to the site's allowed projects in **Workspace › Integrations**. | | "Probara cannot reach this Jira site." | The site needs attention; see [Troubleshooting the connection](https://docs.probara.net/en/guides/integrations/jira/#troubleshooting-the-connection). | | "Jira has no such issue, or the Probara app cannot see it." | Check the key, and that the app has access to that Jira project. | | "The Probara app lacks a Jira permission for this project." | Ask a Jira admin to check the project's permissions for the Probara app. | | "Jira is busy right now. Try again in a few minutes." | Jira is rate limiting the app. Try again later. Background uploads and links wait for Jira's retry time on their own, for up to 7 days. | | "Jira is not responding. Try again later." | Jira is unavailable. Background uploads and links retry automatically for about an hour, then show **Sync error**. | | "This Jira issue is already linked to this defect." | Nothing to do. | | "A Jira issue is already being created for this defect." | Someone else (or another tab) is creating it. Wait a moment, then check the linked issues. | | "This defect was deleted while its Jira issue was being created." | The issue exists in Jira without a Probara link. Close it in Jira, or link it to another defect. |