Addressing CMS form requests

Addressing form requests

When we receive a request from a customer to create a new form or make updates to an existing form, we should engage with the customer to fully understand the need. For simple, single-page forms that do not require logic, work with your client to create and manage the form through Form Builder. For more complex form creation requests or requests to make updates to current Banno CMS forms, we can engage our web development and engineering teams.

For any custom-built Banno CMS forms, our engineering team creates and maintains the backend functioning while our website developers build out the front-end form used on the website itself. For new implementations, we engage with engineers following the design phase to provide direction on the custom forms needing to be built out for the new website. Post-launch, we engage with engineers to build additional forms for our institutions, as needed, or to make adjustments to the setup of existing website forms.

Creation of a new form

When a customer requests that a new form be created for their website, the following information should be gathered, so you can provide web developers and engineers specific direction on the work needed:

• Form name: name or title of the form
• Form fields: the following should be captured for each of the fields to be included in the form and should be listed in the order in which they will appear on the form
  • Field name
  • Field type (text field, dropdown menu, radio buttons, checkboxes, file upload, etc.)
  • Options: if multiple options to select from, include all options in the order they should be shown
  • Required(*)/not required
  • Field description: if additional details or instructions need to be included before or after the field name, include those, so they can be captured as the form is built out
  • Captcha included/not included
• Existing resource: capture any current details that may already exist for the new form being requested including URL, screenshot, PDF, etc. Understand any changes to the current resource that will be needed as the new form is built out.

Example form request:
Contact Us Form

• First Name* - text field
• Last Name* - text field
• Phone Number* - text field
• Email Address* - text field
• Preferred contact method* - radio buttons
  • Phone
  • Email
• Best time to contact - dropdown menu
  • Morning
  • Afternoon
  • Evening
• Products interested in - checkboxes
  • Checking
  • Savings
  • CD
  • IRA
  • Mortgage
  • Auto Loan
  • Other - include text field to complete
• Form should include captcha.

Updates to an existing form

When a customer requests updates to be made to an existing Banno CMS form, capture as many details as possible related to the request, so you can provide web developers and engineers specific direction on the work needed. Information to gather:

• What is the name of the form in question?
• What is the current URL?
• Will the form name be changing?
• Will any field names be changing?
• Will the field type be changing for any of the current fields?
• Do additional fields need to be added?
  • What is the field type of any additional fields being added?
  • If multiple choice field, what are the options available?
  • Will the new field be required?
• Do any fields need to be removed?
• Do we need to adjust required/not required status of any fields?
• Do fields need to be reordered? If so, what is the new order of the fields?

When background information has been gathered

Once we have gathered all of the information we need from the client to fully understand the request, create an issue in Jira to engage the engineering team.

• New issue will be created in the Banno CMS Forms project.
• Issue will follow the outline for submitting Banno CMS form requests (found below), when created, to provide full information for the engineering team to begin working on the form(s).

The original reporter will monitor progress on the ticket as engineers complete work and will work with the engineering team through the Jira ticket to provide more information, if needed, as they work through the form request. Discussion about the issue should happen within the Jira ticket that has been created. When the updates have been made and are available for review on UAT, the original reporter will review the updates and approve the deploy to production.

Further details on this process can be found under Managing CMS form requests through Jira.

Submitting CMS form requests in Jira

Requesting creation of CMS forms

During a website implementation, custom Banno CMS forms may need to be built by our engineering and website development teams. These forms will be discussed during the website implementation process and planned for during the design phase. When we have gathered all details related to the new forms that need to be built, we can engage our engineers to complete backend work by opening a ticket in Jira.

Custom form needs may also arise post-launch. In this case, gather all details related to the request and engage engineers to complete backend work by opening a ticket in Jira.

