---
title: "Troubleshoot Salesforce Case Trigger Not Creating Jira Issues"
canonical: "https://support.appfire.com/space/SUPPORT/3370385470/Troubleshoot%20Salesforce%20Case%20Trigger%20Not%20Creating%20Jira%20Issues"
format: markdown
---
This KB explains how to diagnose a case where the out-of-the-box Salesforce trigger does not create a Jira issue, even though issue creation works from the Salesforce UI component.

> ℹ️ Use this article when you are able to create and sync Jira issues from the Salesforce Lightning UI, but automatic issue creation through the Salesforce Case trigger does not work as expected.

> Macro (toc)

# Symptoms

- When trying to use the out-of-the-box Salesforce trigger to create Jira issues automatically.
- Custom code and flows have already been bypassed or ruled out.
- Creating a Jira issue manually from the Salesforce Lightning Web Component works.
- Push and pull sync through the UI works.
- The trigger path does not create a Jira issue from the Case record.

# Cause

If manual creation from the UI works, the connection itself is often healthy. The problem is more likely related to one of the following:

- Incorrect Jira `projectId` or `issueTypeId` values in the test or trigger logic
- Bindings or field mappings not aligned with the active connection
- The trigger targeting the wrong Salesforce object
- The record ID used for testing not matching the intended Salesforce record

> 📝 A successful UI-based create action does not fully validate the trigger path. It confirms the integration can create issues, but it does not confirm that the trigger configuration, IDs, and mappings used by the automated path are correct.

# How to Troubleshoot

## 1. Export the Salesforce integration connection

Ask the customer to export the current connection configuration from Jira:

1. Go to **Apps > Salesforce > Connections**.
2. Open the relevant connection.
3. Select **Configure**.
4. Click **Export** in the top-right corner.
5. Share the exported file for review.

This export helps verify bindings, mappings, and connection settings.

## 2. Review the Apex trigger used for syncing

Ask the customer to provide the Apex trigger responsible for the sync:

1. In Salesforce, go to **Setup > Developer Console**.
2. Open the relevant Apex trigger.
3. Share a screenshot of the full trigger code.

Reference documentation: [Automate your integration](https://appfire.atlassian.net/wiki/spaces/CSFJIRA/pages/1874001954)

## 3. Test manual creation with the old Lightning component

Have the customer test issue creation using the older Lightning component by selecting **Create** from the Case record.

This helps isolate whether the problem is in the trigger logic or in the connection, binding, or field mapping configuration.

- If the old component also fails, collect a HAR file.
- If it succeeds, the issue is more specific to the trigger-based path.

Reference documentation: [Create a Jira issue from Salesforce](https://appfire.atlassian.net/wiki/spaces/CSFJIRA/pages/3091792703)

HAR capture instructions: [Generate HAR files and analyze web requests for Atlassian support](https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html)

## 4. Execute a direct API test from Salesforce Developer Console

Ask the customer to run an anonymous Apex test from Salesforce to validate whether the API can create the issue outside the trigger.

1. Open **Developer Console**.
2. Go to **Debug > Open Execute Anonymous Window**.
3. Paste the test code.
4. Update the record ID, Jira project ID, and Jira issue type ID before running it.

```java
Id targetCaseId = '500RT00000UYAdEYAX';
List<Case> cases = [SELECT Id FROM Case WHERE Id = :targetCaseId];
System.debug('Cases Found: ' + cases.size());
JCFS.API.createJiraIssue('10000','10001',cases,cases,true);
```

> ⚠️ Do not leave example values in place. In this case, the original test failed because it still used sample IDs `'10100'` and `'10006'` instead of the actual Jira IDs configured in the customer environment.

# What to Verify Before Retesting

- The trigger is configured for the correct Salesforce object, such as `Case`.
- The Salesforce record ID used in testing is valid and matches the intended record.
- The Jira `projectId` is correct for the target project.
- The Jira `issueTypeId` is correct for the target issue type.
- Both Jira IDs are properly bound and mapped in the active connection.

# Confirmed Resolution

In the reported case, the direct API test succeeded after the customer updated the script with the correct Jira IDs:

- **projectId:** `10000`
- **issueTypeId:** `10001`

After running the corrected anonymous Apex script, the customer confirmed that the Jira issue was created successfully and the automatic pull from Jira also worked.

> ✅ This outcome indicates that the integration API and connection were functioning. The earlier failure was caused by incorrect example IDs in the test script, not by a platform-level issue with issue creation.

# Recommended Next Step

If the anonymous Apex test works but the out-of-the-box trigger still does not create issues, continue the investigation on the trigger-specific path:

- Compare the trigger logic with the working anonymous Apex test.
- Confirm the trigger passes the same object, IDs, and conditions.
- Review field mappings and binding conditions in the exported connection file.
- Check whether trigger entry criteria or record-state conditions prevent execution.

<details>
<summary>FAQ</summary>

**Why does UI creation work if the trigger does not?**  
The UI action and the trigger path can use the same connection but still behave differently because they may rely on different execution paths, conditions, or input values.

**What does a successful anonymous Apex test prove?**  
It proves the API can create a Jira issue with the provided record and IDs, which helps narrow the problem to trigger logic, trigger conditions, or configuration.

**What is the most common mistake in this scenario?**  
Using sample Jira IDs from documentation or old test code instead of the actual `projectId` and `issueTypeId` configured in the customer instance.
</details>