Create a Jira issue

Create a Jira Cloud issue when a Darwinium decision identifies an event that needs investigation or follow-up. The call returns the issue ID and key to the event, giving analysts a connection between the detection and the resulting task.

Use this on a deliberately selected event, such as an account change requiring review. Calling it on every request or retry can create duplicate issues.

Prepare a test project and credential

Install Jira – Create Issue and open jira.snippet. The jira_create_issue template sends POST /rest/api/2/issue to Jira Cloud. You need a project key, an issue type available in that project, and an account allowed to create issues.

Map that account's API token to a named secret such as jira_api_token. Jira's Basic authentication combines the account email and API token; see Jira Cloud Basic authentication.

Create a corrected local template

The supplied template needs three adjustments: remove literal apostrophes surrounding its JSON body, remove or correct its literal assignee value, and compose authentication after resolving the secret. Keep your adaptation in a separately named file so a Marketplace reinstall does not replace it.

The following complete example uses a fixed test summary and includes the current event identifier in the description. Replace example, RISK, Task and the account email with your test-project values. It deliberately leaves assignment to the project's default.

api_version: darwinium.com/api/snippet/v1
snippets:
  - name: customer_jira_review
    display_name: Create a Jira review task
    scope: model/operation
    mode: Merge
    arguments: []
    validation: |
      return true;
    template:
      - call_url:
          url: https://example.atlassian.net/rest/api/2/issue
          method: POST
          timeout: 3000
          request:
            header_rules:
              - name: Content-Type
                content: application/json
              - name: Accept
                content: application/json
              - name: Authorization
                template: "Basic {{ ('service@customer.com:' ~ secret(jira_api_token)) | b64encode }}"
            body_rule:
              template: >-
                {"fields":{"project":{"key":"RISK"},"summary":"Review account activity","description":"Darwinium event: {{ identifier }}","issuetype":{"name":"Task"}}}
          response:
            body_rule:
              jsonpath:
                - name: $.id
                  extract_to_attribute: integrations.jira.issue.jira_id
                - name: $.key
                  extract_to_attribute: integrations.jira.issue.key
                - name: $.self
                  extract_to_attribute: integrations.jira.issue.link

Save this as customer_jira_review.snippet, then import and add it to the intended step. The runtime JSON template is escaped according to the application/json content type. If you add dynamic text, keep it as a runtime expression within the JSON string rather than assembling unescaped JSON in a snippet argument.

Run the action only for the selected outcome

Give the operation a name such as create_review_task. Make it depend on the rule or model that determines whether review is needed, and add a condition for that outcome. For example, if your preceding workflow explicitly sets a boolean custom.general_purpose['create_review_case'], the action condition can be:

custom.general_purpose['create_review_case'] = true

This attribute is an example you define, not a built-in decision result. Use the actual output of your workflow. See Dependencies & execution order and Making your own integrations.

Verify the issue and its event link

Deploy to a test target and produce one event that meets the condition. Confirm one issue appears in the test project with the expected description. In Investigations, check integrations.jira.issue.jira_id, .key and .link on that event.

The mapped link is Jira's API resource URL from self. To open the human-readable issue, use your Jira site's /browse/ URL with the returned key, for example https://example.atlassian.net/browse/RISK-123.

Then produce an event that does not meet the condition and confirm no issue is created. Test repeated submissions against your chosen deduplication policy. The template does not provide deduplication; a successful issue creation followed by a lost response is also a reason to avoid blindly retrying.

If Jira rejects the body, check the project's required fields and issue types. If authentication fails, check the service account, token mapping and permission to create issues in that specific project.