The information in this page can be used to quickly see the main use cases that can be implemented with Advanced Portal Reports. It shows the main features into perspective of specific requirements. Use cases are complemented with a lot of screen shots - to help you quickly grasp them.
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Panel | ||
---|---|---|
| ||
Target AudienceAdvanced Portal Reports is build for companies using Jira Service management who need to support more complex scenarios of Portal usage. Advanced Portal Reports works well for companies of any size - both small entities and enterprise customers use it to deliver better visibility into Jira’s data at the Portal. |
Panel | ||
---|---|---|
| ||
Key Features1️⃣ Advanced Requests Report Using Advanced Requests Report the Portal can be extended to show needed fields on request’s page and requests list. In the requests lists Customers can:
2️⃣ Created vs Resolved chart Using Created vs Resolved chart customers can analyze the speed of creating requests vs the speed of completing requests. By comparing the number of issues created with the number of issues resolved, users get insights into whether the support team is able to handle the volume of incoming work effectively. Administrators can:
For more configuration details see the documentation - https://tools4teams.atlassian.net/wiki/spaces/APRFJSM/pages/1507885092/Configure+Advanced+Portal+Reports |
Panel | ||
---|---|---|
| ||
🫤 Pain pointsPain points which Advanced Portal Reports address:
|
Key use cases
Panel | ||
---|---|---|
| ||
Exposing SLA fields to Portal customers |
🙏 Needs:
One common use case of Advanced Requests Report аdvanced Portal Reports is to show SLA fields on the Portal. Usually companies want to expose fields such as “Time to first response” and “Time to resolution” at the Portal and allow customers to view, search and sort by SLA fields.
🫤 Pain points:
Lack of ability to view a SLA on request’s page
Lack of ability to view a SLA as a column in request list
Lack of ability to filter by SLA the request list
Lack of ability to sort by SLA the request list
Solution:
Using Advanced Requests Report аdvanced Portal Reports the Portal may be extended to show SLA fields in both locations - request’s page and requests list.
This will enable Customers to view the SLAs at both on request’s page and in the requests lists - where they could sort the requests list by SLA and use it as a filter.
See full list of supporter fields here - APR Supported Fields
SLA on request’s page
SLA as column and filter in requests list
Panel | ||
---|---|---|
| ||
Extending Portal with powerful search |
🙏 Needs:
In some cases customers need to be able to search by values stored somewhere in a text fields. For example a text in the description, or a value stored in custom text fields such as “External Reference ID” custom field. They want to be able to do exact match and partial match. In other cases customer need to be able to search by reporter, by custom field or SLA.
🫤 Pain points:
Limited ability to search for requests on the Portal
Solution:
Using Advanced Requests Report customers can search requests:
by text (JQL text~). By default the search result returns both exact and partial matches in any text field. Text search is limited by the functionalities of the underlying Jira and JQL. For more information refer to the documentation - https://tools4teams.atlassian.net/wiki/spaces/APRFJSM/pages/1545109693/Search+for+requests
by SLA
by custom fields added as columns - see here more details https://tools4teams.atlassian.net/wiki/spaces/APRFJSM/pages/1509097598/Filtering
See below few search screens.
Panel | ||
---|---|---|
| ||
Speed JSM adoption with pre-configured Portal lists - fields, columns and filters |
🙏 Needs:
A company builds websites. They use JSM to track support feature requests for the websites they create. They added these fields to Jira:
“Site” = drop-down to select impacted site (set during ticket creation)
“Classification” = drop-down list with options such as “Technical issue, Data issue, Training, Feature request” (set during first triage)
“Contract” = drop-down list with contracts, which cover the cost of service request implementation (set during first triage)
Customers generate tickets within their individual JSM projects. These tickets are initiated by the purchasing company, not the end users of the site. Business people request new features by creating a ticket and IT team triages requests and decides which features will be implemented by setting the “FixVersion” field.
They use “FixVersion” and to plan when the feature will be done and Planned Start and Planned End dates.
🫤 Pain points:
Customers lack visibility into additional details like classification and contract settings determined by support. They require this visibility to analyze whether support requests come from inadequate training or site quality. Furthermore, they need clarity on which requests are covered by specific contractsneed visibility when is expected for features to be delivered.
Solution:
To meet customer needs the admin have:
1) configured the Advanced Requests Report to show needed columns on request list.
Reference (Key)
Summary
Assignee
Status
PriorityFixVersion
Due Date
“Site” custom field
“Classification” custom field
“Contract” custom field
Planned Start
Planned End
Linked Issues
2) Configured Requests View to show needed fields on requests page.
Due Date
“Site” custom field
“Classification” custom field
“Contract” custom fieldFixVersion
Planned Start
Planned End
Linked Issues
3) Configured Global Views, for saved filters which customer can open on the Portal:
“Contract - 2024 site support” “Release Q1 2024” which shows all requests created since beginning of 2024, with “Contract” custom field = “Contract - 2024 site support”. The customer which will be delivered with this release”. The business can export the list and use this as reportingit for UAT preparation.
“Support Requests due insufficient Training - 2024” which shows all requests created since beginning of 2024, with “Classification” custom field = “Training”.
Panel | ||
---|---|---|
| ||
Ability to use saved filters - defined by customers on the Portal |
Panel | ||
---|---|---|
| ||
Ability to analyze trends of created vs resolved (speed of creation vs speed of closure) |