1. Access the Banno CMS Forms project.
2. Select Create (+). Note: Each issue should cover a single institution.
3. Project: Banno CMS Forms
4. Issue Type: Task
5. Request Type: New Form
6. Summary: title the issue using a succinct but specific description of the request. For these requests, the summary should begin with the institution name, followed by ‘New Form(s)’, then jSource number (ex: ‘Ovation Bank: New Forms - #22222’).
7. Description: provide a thorough description of the request, so engineers can build the form(s) for the institution. Indicate the form name and list all form fields to be included in each new form, in order, specifying any field details (descriptions, type of field, etc.) and identifying which fields should be required. If multiple forms need to be created, each should be listed separately within the description, so engineers have clear direction on the work needing to be done. As part of the description, provide any available reference links (to existing forms or design mock-ups), screenshots, and other resources that help make the direction clear for engineers.
8. Attachment: attach any files (screenshots, PDFs, etc.) related to the request to provide full context to the engineering team.
9. Live Website URL: indicate current website URL, for reference. If referring to a specific form on the site as a reference point, provide a direct URL to that form. Note: the description field should be used if several direct URLs are being referenced.
10. Institution ID: indicate the institution ID for the institution.
11. Due Date: identify the date the setup should be completed. These requests should be set, at minimum, 5 business days out. More time may be needed, based on the scope of the request.
12. Click Create.

This opens the issue in the Banno CMS Forms project in Jira and creates a link that can be used to track progress and as a reference point for discussions with the engineering team.

Requesting updates to CMS forms

Post-launch, institutions may request that adjustments be made to the setup of an existing website form. In this case, gather all details related to the request and engage engineers to complete backend work by opening a ticket in Jira.

1. Access the Banno CMS Forms project.
2. Select Create (+). Note: Each issue should cover a single institution.
3. Project: Banno CMS Forms
4. Issue Type: Task
5. Request Type: Update to Existing Form
6. Summary: title the issue using a succinct but specific description of the request. For these requests, the summary should begin with the institution name, followed by ‘Update to ____ Form’, then jSource number (ex: ‘Ovation Bank: Update to Loan Application Form - #22222’).
7. Description: provide a thorough description of the request, so engineers can update the form, as requested. Indicate the name of the form to be updated, include a link to the existing form, and provide specific details on what updates are needed and where. As part of the description, provide any available reference links (to existing forms or design mock-ups), screenshots, and other resources that help make the direction clear for engineers.
8. Attachment: attach any files (screenshots, PDFs, etc.) related to the request to provide full context to the engineering team.
9. Live Website URL: include the current URL for the specific form needing adjustments made. Note: the description field should be used if several forms need updating at the same time and several direct URLs are being referenced.
10. Institution ID: indicate the institution ID for the institution.
11. Due Date: identify the date the setup should be completed. These requests should be set, at minimum, 5 business days out. More time may be needed, based on the scope of the request.
12. Click Create.

This opens the issue in the Banno CMS Forms project in Jira and creates a link that can be used to track progress and as a reference point for discussions with the engineering team.

Managing CMS form requests through Jira

Once an issue has been created within Jira, the issue will be managed here until there is a resolution. The engineering team will review all issues submitted, communication about the requests will happen within Jira on each ticket, we will use workflows to indicate status of the issue as it is being worked on and indicate when the work is complete.

Engineering review process

The engineering team will sweep through requests on the Banno CMS Forms board as they come in and will use the workflow statuses to indicate progress on the issue. These requests should be completed by engineering within 5 business days, unless it is indicated that the issue is blocked or waiting on information or the scope of the issue is so large that more time is needed to complete the request.

If you have a high priority request, ping @curry-firefighter in the #prod-content Slack channel, using the :urgent: symbol and referencing the Jira ticket.

In Slack, discuss individual topics within a single thread to help keep the channel cleaned up and easy to navigate. The engineering team will filter and manage incoming requests and loop in other team members, when necessary.

Communication on CMS form requests

Where possible, discussions in regards to Jira issues should take place in Jira. Operations team members can comment on the ticket, when needed, to engage with engineers. The engineering team will also adjust status and/or comment on the ticket within Jira as progress is made, so the operations team knows the current status of each request.

At times, discussions about a request may happen outside of Jira (e.g. Slack, email). When this happens, relevant details from the discussion should be captured as a comment on the original issue, so the history is complete and can be easily referenced later. This may include screenshotting, linking to Slack archives, or summarizing a discussion/email thread.

If a member of the operations team wants an update on a request and aren’t getting one through Jira, they should put a note in the #prod-content Slack channel, with a link to the referenced request from Jira. Any conversations in the Slack channel should be summarized as comments on the issue itself.

Workflow status

We will use workflow statuses within Jira to keep the engineering and operations teams informed with where we are on each particular request. As progress is made, the status should be updated, as well.

Below is an outline of the various statuses and corresponding descriptions of how and when they should be used.