Feature spotlight
In This Blog
The moment a field gets encrypted, an admin usually assumes automation is off the table — Jira Automation reads and writes values directly, and an encrypted field doesn’t hand its value over the normal way. That tradeoff, security or automation, is exactly the kind of thing that makes teams hesitate to secure a field that’s already wired into their workflows.
It’s not actually a tradeoff. Secure Custom Fields for Jira exposes a Web API built for exactly this — it works like the standard Jira REST API but returns decrypted values to requests that are authorized to see them. Jira Automation’s built-in Send web request action calls that API directly, so a rule can read a secured field’s value, act on it, or write a new one back, all without the field ever losing its encryption or its permissions.
Picture an admin who secured a “Renewal Risk” field on a set of account-management issues, but a team still needs to know the moment that value changes so the right people can react. Instead of giving up on automation to keep the field secure, the admin builds a rule: on every issue update, call the field’s Web API endpoint, check whether Renewal Risk changed, and if it did, email the account’s watchers with the new value. The field stays encrypted and permissioned exactly as configured, the automation just has its own authorized way in.
That one pattern (call the Web API from a Send web request action) covers most of what teams actually want to do: emailing watchers on a change, updating a secured value when an issue transitions, or moving an issue forward once a secured field is filled in.
For the setup steps and more automation examples, see How to integrate secure custom fields with Jira Automation.
Not using Secure Custom Fields for Jira yet? Start a 30-day free trial to see how it fits into your existing automation rules.