Is {{comment.isInternal}} a valid smart value? spoiler: it is, FYI

Question

Hi,

Just FYI, or maybe the documentation is not up-to-date, but I ran into the following:

In a comment triggered automation, I wanted to test whether a comment is internal or customer reply. Usually it's done with {{comment.internal}} as the documentation suggests.

However, the automation editor lists {{comment.isInternal}} as a compatible value.

To double check, I checked with Atlassian Support (AI) and the response was surprising.

So I guess I just came across something that is undocumented (yet).

The Automation rule works like a charm with {{comment.isInternal}}, as I expected.

Bill Sheboy · Answer

Yes, I agree.

When that built-in documentation was first added, even Jira Cloud rules pointed to Jira Data Center docs!  It is definitely incomplete and likely hardcoded to a limited list of values.

In my experience, a better way to find the supported smart values is to look at the JSON for an example work item using the REST API and a browser tab, as described in this how-to article:

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

I recommend saving a bookmark to help quickly refer to it when needed.

József Porohnavec · Answer

Hi @Bill Sheboy

I agree with you 100%.

The strange thing is the built-in smart value listings for the rule editor do not list {{comment.internal}}.

If only just the docs were behind, but in this case, the lack of the documented version in the live product is quite misleading.

Bill Sheboy · Answer

Hi @József Porohnavec

I recommend not using undocumented (or discovered) smart values, rule features, REST API endpoints, etc. without confirming their availability and intended behavior with an actual person in the Atlassian Support team.  If you are on a paid license, your Jira Site Admin may submit that request here: https://support.atlassian.com/contact/#/

In my experience, the automation product is always evolving and so rule features (or the documentation) may be updated before general announcement to customers.  And thus, they are subject to addition, removal, or change in behavior.  No amount of customer testing can mitigate such change from negatively impacting usage.

An example I encountered several years ago was an Atlassian product manager added new rule actions for managing sprints to the public documentation...but those did not exist.  Contacting their support team led to a bit of back and forth until they admitted it was a "what if" scenario accidentally posted to the docs, and they had no intention of adding the actions.  Similarly, the Atlassian Support team suggested automation syntax solutions which worked, and which were listed nowhere in public docs.

Unfortunately, the documentation is way behind the product behavior and continues to include typos and incorrect usage of some features.  It seems the newest features (e.g., create lookup table) have very accurate documentation.  And the built-in smart value listings for the rule editor using the { } icon are also hard-coded and often do not accurately reflect the current rule scope / component.  I have suggested they integrate automated documentation generation with their release pipeline to help eliminate such problems in the future.

Kind regards,
Bill