Creating an issue (bug) for PFM in Jira Service Desk

When an issue has been reported and all information has been gathered (following our Addressing questions + issues guide), the team member will create a Jira Service Desk issue to engage engineers. All of our issues for PFM App should be routed through this repository, so we have a single place to track current issues.

Jira Service Desk should be searched prior to creating a new issue, to see if there is already an open issue for the exact same problem or if there is a similar issue that has previously been resolved. If the exact problem already exists and there is already an issue submitted that remains open, the additional information that has been gathered should be added in the issue’s description and a comment should be added to the issue. If there are any discrepancies between your issue and the issues that are already in Jira Service Desk, create a new issue and add a link to any similar existing issues. Issues can always be linked together in the future if an engineer believes the new issue to be the same as an existing issue.

Creating the issue

1. Access the Customer Support board.

2. Select Create (+) in the left-hand panel. Note: Each issue should cover only one concern.

3. Project: Customer Support

4. Type: Customer Issue (PFM)

5. Summary: title the issue using a succinct but specific description of why you are opening the issue. If the issue is relevant to only a single institution, Summary should begin with the institution name. If multiple or all institutions are affected, indicate this in the summary, as well (ex: ‘Ovation Bank: Summarize the issue’ -or- ‘Multiple FIs: Summarize the issue’ -or- ‘All FIs: Summarize the issue’ ). A very generic issue title makes finding the issue later more difficult. Issues can always be renamed, if needed, as we understand more about the issue that is occurring.

6. Description: copy/paste the following form and complete with details about the issue: Background

   • What background information is needed to understand the issue?
   • What is being experienced vs. what is expected?
   • What is the specific error message?
   • Does the error repeat reliably?
   • List steps needed to be taken to reproduce the reported issue.
   • Indicate the time/duration that the error occurred the first time.
   • Indicate the time of the last attempt, if multiple attempts have occurred over an extended interval.
   • Provide logs from the user’s device.

   Checklist I confirm that I:

   • Created a meaningful and concise title
   • Addressed one, singular concern
   • Provided specific details about the issue and steps to take to reproduce

7. Attachment: attach any files, such as screenshots, videos, logs, error messages, device info, etc. that can help the engineering teams understand the issue being experienced.

8. Product: indicate the product where the issue is occurring. Note: more than one product can be selected.

   • CMS
   • Form Builder
   • History
   • Marketing
   • Mobile
   • Monitor
   • Online
   • People
   • Reports
   • Settings (Users/Groups/Logins)
   • Support
   • PFM - UI/UX
   • PFM - Data/API/Admin
   • PFM - Reporting
   • PFM - Infrastructure

9. Feature: indicate the specific feature where the issue is occurring, within the product noted above.

   • Bill Pay
   • Cards
   • Change User Info
   • Documents
   • Enrollment
   • Login
   • My Card Rules
   • Password Management
   • PowerOn
   • Remote Deposit
   • SSO
   • Stop Payments
   • Transactions
   • Transfers
   • Travel Notices
   • Zelle
   • PFM - User Features
   • PFM - Accounts & Transactions
   • PFM - Ground Control

10. PCID: provide the partner customer ID for the issue being reported.

11. Partner/FI: provide the Partner/FI for the issue being reported.

12. Account ID: provide the Account ID for the issue being reported.

13. Device/Browser Information: provide device or browser information from the Permissions tab in Banno People as well as version information. A screenshot of the user’s device(s) is not sufficient, this needs to include the actual device(s) information.

14. JHA Core: indicate the JHA core for the reporting institution.

15. Customer Phase: indicate the phase the customer is currently in. This is critical for determining urgency and guiding triaging/debugging efforts that are commonly related to the specific customer phases. If the customer is not live, the original reporter should include a link to the implementation spreadsheet for go-live dates in the description.

• Live: Used by Support/Implementation when the customer has been transitioned to support after go-live.

• New Launch: Used by Implementation when the customer is newly live.

• Going Live Soon: Used by Implementation when the customer is 1-2 weeks out from go-live.

• Implementation: Used by Implementation when in any other phase of the Implementation.

  Note: You should use “Going Live Soon” when the customer is within the week before live. “New Launch” should be used in the post-live support phase before they’re transitioned to support for opening cases in jSource. Make sure to set the appropriate severity so engineers can prioritize triage.

16. jSource Case #: include the jSource case number, for reference. Zendesk Ticket IDs: include the Zendesk ticket id, for reference.
17. Severity: indicate the severity of the issue. By default, the field should be set to Medium. If necessary, adjust the severity to help engineers gauge priority.

• Urgent: production completely stopped, no workaround available, vital to the functioning of the customer
• High: production impaired, very time sensitive
• Medium: production slightly impaired, not severely time sensitive
• Low: general need

19. Labels: if necessary, a label can be used to provide a bit more context around the issue, whether it’s about the importance of the issue or about the temperament of the customer who is reporting the issue. The following labels are currently available for use but should be used as conservatively as possible.

• Customer Mad: An indicator to signify that the institution is extremely unhappy about the current situation and that we need to have heightened communication with the institution.
• Live Blocking: This indicates an issue that is blocking an institution from going live on our service, therefore this issue is blocking revenue.

20. Linked Issues | Related FI: if applicable, indicate the institution(s) the issue is affecting. Under Linked Issues, select Related FI, then search for and select each relevant institution found in the Customer FIs project. If there are multiple requesters, include all institutions who are experiencing the issue. Note: Institutions are synced regularly from the implementation status sheets and can be searched by institution name or Company ID.

21. Linked Issues: select relates to, then search for and select each relevant issue or enter the issue key directly to provide context and background information for the engineering teams, if applicable.

22. Click Create.

This opens the issue in the Customer Support project in Jira Service Desk and creates a link that can be used to track progress and as a reference point for discussions with engineering teams. Review our guide to Managing issues through Jira Service Desk for details on the issue management process that follows creation of the issue.

Tips on linking issues: when creating an issue, the linked issue field searches only your recent history or allows you to enter the issue key directly. If you are having trouble finding the issue you are wanting to link, skip this step and create the ticket. Once created, you can link issues directly from the open ticket, and this will search all open Jira tickets, rather than only your recent history. Direction for linking issues can be found in the Using Jira Service Desk guide.

Creating an task for PFM in Jira Service Desk

When an issue comes in from a customer, and needs to have engineering work completed, all of our PFM Tasks should be routed through the Customer Task (PFM) workflow.

Creating the issue

1. Access the Customer Support board.
2. Select Create (+) in the left-hand panel. Note: Each issue should cover only one concern.
3. Project: Customer Support (OPS)
4. Type: Customer Task (PFM)
5. Summary: title the issue using a succinct but specific description of why you are opening the task. If the task is relevant to only a single institution, Summary should begin with the institution name. If multiple or all institutions are affected, indicate this in the summary, as well (ex: ‘Ovation Bank: Summarize the issue’ -or- ‘Multiple FIs: Summarize the issue’ -or- ‘All FIs: Summarize the issue’ ). A very generic issue title makes finding the issue later more difficult. Issues can always be renamed, if needed, as we understand more about the issue that is occurring.
6. Description: Be direct and clear with what needs to happen, by providing appropriate FI Names and Partner ID’s
7. Components: this field will either be one of the following choices depending on your request
   1. VPN Setup - PFM
   2. Data and Reports - PFM
   3. Remove Users - PFM
8. Click Create