...
Custom Field
...
Description
...
Modification
...
Configuration
...
View example
...
FIELD TYPE: LIST OF USER
...
The chain of previous users who were assigned to an issue
...
Display results as UserGroup (default) or as a Text
Display chain of users (default) or last only last
Note: field represent user/chain without including current assignee.
Limitation for the Text view: no more then 8 users can be displayed
...
FIELD TYPE: STRING
...
Collect statistics of child issues/tasks inside their parent.
Field avaialble in the EPIC (for linked issues) or Issue (for subtask) calculation.
...
Sum of Story Points of sub items in all (default) or specific status based on number field type (Story Points by default) displayed as number (default) or in percentage.
...
Count of unsized sub items in all (default) or specific status displayed as number (default) or in percentage.
...
FIELD TYPE: LIST OF USER
...
The chain of users who made last updates to an issue
...
Display results as UserGroup (default) or as a Text
Display chain of users (default) or last only last
Ignore some users who made modifications but should not be displayed in the field (empty by default)
Limitation for the Text view: no more then 8 users can be displayed
...
FIELD TYPE: STRING
...
Mirroring value in a Sub-Task from the custom field in a parent issue.
Field available only for the subtask issue type.
...
Don’t have default value, should be defined in the configuration.
Note: next types supported and will be presented as string:
group, user, option, date, datetime, string, number
Other field type will be converted to String JSON.
...
FIELD TYPE: STRING
...
Mirroring value of a issue status in a Sub-Task.
Field available only for the subtask issue type.
...
Don’t have modification, just represent parent status as string.
...
...
FIELD TYPE: LIST OF STRING
...
Amount of time that an issue has been in previous statuses
...
Display only last ‘time in’ status (default all time in statuses)
Hide ‘time in’ for current status (default show)
Display value in hours or days (default)
Note: less then 1 day = 0
e.g: 47 hours → 1 days, 48 hours → 2 days, 30 minutes → 0 hours, 65 minutes → 1 hour.
...
FIELD TYPE: LIST OF USER
LIMITATION: NO MORE THAN 20 FIELDS
...
Notify selected users about issue status.
Please note: if you create more than 20 fields with the type: User Notification, we can’t guarantee the stability according to Jira limitation. We recommend that you do not go beyond this limit.
Notification will be send within one hour after ‘time in status’ will be exceeded, next message will be send starting from this time + interval time. e.g: You have changed issue status to 'In review' at 13.00, and your configuration: interval: 2 hours, time in status 1 hours, status 'in review'. Notification will be send beetween 14.00-15.00. (e.g: at 14.37 and the next will be send at 16.37, 18.37 and so on)
...
Display results as UserGroup (default) or as a Text
Required fields should be configured:
Notification subject, notification body, ticket status, how long issue should be in status before notification will be send (in hours), interval how often notification will be send until status change. (in hours from every 1 to every 24 hours)
Limitation for the Text view: no more then 8 users can be displayed
...
By default, forge-based custom fields compute the value of the field on every issue view request, so that the freshly computed value is shown to the users whenever they open the issue page. Jira also saves this value into the database against the issue. Thanks to this, the value is not only available for that one particular user interaction but also becomes immediately refreshed for the REST API, all other views, JQL search, etc. Because the value function is invoked only on the issue view for the viewed issues any asynchronous changes will not update the field value until the view will not be open again. For that reason, we provide an additional configuration page per project, where you might define which fields should be updated asynchronous.
Go to: Projects → Fabulous custom fields project configuration
...
Select specific custom fields that should be asynchronously updated per project and click Submit
...
Example of usage: You have configured Parent Status field and you are viewing a sub-task in the issues search screen. Someone changing the status of its parent. In case of Parent Status is not configured for the asynchronous update, and you will update the issue search screen, Parent Status field will not correspond to the real issue parent status as you did not have direct interaction with the sub-task view. In case of Parent Status is configured for the asynchronous update data also will be updated for the issues search screen without additional interaction directly with the sub-task issue view. Please NOTE: it may take some time before the value will be updated.
...
Once the configuration is ready the next Fabulous Surveys functionality is available for the user:
Issue Preview Surveys
| Anchor | ||||
|---|---|---|---|---|
|
To preview the survey email
Go to: <Some issue> → Activity → Surveys Preview
In that section, you can shift between the ACTIVE campaign tab (blue rectangle on the screenshot).
Select an email address (correspond to the campaign recipient field) to preview the email data. And force send the survey (if the current user has appropriate permission) for the selected or all recipients if recipients are more than 1 (red rectangle on the screenshot).
...
If the recipient hides his email you will see the appropriate message
...
Force Send Survey
| Anchor | ||||
|---|---|---|---|---|
|
Allow Jira users with the appropriate permissions to send the survey ignoring campaign configuration from the trigger and periodicity section.
| Note |
|---|
Please note Will be ignored only Trigger and Once per ticket configuration. 'Link expiration' and 'Resend if expired' functionality left as it is. You can get more about this functionality here. |
Issue Survey Answers
| Anchor | ||||
|---|---|---|---|---|
|
To check survey answers for the specific issue (only with the right permissions)
Go to: <Some issue> → Activity → Surveys Answers
Here you can switch between all project campaigns (red rectangle on the screenshot)
...
If some answers exist they will be displayed in the following table:
...
Where Answered contains a Jira user or an email (for not Jira user) who was the survey recipient, an answered date in the format DD/MM/YYYY, and rating data if the rate exists.
Average surveys rating
| Anchor | ||||
|---|---|---|---|---|
|
To check the average rating per survey campaign
Go to: <Some issue> → Issue Details → Average surveys rating → Show average rating
...
The average rating will be displayed according to every project survey campaign:
...
Surveys Responses
| Anchor | ||||
|---|---|---|---|---|
|
Jira users with the appropriate permissions can view information about survey responses for all survey campaigns.
Go to: <Some project> → Surveys -> Responses
To filter responses click Apply Filters and select the appropriate filters for your needs:
...
Export Responses
| Anchor | ||||
|---|---|---|---|---|
|
You can export responses (according to applied filters) into the .csv or .json file.
A file in the selected format will be sent by email. By default, the file will be sent on the current user email (if it's open for plugin) or a user can specify the appropriate email.
Go to: <Some project> → Surveys -> Responses → and click Export
...
Select the file format, email address, and click Export
...
| Info |
|---|
Please note For sending files via email will be used 'Global Surveys SMTP configuration'. |
Surveys Analytics
| Anchor | ||||
|---|---|---|---|---|
|
Jira users with the appropriate permissions can view information about survey analytics for all survey campaigns.
Go to: <Some project> -> Surveys -> Analytics
...
or: <Some issue> -> Activity -> Surveys Analytics
...
You can check analytics data in the following table:
Email sending analytics - provide data about which events sent emails to recipients when it was and the status of this sending.
Field | Value | Description |
|---|---|---|
Campaign | Text | Name of the survey campaign |
Issue (only for global analytics) | Link | IssueKey with self issue link |
Event type | force 💪, trigger ➡️ or resend 🔁 | Survey send event initializer |
Datetime | DateTime | Datetime of sending email in the format:
|
Recipient | User | User name for Jira user or email for external user. |
Status | ✅ (true) or ❌ (false) | Email sent status. |
...
2. Successfully sent emails by event type - data about the count of successfully sending events by type for some issue in some campaign.
3. Not sent emails by event type - data about the count of not sent events (SMTP server problems, infrastructure problems, and so on) by type for some issue in some campaign.
Field | Value | Description |
|---|---|---|
Campaign | Text | Name of the survey campaign |
Issue (only for global analytics) | Link | IssueKey with self issue link |
Trigger | Number | Count for trigger event type |
Force | Number | Count for force event type |
Resend | Number | Count for resend event type |
Total | Number | Sum of trigger, force, resend |
...
4. General status of sent emails - data about the count of already replied, active, and expired surveys sent by emails.
Field | Value | Description |
|---|---|---|
Campaign | Text | Name of the survey campaign |
Issue (only for global analytics) | Link | IssueKey with self issue link |
Replied | Number | Count of replied survey links |
Active | Number | Count of sent emails which not expired and not replied |
Expired | Number | Count of sent emails which expired and not replied |
Total | Number | Sum of replied, active, expired |
Find a way to contact us in the Contact and Support section
...