- Get started
- About
- Conditions and validators comparison
- Migration to Cloud
- Connect to Assets API
- Use cases
- Dynamic Forms
- Dynamic Forms Overview
- Add Dynamic Fields
- Add Translations
- Configure Conditions
- Configure Validators
- Copy Dynamic Fields
- Display Dynamic Fields
- Dynamic Fields in Team-managed projects
- REST API
- Use Case
- Supported fields
- Bundled Fields
- Bundled Fields Overview
- Global Configuration
- Project Configuration
- Display Bundled Fields
- Search with Bundled Fields
- Automation
- Request details view
- Customization Overview
- Display Additional Details
- Display Attachments
- Display Related Issues
- Display SLAs
- Use Case
Configure Conditions
Find out how to configure Conditions for Dynamic Fields
Thanks to the Dynamic Forms feature of Extension for Jira Service Management you can set Conditions for the fields which are dynamic. This allows you to shorten request forms by displaying only the necessary information that is tailored to the individual needs of your Customer Portal users.
Conditions are rules that define whether a field is displayed in a request form based on user input or group membership. You can set multiple rules for a field and organize them into Condition blocks.
Your Condition blocks can include Field conditions as well as User conditions.
It’s possible to set multiple Condition blocks for a field. At least one condition in every block must be fulfilled to display the field.
Conditions within a block, which pertain fields, are in an “or” relationship, meaning that at least one condition out of the block needs to be fulfilled. Adding conditions which relate to users is optional and appears in an “and” relationship.
Condition blocks are in the “and” relationship, meaning that at least one condition from each condition block needs to be fulfilled.
As any change in a request type is automatically saved and visible on the Customer Portal, we recommend to keep request forms Hidden from portal while modifying them.
Field conditions
By adding Condition blocks you can configure conditions for selected fields to define whether a field is displayed in a request form based on user input in previous fields of that form. Determine the field which value you want to compare, add a condition and be sure that your Dynamic Field will be displayed on the Customer Portal if the configured condition is fulfilled.
- You can condition a field which is dynamic only based on other Dynamic Fields. Conditions can’t be used with regard to all the fields which are defined in a particular request type.
- Adding Field conditions for the first field that appears on your Dynamic Form isn’t possible. You can set User conditions for the first field on your form or add Field conditions for any field following it.
You can configure the following Field conditions:
Field type | Condition | Description | Example |
---|---|---|---|
TextField/TextArea/RadioButton | is equal | The current value must be identical to the expected one | “some_value” / “some_value” |
not empty | The current value can’t be empty | “some_value” | |
SingleSelect | is equal | The current value must be identical to the expected one | element / element |
not empty | The current value can’t be empty | element | |
NumberField | is equal | The current value must be identical to the expected one | 10 / 10 |
not empty | The current value can’t be empty | 5 | |
is greater than | The current value must be a higher number than expected | 10 / 9 | |
is less than | The current value must be a lower number than expected | 9 / 10 | |
MultiSelect/Labels/Components | not empty | The current value must contain at least one element from the list of the given field | element_A |
contains all | The current value must contain all available elements from the list of the given field. | element_A, element_B, element_C / element_A, element_B, element_C | |
contains any | At least one element of the current value must be included in the set of expected value elements. | element_B / element_A, element_B, element_C element_A, element_C, element_D / element_A, element_B |
|
contains | All elements of the current value must be included in the set of expected value element | element_A, element_B / element_A, element_B | |
doesn’t contain | None of the elements of the current value can be included in the set of elements of expected values. | element_A, element_B / element_C, element_D | |
Fix Version/s/Affect Version/s | not empty | The current value must contain at least one element from the list of the given field | “version1” / “version1” |
contains all | The current value must contain all available elements from the list of the given field. | “version1”,“version2”/“version1”,“version2” | |
contains any | At least one element of the current value must be included in the set of expected value elements. | “version1”,“version2” / “version1” | |
contains | All elements of the current value must be included in the set of expected value element | “version1”,“version2”/“version1”,“version2” | |
doesn’t contain | None of the elements of the current value can be included in the set of elements of expected values. | “version1”,“version2”/“version3” | |
MultiCheckboxes | all checked | The current value must contain all available elements from the list of the given field. | element_A, element_B, element_C / element_A, element_B, element_C |
any checked | At least one element of the current value must be included in the set of expected value elements. | element_B / element_A, element_B, element_C | |
is checked | All elements of the current value must be included in the set of expected value elements. | element_A, element_B / element_A, element_B | |
is not checked | None of the elements of the current value can be included in the set of elements of expected values. | element_A, element_B / element_C, element_D | |
Date Picker/Date Time Picker | is equal | The current value must be identical to the expected one | “2020-10-10 12:00” / 2020-10-10 12:00" |
not empty | The current value can’t be empty | “2020-10-10 12:00” | |
is later than | The current value must contain a later date than expected | “2020-10-11” / “2020-10-10” | |
is earlier than | The current value must contain an earlier date than expected | “2020-10-09” / “2020-10-10” | |
is before request creation (+/- offset) | Earlier date than the value from the creation date +/- x minutes/hours/days/weeks/months/years | “2019-04-04 12:00” / 2019-04-01 12:00" Creation date: 1 Apr 2019 + 3 days Accepted date: 4 Apr 2019 |
|
is after request creation (+/- offset) | Later date than the value from the creation date +/- x minutes/hours/days/weeks/months/years | “2019-04-05 12:00” / 2019-04-01 12:00" Creation date: 1 Apr 2019 + 3 days Accepted date: 5 Apr 2019 |
|
CascadingSelect | parent is equal | The current value of the parent must be identical to the expected one. | parent_A_child_A / parent_A_child_B |
child is equal | The current value of the parent and child must be identical to the expected one. | parent_A_child_A / parent_A_child_A | |
not empty | The current value can’t be empty | parent_A parent_A_child_A | |
Attachment | not empty | The current value can’t be empty | “extension.png” |
Priority | is equal | The current value must be identical to the expected one | “High” / “High” |
not empty | The current value can’t be empty | “High” | |
Assets* | not empty | The current value can’t be empty | object_A |
contains object | The current value must contain at least one object | object_A / object_A, object_B | |
contains any object | The current value can contain any object | object_B / object_A, object_B | |
contains all objects | The current value must contain all objects | object_A, object_B / object_A, object_B | |
doesn’t contain object | The current value can’t contain objects | - |
*Bear in mind that in order to use Assets it’s required to upgrade to the Premium Plan and establish your connection with the Assets API. To learn more, navigate to the Connect to Assets API section.
Note that the Example section in the above table presents the exemplary values that show how conditions work. In the case of the value comparison, the second value represents the set configuration while the first one represents the current value.
Configuring Field conditions
To learn about the configuration of conditions for a selected field, see the quick guide or follow the below steps.
Quick Guide
Steps
Before you start, log in as a user with Jira Administrators project permissions. For more information, see Atlassian documentation.
- In Project Settings > Customer form extension, go to the desired request type and select a field from the Dynamic Fields section.
- Click Conditions in the Options column.
- In the dialog box window, which enables you to create new condition blocks, click Add field condition.
- Select Field which value you want to compare by choosing the field name from a drop-down list.
By configuring Field conditions make sure that your target users can display all the fields used for configuration and no set User conditions restrict their visibility.
-
Determine Condition for your field. To select a condition type, use the field’s drop-down list.
-
Choose Criteria to be used for your field condition.
It’s possible to introduce more than one Criteria. You can select the particular criteria names from a drop-down list or start typing in their names and the hints appear as you type.
- Optionally, you can add more conditions for the selected field. In order to introduce an alternative condition, use the Plus icon and configure the fields’ values.
If you wish to delete the added condition, use the Bin icon.
- To finish the configuration of conditions, click Save.
A single condition block can include several Field conditions which are in the “or” relationship.
Result
Conditions for the selected field are set. During raising a request, this field will be displayed if its conditions are fulfilled.
By configuring Field conditions for the Approvers field you can change the visibility of this field based on the input introduced in the previous field, Required hardware.
If the user selects Computer monitor, Laptop and computer monitor or Laptop options in the Required hardware field, the next field, Approvers, will automatically appear on the form to be filled in.
Thanks to the set configuration, users see the additional field on the request form only when it’s necessary.
User conditions
You can decide whether to display the field not only based on user input but also on the basis of the group your users belong to. To make your request forms dynamic, configure conditions in order to show a particular field only to the users who belong or don’t belong to the groups selected in Criteria. Thanks to this feature you can make sure that significant fields are visible to relevant users.
-
In contrast to Field conditions, all User conditions can be configured for any field which appears on your Dynamic Form. That means it’s possible to decide about the field visibility based on the user group also with regard to the first field which is included in your Dynamic Form.
-
Bear in mind you can determine the visibility of fields only to the users that fulfill the set conditions. The anonymous or unlicensed Jira Service Management users won’t see the fields with configured User conditions.
Configuring User conditions
It’s possible to configure a single User condition with multiple criteria for any field included in your form. Currently, you can define all conditions only for the Creator user type which refers to the user who raises a request on the Customer Portal. To learn about configuration, see the quick guide or follow the below steps.
Quick Guide
Steps
Before you start, log in as a user with Jira Administrators project permissions. For more information, see Atlassian documentation.
- In Project Settings > Customer form extension, go to the desired request type and select a field from the Dynamic Fields section.
- Click Conditions in the Options column.
- In the dialog box window, which enables you to create new condition blocks, click Add user condition.
Bear in mind that for the configuration of the first field which is included in your Dynamic Form, only the Add user condition option is available. You can add Field condition for any subsequent fields.
- Select a condition type for your condition block. By using the field’s drop-down list, you can decide whether to display the field only to the user who:
- is in one of the groups specified in Criteria.
- is not in any of the groups specified in Criteria.
- is in all of the groups specified in Criteria.
- Choose the user group(s) which should be used as Criteria for your condition.
By adding Criteria it’s possible to introduce several user groups. You can select their names from a drop-down list. Alternetively, start typing in their names and the hints appear as you type.
To quickly remove the added condition, you can use the Bin icon.
- To finish the configuration of conditions, click Save.
Result
The condition related to the user is set. During raising a request, your dynamic field will be displayed based on whether the configured condition is fulfilled.
By configuring User conditions for the Required hardware field you can limit the visibility of this field and make it accessible only to relevant users.
Thanks to the set configuration only users who belong to the Team leaders and Administrators groups will see the field.
For the users who don’t belong to the Team leaders and Administrators groups the request form will be shorter as they won’t see this field.
The conditions settings related to a single field can include several Field conditions and only one User condition that are in the “and” relationship.
If you can’t find the answer you need in our documentation, raise a support request.
Include as much information as possible to help our support team resolve your issue faster.