Jira Settings | Salto Help Center

After adding an Jira application connection to an environment, users can customize various aspects according to their unique setup.

To do this, go to the Environment Settings -> Application Connections -> click the three dots next to your application -> Edit Configuration File

For more information about changing settings, read the Salto Configuration File article.

Masking Sensitive Data

Jira elements fetched into Salto, including automations, workflows, custom‑field settings, may contain credentials or tokens that you might want to mask.

For the full masking guide, see: Masking Sensitive Information in Salto for Git Repositories

jira {
  masking = {
    automationHeaders = [
      "Authorization",
      "API_KEY"
    ]
    secretRegexps = [
      ".*password.*",
      ".*secret.*"
    ]
  }
}

This configuration masks:

Any automation‑header value whose name equals Authorization or API_KEY
Any string that contains password or secret anywhere in the environment

Configuring Default User Fallback

When deploying configurations that include users who don't exist in the target environment, you can configure a fallback user:

jira {
  deploy = {
    defaultMissingUserFallback = "##DEPLOYER##"
  }
}

This will use the deployer's user account as a fallback for any missing users. You can also specify a specific username or email instead of `##DEPLOYER##`.

Managing Rate Limits

If you're encountering API rate limit issues, you can adjust the rate limiting settings:

jira {
  client = {
    rateLimit = {
      total = 10
      get = 5
    }
    maxRequestsPerMinute = 350
    delayPerRequestMS = 100
  }
}

Handling Unique Instance Names

In some cases, Jira instance may include multiple configuration elements with the same name (e.g., custom fields, screens). In this case, Salto will not be able to fetch them, as it can't determine a safe cross-env ID for the element (more on this issue here).

You can see the list of omitted elements in environments' "Configuration Issues" screen.

Preferred solution:

We recommend resolving the collision in Jira - either by renaming the conflicting items or removing the duplicates where possible.

Fallback option:

If resolving the conflict isn’t feasible, you can configure Salto to fall back to using internal Jira IDs for uniqueness:

jira { fetch = { fallbackToInternalId = true } }

This option should be used only when necessary, as it results in less intuitive element names.

Excluding Elements

You can edit the Salto Configuration File to exclude specific elements that you do not wish to view or manage with Salto. You can choose to exclude entire configuration types or specific configuration elements with certain properties.

For example, this configuration excludes all webhooks with "test" in their name:

jira {
  fetch = {
    include = [
      {
        type = ".*"
      },
    ]
    exclude = [
      {
        type = "Webhook"
        criteria = {
          name = ".*test.*"
        }
      }
    ]
  }
}

Excluding Elements by Project Type

You can exclude elements based on some criteria:

jira {
  fetch = {
    include = [
      {
        type = ".*"
      },
    ]
    exclude = [
      {
        type = "Project"
        criteria = {
          style = "next-gen"
        }
      }
    ]
  }
}

This example excludes team-managed projects (style is next-gen) while still including company-managed (classic) projects.

Excluding Custom Fields

JIRA has many custom fields that you might not need to track. You can exclude specific custom fields by editing your Salto Configuration File:

jira {
  fetch = {
    include = [
      {
        type = ".*"
      },
    ]
    exclude = [
      {
        type = "Field"
        criteria = {
          name = "customfield_.*"
        }
      }
    ]
  }
}

This example excludes all custom fields from being fetched, which can significantly improve performance.