JSU Server/Data Center vs Cloud feature comparison

We have achieved feature value parity; JSU for Jira Cloud is as powerful as our best-selling JSU for Jira Server! We have also introduced a Universal Rule Builder (beta) to our Jira Cloud app. This simplified experience makes it even faster and easier to build and visualize your workflow rules.

While some unavoidable API limitations in Jira Cloud restrict the full capabilities of some minute features of JSU for Jira Server, we've pushed the parity as far as Jira Cloud allows. Rest assured, this does not affect the value JSU brings into customizing your Jira workflows regardless of platform.

See the parity tables of JSU features below for complete details.

Conditions

Condition	JSU Server/ Data Center	JSU Cloud *Atlassian managed integration with Jira Cloud

Condition	JSU Server/ Data Center	JSU Cloud *Atlassian managed integration with Jira Cloud
User Is In Any Groups		*
User Is In Any Roles		*
User Is In Custom Field		*
Value Field		*
JQL		Jira Cloud architecture limitation
User Is In Any Users
Status Changed		N/A - Jira Cloud natively prevents ANY → ANY transitions to/from the same status.

Validators

Validator	JSU Server/ Data Center	JSU Cloud *Atlassian managed integration with Jira Cloud
Date Compare		*
Date Expression Compare		*
Fields Required		*
Regular Expression Check		*
Date Window		*
Linked Status

All features marked * were originally supported by JSU for Jira Server but are currently maintained by Atlassian on Jira Cloud.

Preconditions

Precondition	JSU Server/ Data Center	JSU Cloud

Precondition	JSU Server/ Data Center	JSU Cloud
Date Compare
Date Expression Compare
Date Window
Fields Required
Linked Status
Regular Expression Check
User Is In Any Groups
User Is In Any Roles
User Is In Custom Field
Value Field
JQL

Post functions

Post Function	JSU Server/Data Center	JSU Cloud

Post Function	JSU Server/Data Center	JSU Cloud
Copy Value From Other Field*		99% (Does not include the `* default value *` parameter due to Jira API limitations)
Update any Issue Field*
Clear Field Value*
Create a Linked Issue*		99% (Does not include the `*default value*` parameter due to Jira API limitations)
Linked Transition*		99% (Does not include the `Set Resolution - None` and `*default value*` parameters due to Jira API limitations)
Follow Up Transition
Copy or Move Attachments
Calculated Field*
* see note below about Jira Cloud Screen Security Configuration

Jira admins should be aware of Jira Cloud’s screen security configuration. This requires fields to be on the relevant screens to be edited. You can learn more in the Jira Cloud API documentationhttps://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-put. This highlights an important distinction between our Server/Data Center and Cloud apps.

On Jira Data Center, a JSU post function can be configured to run as either the initiating user or as a selected user. Both impersonation options can also be migrated to the cloud version, on which a third option is available: the JSU Add-on user. This configuration feature is called Perform As User in JSU.

If the field is present on a screen, JSU can edit it using the permissions of the user set in the Perform As User configuration, as long as that user has permission to edit the field. If the field is not on the edit screen, JSU cannot edit it unless the post function is set to run as the JSU Add-on user. This overrides the screen security configuration using the overrideScreenSecurity and overrideEditableFlag query parameters.

Custom fields context

If you use custom fields, you can select which issue types and projects the custom field appears in. The JSU Add-on user can’t be used to override fields missing because of their screen context. For example, if you have configured a post function to edit a custom field that is used only on a bug issue type and it is executed when a user transitions a different issue type, the execution will fail. See Configure custom field context | Atlassian Support to learn more.

Deactivated or missing users

If the selected Perform As User is deactivated or doesn’t exist in the Cloud instance following migration, JSU will use the JSU Add-on user to run the post function.

Perform As User

User	JSU Server/Data Center	JSU Cloud
Selected user
Initiating user	(default setting)
JSU Add-on user		(default setting)

If you migrate a post function that uses the initiating user from Jira Data Center, JSU maintains that behavior in Jira Cloud.

Custom fields

Field	JSU Server/ Data Center	JSU Cloud
Location Text
Location Select
Directions

Additional features

Feature	JSU Server/ Data Center	JSU Cloud
Issue Transitions Tab
Bulk Copy
Transition Trigger Service
Calculated Field

The Product team has prioritized the features that matter most to you. The features marked with in JSU for Jira Cloud are not being implemented in the near future due to low popularity. We are, however, always interested in hearing if any of these are critical for you. Contact us and share your use cases with our team. Help us make JSU even better for you!