Updates to handling sensitive data and terminology in Automation

[#1]

Hi community!

Thanks to feedback from users like you, we're making some important changes to how Automation handles "hidden" fields, those sensitive values like API keys or tokens that you mask during rule configuration.

We've also got an update for some terminology changes making their way across the platform.

Keeping your sensitive data secure in Automation

We've received reports (shout out to those who raised AUTO-2211 and AUTO-2207!) that sensitive values were appearing in clear text when using the Automation Rule Management API. We're taking action to ensure these values are consistently redacted across all surfaces to keep your data secure.

What's changing

Over the next 7 days, we're rolling out a fix to address the gaps identified in our REST API and export tools. We're ensuring that hidden field values are:

• Always redacted in API responses — addressing the feedback in AUTO-2211, you'll now see a placeholder instead of the plain-text value

• Excluded from rule exports (both single and bulk)

On re-import, hidden fields will be blank and must be re-entered manually.

Here's an example of what a redacted field looks like in an API response:

"headers": [
{
"id": "_header_1777502480005",
"name": "token",
"value": "**************************",
"headerSecure": true
}
]

 Which components are affected

The fix covers components where hidden fields weren't being fully enforced:

• Incoming Webhook

• Send Web Request

• Slack

• Twilio

• Microsoft Teams

• Send custom Docusign request

• Send custom Entra ID request

• Send custom Okta request

• Send custom Workday request

Components that use Atlassian's outbound auth (OAuth connections) are not affected, those credentials are never stored in rule configuration.

A quick note on backups

If you use rule exports as a backup mechanism, exports will not include hidden field values, this has always been the intended behaviour, but we want to make sure it's clear. If you ever need to restore from an export, you'll need to re-enter any sensitive values manually. We recommend storing those keys securely outside of Atlassian (for example, in a password manager).

When is this happening?

We're also working on a broader fix to apply the hidden field pattern consistently across all components that handle sensitive values — including Generic Request actions used with Workday, Okta, Microsoft, Entra, and DocuSign. As part of a single rollout, existing components will have sensitive fields removed over the next 7 days, and support will extend to these additional components over the next 14 days.

We’re also updating automation vocabulary!

“Rules” are now called “flows”, and “components” are now called “steps”.

With automation expanding across Atlassian, we’ve updated these terms to align with other experiences. Everything you’ve built still works the same.

Questions or feedback?

How are you using these components today? If you have a specific workflow that relies on rule exports, or you have questions about how this change affects your setup. Let us know in the comments. We're here to help.

If you believe you've been impacted by the regression, please reach out to Atlassian Support.

[Josh]

This is excellent news. Thank you, @Scott Bell !

[Shai Gilboa]

@Scott Bell what about the redactSensitiveFields paramter?

[Marshal Okokhere]

How are we sure that, those sensitive values are safe because it’s very important to have at least 90% hope that everything will be safe.

[Scott Bell]

@Shai Gilboa The redactSensitiveFields parameter will no longer have an affect - sensitive fields will now always be redacted.

[Scott Bell]

@Marshal Okokhere what do you mean by "safe" in this context?

[Shai Gilboa]

@Scott Bell but the whole idea was to by default redact, but also allow usage of APIs to copy automations from one instance to the other.
We have created elaborate python scripts and pipelines for this (which redact/un-redact as needed).
Cancelling this parameter will now break this and introduce manual work again. 

[Scott Bell]

@Shai Gilboa You're right to call this out.

To clarify what's changing: previously, sensitive fields were returned in plain text by default, and `redactSensitiveFields=true` was the opt-in to redact them. The fix inverts this, redaction is now the default and unconditional, so the parameter has no effect.

This is a breaking change for pipelines that relied on reading back those values via the API. That's a known tradeoff of the fix, and your use case (programmatic rule migration between instances) is legit.

There's no current API path to retrieve unredacted values. The right long-term answer is a secrets vault / named secrets feature, where you'd define a secret once and reference it as a variable in rules, meaning it never needs to move between instances. That's not in scope for this fix, but I'll make sure your use case is logged as a priority input for it. I'll be raising an AUTO ticket shortly (will link it here).

In the short term: storing sensitive values externally and injecting at import time is the only available workaround. I know that's disruptive if your scripts were previously self-contained.