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.

Managing 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.

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 may include multiple configuration elements with the same name (e.g., custom fields, screens), which causes naming collisions when fetched into Salto.

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 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 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.*"
        }
      }
    ]
  }
}