Work with Jira from Supportbench: connect engineering issues and keep customer ownership clear

A Jira issue can track engineering investigation while a Supportbench case tracks the customer’s service experience. Linking them helps a support team keep the technical work visible without losing the customer relationship, case owner or next-update commitment. This guide covers the connection, the agent’s link/create procedures and the limits of synchronization, so that “engineering is working on it” becomes an accountable handoff rather than the end of customer communication.

Choose linking or creating for the right reason  ·  Confirm the connection and permissions  ·  Configure and verify the existing supported connection  ·  Link an existing engineering issue to a case  ·  Create a new Jira issue from a case  ·  Give engineering enough context and keep the customer informed  ·  Understand optional Jira-to-case status automation  ·  Pause or remove the integration deliberately  ·  Troubleshoot the actual failed step

Choose linking or creating for the right reason

An issue link does not grant a customer Jira access, make every Jira comment appropriate for a customer, or establish a promised release date. Review what you share with engineering and what you send back to the customer.

Confirm the connection and permissions

An administrator configures the integration. Creating an issue requires case access and Create and comment on JIRA items. The search-and-link procedure for an existing issue also requires Search and link JIRA issues; committing a link uses the create/comment permission too. The Link a Case path additionally requires the applicable case-edit and case-linking capability. Missing actions may therefore be an access or integration-state issue rather than an empty search result.

On the Jira side, the connected identity needs access to the relevant project, issues and create fields. Completing webhook and custom-field setup requires Jira administration privileges. A token does not grant more permissions than its user has.

Atlassian documents both the token behavior and restrictions on apps that collect customer API tokens; this guide describes Core’s existing method, not an endorsement that it meets every current cloud-app requirement. Consult Atlassian’s current authentication guidance and API-token management, and resolve new-connection questions with your administrator and Supportbench Support. Provider requirements reviewed on 28 October 2026.

Configure and verify the existing supported connection

1. Open Settings → Integrations → JIRA. Inspect the saved connection before changing a working integration.
2. In Connection, enter your actual Jira hostname, such as your-company.atlassian.net. Use Email or username for the connected identity and Password or API token for its compatible credential. For Jira Cloud, use the account email and approved API token. Leave the credential blank only when you intend to retain the saved one.
3. If your approved setup needs a new compatible token, the account owner creates it in Atlassian account security, gives it a recognizable name and expiry, and copies it into the credential field. Follow the official token instructions above. Record the rotation owner and expiry without copying the token into a ticket or document.
4. Under Diagnostics, optionally enter a representative Issue key or URL, then select Test connection. This tests current form values and issue access without saving or changing Jira.
5. Choose Automatic Jira activities deliberately: All changes, Comments and status changes, New comments only, Status changes only, or No automatic activities. Set Active according to whether agents should have the issue/linking actions. Save the intended configuration.
6. Review Setup checklist: the add-on, webhook and linked-cases field are separate items. Use Retry setup for an incomplete supported component when the Jira administrator’s access is available. Confirm an existing add-on before installing another.
7. Copy only your own displayed Webhook URL when reviewing the Jira webhook. Never use a tenant-specific URL copied from an old article. Recheck the connection and a sample issue after setup.

Jira administrators can review webhooks under Jira’s system administration. Core’s webhook setup uses issue-updated and comment-created/updated events with the payload included. Follow Atlassian’s current webhook administration guide. Setup indicators reflect saved setup; the connection test and observed event verify current behavior.

Link an existing engineering issue to a case

1. Open the intended Supportbench case and review the customer’s reported problem. Confirm that you are linking the same underlying issue, not simply a similarly worded title.
2. Open Actions → Case Relations → Link a Case. In Link type, choose JIRA.
3. Choose the relevant Project if known. Review Status: Open is the initial scope; use All when the issue may already be closed.
4. Enter the known issue key or useful wording in Search Terms, then select Search. Narrow the query or project if results are broad; the search returns at most 50 results.
5. Inspect the intended result and choose Link issue. Searching alone does not create the relationship.
6. Read the result and verify the issue appears in the case relationship context. The link action checks the issue again, so a stale or inaccessible search result can fail. An existing duplicate relationship is rejected.

For a B2B escalation, record the affected customer environment, impact and next customer update on the case. A shared Jira issue can describe the technical defect while individual cases preserve each customer’s operating conditions and commitments.

Create a new Jira issue from a case

1. Confirm there is no suitable existing issue and that the case contains the verified facts engineering needs. Remove credentials and unrelated customer details from content you intend to share.
2. Open Actions → Integrations → Create JIRA issue.
3. Select the required Project and Type. Select a Board only when appropriate; the initial option is no board.
4. Complete the required summary and the fields loaded for that Jira project and issue type. Fields marked with an asterisk are required. Jira’s metadata and permissions determine the available fields; the form is not the same for every project.
5. Write a useful description: observed behavior, expected behavior, reproduction steps, affected environment or version, business impact and evidence. Separate a confirmed fact from a suspected cause.
6. If an activity is selected as context, review it and its saved attachments before submitting. This is not a general file-upload form; authorized saved activity attachments are copied subject to limits.
7. Select Create JIRA issue, read the result and record the returned issue key. Verify the relationship and any follow-up warning in the case before trying again.

Give engineering enough context and keep the customer informed

A useful handoff is specific enough for another team to act without reconstructing the conversation. Include the customer-facing symptom, affected service or asset, reproduction conditions, time and timezone, the evidence already collected and what support has ruled out. Use a sanitized example when the underlying data is private. State the exact engineering question: diagnosis, workaround validation, release applicability or a product decision.

Keep a named support owner and the next customer update on the case. A Jira status is an engineering signal; it is not a complete customer message. For example, “Done” may mean the code change is complete while the customer still needs the release, configuration change or confirmation that their environment is covered.

Understand optional Jira-to-case status automation

Linking or creating an issue does not automatically mirror all statuses in both directions. Administrators separately configure Case updates → Status mappings in the Jira settings. A mapping selects Jira project, Jira changes to, Set case status to and the eligible current states under Only when the case is.

The inbound automation requires a matching enabled rule, a Jira status-change event, the correct project, an eligible current case status and a verified linked issue. Closing a case has an additional guard: all linked Jira issues must be readable and in Jira’s done category. A case linked to two engineering issues should not be assumed ready to close when only one finishes.

• Test the mapping with a controlled case and the intended Jira transition.
• Test a case in an excluded current status to confirm the rule does not override it.
• For closure, test the multiple-linked-issue situation and verify the customer workflow.
• Use Check automation history when an expected change is missing or a result needs review. An interrupted action is not a reason to blindly replay the same event.

Use the Jira configuration reference for mapping fields and setup. Automatic activity volume and status mappings are separate choices; choose both deliberately.

Pause or remove the integration deliberately

Turning off Active hides issue and linking actions while preserving the saved connection. It does not stop Jira webhook updates. To stop incoming webhook traffic, an authorized Jira administrator must manage the webhook in Jira.

Remove Jira removes the saved Supportbench connection. Jira-side cleanup remains a separate task: review the Supportbench webhook, linked-cases custom field and add-on with the Jira administrator. Do not remove a field or app before assessing its existing use and recovery requirements. For credential rotation, update the saved credential, test the connection and verify a representative issue before relying on it again.

Troubleshoot the actual failed step

Provide the case ID, issue key, approximate event time and sanitized error when asking for help. Never share the API token or your account-specific webhook secret in a public article or screenshot.

Continue learning

• Configure Jira, automatic activities and status mappings
• Coordinate internal handoffs
• Manage escalation and customer commitments