BBx Generations & Barista Customer Support Handbook

Version 2.0

Released: 22 February 2022

Revision Tracking

For historical information about revisions that have been made to this document, see the Revision Tracking section at the end of this document.

Table of Contents

• Overview of Customer Support

• Terms Defined

  • Customers

  • Business Days

  • Business Hours

  • Software Problem Report (SPR)

    • Information Needed in a Software Problem Report

  • Support Hours

  • Support Ticket

• Support Levels

  • Support Response Diagram

  • Tier 0, Do-It-Yourself Support

    • Online Documentation

    • Bugzilla Databases

    • Community Forums

    • Additional Resources

    • What Tier 0 Do-It-Yourself Help Is and Is Not

    • Tier 0 Support Details

  • Tier 1, Tech Support Triage

    • What Tier 1 Support Is and Is Not

    • Tier 1, Tech Support Triage Responsiveness

  • Tier 2, Tech Support Tasking

    • What Tier 2 Support Is and Is Not

    • Tier 2 Workflow

  • Tier 3, Professional Services (PS) Tasking

    • Professional Services (PS) Tasking Coordination

  • Tier 4, On Demand (OD) Tasking

    • On Demand (OD) Tasking Responsiveness

• Revision Tracking

  • Changes Made in Version 2.0, 15 February 2022

  • Original Release

• Appendix A. Software Problem Report Form

Overview of Customer Support

The purpose of this handbook is to describe the process that BASIS USA follows in providing various levels of technical support to its BBx and Barista users/customers. A separate handbook will be available in the future to cover support from BASIS USA for AddonSoftware.

This handbook covers all of the steps from reporting a problem to obtaining the right type of support. In following this handbook, BASIS will offer its BBx and Barista customers consistent and understandable levels of technical support. Customers will benefit because this transparent model should minimize any miscommunication or unrealized expectations that might otherwise have arisen. It will also help them obtain the right support with as little wasted time and effort as possible.

Terms Defined

Before describing the customer support process, we must first define a few key terms and phrases. These definitions are necessary for describing the interface between BASIS support personnel and BASIS customers.

Customers

All users of BASIS products are BASIS customers. However, for the purposes of the customer support handbook, Customers are more narrowly defined to be channel partners, resellers and distributors, and self-programming end users who are entitled to direct technical support from BASIS. The key differentiator is that this subset of customers purchase and manage their licenses directly with BASIS. Other BASIS customers need technical support from the BASIS channel partner from whom they purchased their license to run their BASIS product.

Business Days

Business Days are defined as any day other than Saturday, Sunday, or an official BASIS holiday.

Business Hours

Business Hours are defined as the hours when the BASIS International, Ltd. office in Albuquerque, NM, is open for business. Business Hours are between 8 a.m. and 5 p.m. Albuquerque time on a Business Day. Albuquerque observes Daylight Saving Time as part of the Mountain Time zone.

Software Problem Report (SPR)

A Software Problem Report (SPR) is defined as a statement of a problem that a user encountered when using a piece of software. It is not a request for a specific solution. In order to create an actionable SPR, the user must request Tech Support to open a Support Ticket and provide the detailed information outlined in Information Needed in a Software Problem Report.

An SPR can be created in one of the following ways:

• Customers can email an SPR form (see Appendix A), along with the license information needed, directly to Tech Support as part of opening a Support Ticket.

  • SPRs submitted this way will be investigated by Tech Support personnel as part of resolving the Support Ticket.

  • This path is available to permit customers to get timely responses to their Support Tickets that include updates on the specific problem.

• Community forum topics or email discussions can be the source for an SPR if a customer opens a Support Ticket and requests an investigation into the problem.

• Community forum topics or email discussions can also be the source for an SPR if, during routine monitoring of forum posts, a BASIS employee determines that a problem being discussed warrants an SPR. This detection is not guaranteed to occur - to ensure a problem is addressed, open a Support Ticket.

• When Customers do not require timely assistance and therefore do not require an immediate response from BASIS to an SPR, they can also report a software problem by sending an email to ReportABug@basis.cloud, preferably including, or attaching, the information they have about the software problem in an SPR.

  • Some examples of low-priority issues that you may consider appropriate to send to ReportABug@basis.cloud include: differences you encounter between documentation and implementation, errors in documentation pages, formatting or layout differences between GUI and BUI, behavior issues for which you have already implemented a workaround in your code, and so on.

  • SPRs submitted this way will be investigated by Tech Support personnel as time permits, but no response is guaranteed.

  • During Tech Support's investigation, they may contact the reporter for additional details.

If Tech Support personnel end up creating an official bug based on the SPR, then they will add the reporter's email address to the CC list if that is possible. Being in the CC list permits the reporter to receive email notifications from Bugzilla, depending on their user preferences.

Once a Support Ticket has been created, Tech Support Personnel will work with the user to triage the reported problem. Triage may result in an SPR being rejected for a number of reasons, including but not limited to:

• Operator error or inappropriate product use

• Invalid problem statement

  • Works correctly as documented and designed

  • Lacks a statement of the underlying problem

• Could not reproduce

  • Insufficient details to reproduce (Java, BBx, or Barista version, operating system, etc.)

  • Missing reproduction steps

  • No sample program

• Won’t fix

  • Correcting this problem may cause other issues

  • The requested functionality is inappropriate for the product

  • The requested functionality is infeasible (it cannot be provided for architectural or other design reasons)

If an SPR is triaged by Tech Support and not rejected, then it will be further classified as one of the following:

• A Bug - an actual error in the current software implementation, to be fixed by the development team. If triage results in an actual Bug being uncovered, then the Support Ticket is canceled and the Bug is entered into Bugzilla (or whatever defect tracking system is in use at that time) for resolution by the development team.

• An Enhancement Request - a request for the development team to add new functionality to the software. The Support Ticket is closed as having been used/exhausted.

• A Support Ticket - a request for assistance from Tech Support. The Support Ticket is used to record Tech Support’s efforts to resolve the problem until it has been either resolved or exhausted.

• A Professional Services Request - a request to establish a new Professional Services (PS) contract, or to use an existing one, to obtain assistance in resolving the problem. The Support Ticket is canceled, and the support time already expended will be charged to the PS contract.

Information Needed in a Software Problem Report

In order for BASIS to quickly and accurately determine whether or not a Software Problem Report represents an actual defect in the software, the user must provide the following information:

1. PROBLEM STATEMENT

   • What behavior did you encounter that you believe you should not have, or what behavior did you not encounter that you believe you should have? Be as specific as possible, and avoid vague statements like “It should work right,” “It is broken,” or "Run the sample program; the problem is obvious." Do NOT describe a solution, but instead describe the underlying problem that needs to be solved by the engineering team.

   • What behavior do you believe should have been encountered instead? If possible, provide screenshots of any and all output windows that are relevant to the problem, and mark on the images the specific areas that represent the problem.

   • What is the impact of this problem? Is it a production issue, perhaps blocking end users from accomplishing their daily tasks? Be as specific as possible when describing the impact on your end users.

2. PRODUCT VERSIONS

   • What version of which product or products were used when the problem was seen? Be as specific as possible, preferably down to the version identifiers with build timestamps.

3. RUN-TIME ENVIRONMENT

   • Java version

   • Java source/type (Oracle, AdoptOpenJDK, or other sources)

   • Operating System together with the OS version number

   • License serial number

   • CUI, GUI, or BUI

     • If GUI, is it running locally, or using Web Start, or as a Desktop App?

     • If BUI, which browser and what version is in use?

   • Any special conditions such as running on VMWare, on Citrix, and so on?

4. REPRO STEPS

   • How did you reproduce it, and how can the developer? What specific steps or actions did you take to encounter the problem? Include every step needed to reproduce the problem while removing any extra “unneeded” steps or actions. You may need multiple runs to figure this out.

   • What conditions or configurations of the product contributed to the problem? This breakdown includes information about whether or not the reporter knows if this “always happens,” or if (for example) it only happens under certain configurations, with certain files, or after certain changes have been made. If any input files (data dictionary, data file, configuration files, etc.) are needed to reproduce the problem, provide it/them.

5. SUPPORTING CODE DETAILS

   • For BBX Code or Language problems: What small, self-contained sample program can you provide to allow BASIS personnel to obtain the results you cited (the PROBLEM STATEMENT when using the REPRO STEPS)? If the issue being reported is related to the language, then it is imperative that your report includes a small self-contained sample program that can be run by BASIS personnel to demonstrate the problem. To be self-contained, the program cannot have references to non-BASIS JAR files, image files, data files, etc. unless those files are also provided, and must be executable directly in BBx (i.e., not within any complex software program or framework). If BASIS cannot reproduce the problem by running your sample program, engineering will be unable to investigate the report.

   • For Barista problems: What information can you provide to allow BASIS personnel to obtain the results you cited (the PROBLEM STATEMENT when using the REPRO STEPS)? Much of the Barista code responsible for running application forms, reports, and queries is accessible to you. Whenever possible, in addition to the repro steps, supply the line of Barista code involved in the issue along with the name of the program file containing that line, and print any values referenced in that code. Screen captures or short videos showing the issue are also helpful, as are self-contained sample programs. If those are not possible, try creating the same issue within the Examples application and include the modified example. If the issue can only be reproduced within your application, you may need to submit some of your application form or callpoint files.

The following suggestions will help ensure that every SPR is investigated efficiently:

• Do not describe the desired solution but instead describe the problem that needs to be resolved.

• Be precise in every detail - especially when it comes to a user interface, refer to controls by the text they exhibit, such as the [OK] button, the Assigned To field, and so on.

• Be clear - document exactly what steps are needed so that others can reproduce the problem being reported; include every step needed to reproduce the problem, but do your best to leave out any “unneeded” steps or actions.

• Discuss one problem per Support Ticket - combining problems or features often confuses the issues. When in doubt, open multiple Support Tickets.

• No problem is too trivial to report; small problems or features needed may actually hide big ones.

Support Hours

Support Hours are defined as the hours when Technical Support personnel are available to respond to Support Tickets. Support Hours are the same hours as Business Hours.

Support Ticket

A Support Ticket (sometimes referred to as a Tech Support Ticket, Tech Support Incident, Trouble Ticket, or simply a Ticket) is defined as a single incident when a licensed user requests technical support assistance to resolve a single problem or issue.

• Tech Support personnel open a Support Ticket whenever they are contacted by a licensed user with a request for assistance if at least one unused Support Ticket is available.

• One Support Ticket includes a maximum of two hours of effort by BASIS personnel. Once those hours are exhausted, the customer can choose to:

  1. Pursue options on their own, such as Tier 0 Do-It-Yourself Support.

  2. Open another new Support Ticket to obtain further Tech Support assistance; this can continue until the customer’s available Support Tickets have been exhausted.

  3. Purchase additional Support Tickets.

  4. Establish a Professional Services (PS) or On Demand (OD) contract for hourly support for a defined level of effort over a defined period of time.

• Support Tickets have a limited scope. They cover the areas defined in What Tier 2 Support Is and Is Not.

• A separate policy exists that explains how Support Ticket credits are issued and tracked.

• Unused Support Tickets are valid for use during the calendar year for which they are issued. Unused Support Tickets cannot be carried over to subsequent years, although any Support Ticket that is already open and in-work at the end of the calendar year shall be considered valid until it is closed or exhausted (for whatever reason).

• A Support Ticket is considered closed, and no further support time will be expended on that task when support notifies the customer in writing of that closure. The customer can reply to that notification if they disagree, and BASIS management will review the situation within 2 Business Days.

Support Levels

BASIS offers five tiers of support, ranging from passive or do-it-yourself help such as online documentation (Tier 0) to on-demand support (Tier 4). Each support tier is defined by its stated purpose (what it is and what it is not) and by the commitment BASIS makes to meet customers’ expectations when they participate in that support tier. The five tiers are:

• Tier 0, Do-It-Yourself Support

• Tier 1, Tech Support Triage

• Tier 2, Tech Support Tasking

• Tier 3, Professional Services (PS) Tasking

• Tier 4, On-Demand (OD) Support

See the sections below for a complete definition of each support tier, and the procedures that BASIS support will follow when handling requests for assistance.

Support Response Diagram

Figure 1 below is a high-level flowchart showing how BASIS’ Tech Support team responds to customer requests.

Figure 1. How BASIS’ Tech Support Responds to Customer Requests

Figure 1 is included to simplify the details provided below. If there are any conflicts between Figure 1 and the text of this handbook, the text is the final authority.

Tier 0, Do-It-Yourself Support

In Tier 0, customers refer to online help documentation or participate in community forums to resolve their questions or issues. No BASIS support interaction occurs beyond routine monitoring actions.

Online Documentation

One avenue for Do-It-Yourself help is via this URL: https://documentation.basis.cloud/BASISHelp/WebHelp/index.htm. There you can search BASIS’ online documentation for:

• Product Documentation

• BASIS International Advantage Articles

• Tutorials

• Knowledge Base Articles

• Wiki sites

Bugzilla Databases

Another avenue for Do-It-Yourself help is by searching BASIS’ Bugzilla databases at:

• bugzilla.basis.cloud - for all BBx products and general BASIS Help

• bugs.basis.cloud - for Barista Application Framework

Bugzilla offers a built-in search/query engine where you can look for issues that have already been reported that may apply to your situation.

To access one of these databases, please contact your BASIS sales representative.

Community Forums

BASIS supports a number of Google Group community forums. These community forums are:

• barista-list (https://groups.google.com/a/basis.cloud/g/barista-list)

• bbj-developer (https://groups.google.com/g/bbj-developer)

• ide-user-group (https://groups.google.com/a/basis.cloud/g/ide-user-group)

To encourage adoption of, and optimal results from the use of, all BASIS forums, BASIS offers a BASIS Community Forum Users Guide that explains how to get the most out of any discussion Google Group.

Additional Resources

To encourage participation in the community forums, BASIS offers additional options for community sharing of information and resources. Two wiki sites are available:

• The IDE User Group wiki, which includes information and sample programs related to using one of the BASIS development IDEs, and general interest articles such as past conference presentations.

• The Barista and Addon wiki, which includes topic-specific information, sample programs, and helpful documentation related to using the Barista or AddonSoftware products.

Contact your sales representative to get access to either of these wiki sites.

What Tier 0 Do-It-Yourself Help Is and Is Not

Tier 0, Do-It-Yourself Support is meant for:

• Members of the community to post low-priority questions or thoughts for discussion by the community in general.

• Members of the community to share their experience and knowledge with other community members.

• BASIS to post announcements or notifications that are relevant or of interest to a large number of the members of that forum.

• Members of the community to check on the progress or status of an entry in one of BASIS’ Bugzilla databases.

Tier 0, Do-It-Yourself Support is not meant for:

• Sensitive discussions that may include technical support communications or information about BASIS’ or a customer’s potentially private business details.

• Professional services interactions.

• Discussions or investigations that are in any way urgent.

Tier 0 Support Details

In Tier 0, Do-It-Yourself Support, the community forums:

• Are moderated by BASIS personnel for inappropriate content or behavior.

• Are not actively monitored by BASIS personnel for emergencies or other high-priority needs. Members of the community who need high-priority assistance should either open a Support Ticket or arrange for professional services support, as they deem best for their situation.

• Are not guaranteed to elicit any response by BASIS personnel, let alone within any specific period of time.

• Are sometimes reviewed by BASIS personnel for details that could refer to a Bug. These details primarily include posts with enough detail to be reproduced in a development environment. Problems documented in this detail may be analyzed and may (or may not) result in a Bug being created to track the issue or may result in a referral to an already-existing Bug. However, the only way to ensure that a problem is investigated is to open a Support Ticket with Tech Support.

In order to keep the community forums from being used as direct lines from customers to engineering personnel, the following guidance applies:

• If information appears in a community forum post that could indicate the existence of a BASIS Bug, the BASIS moderator may optionally create a Bug in Bugzilla, and post information about that Bug on the forum topic.

• In any case, Bug links and other details will only be posted to the community forum by the moderator when they determine that the information could be relevant to future discussions.

• Community forum posts should not be targeted at or addressed to BASIS personnel.

• Unsolicited reports should not be emailed directly to individual BASIS personnel.

• If a topic has not received any community response within 5 Business Days, then the moderator may post to that topic suggesting ways for the customer to obtain BASIS support, such as Professional Services, On Demand Support, or a Mentoring contract.

Tier 1, Tech Support Triage

In Tier 1, customers can contact BASIS’ Technical Support group and request assistance in solving a specific problem. Customers should first attempt to resolve their issues via one or more Tier 0 Do-It-Yourself help resources and only contact Tech Support if those avenues have not proven successful.

The currently accepted means to request technical support are:

• An e-mail to support-ticket@basis.cloud

• A telephone call to 505.345.5021

• An online e-Support Request Form

  • For evaluation license users

  • For licensed users

Contacting Tech Support in this manner is referred to as “Tech Support Triage” because the most important response to any request for technical support is the initial triage that must take place. This triage will determine whether or not the request falls within the boundaries of tech support. Triage may instead result in the request being referred to the professional services team, or it may result in a referral to one or more of the community forums or BASIS’ online help. If the triage results in the request being determined to be:

• A valid technical support request — then that request will be handled as part of either Tier 0, Do It Yourself Support, or Tier 2, Tech Support Tasking.

• Not a valid technical support request but could potentially be met by establishing a professional services contract — then that request will be handled as part of Tier 3, Professional Services (PS) Tasking.

• Not a valid technical support request but instead requires an on-demand support contract — then that request will be handled as part of Tier 4, On Demand (OD) Support.

In any case, Tier 1 Tech Support Triage support ends once the assessment and evaluation of the request, along with the required notification, are complete.

What Tier 1 Support Is and Is Not

Tier 1, Tech Support Triage represents the initial assessment and evaluation of a customer’s request for assistance, with the resulting acceptance of the request or its assignment to one of the higher support tiers. It is not the actual resolution of the problem (although occasionally simple requests can be completely handled by pointing the customer to some existing Tier 0 resource).

Tier 1, Tech Support Triage Responsiveness

The BASIS acknowledgment for a Tier 1 (Tech Support Triage) request consists of acknowledging the receipt of the request:

• Within 2 hours when the request is received during Support Hours

• Within 2 hours of the start of the next business day for all requests received outside of Support Hours (including non-business days such as holidays or weekends)

The BASIS response for a Tier 1 (Tech Support Triage) request consists of:

• In the case where additional information is required in order to evaluate the request, the customer shall be contacted, and the necessary details requested, within 2 Business Days of the request submission. In this case, the resolution of the triage investigation should occur within 2 Business Days of the final receipt of sufficient details to allow triage to occur

Once Tech Support has received sufficient details to allow triage to occur (either from the initial report or after triage communications and investigations have finished), Tech Support personnel will determine the validity of the request and follow one of these courses of action:

• In the case where the request should be addressed as a Tier 0 request (the requestor simply needs access to one or more of BASIS’ self-help resources), the customer shall be notified of this result within 2 Business Days of the final receipt

• In the case where the request is rejected as invalid for any/every tier of support, the customer shall be notified of the rejection within 2 Business Days of the final receipt

• In the case where the request should be addressed as a Tier 2, Tier 3, or Tier 4 request, the customer shall be notified of this result within 2 Business Days of the final receipt. Within that same time period, the appropriate BASIS personnel shall also be notified to initiate the correct tier support response

Tier 2, Tech Support Tasking

In Tier 2, BASIS personnel provide customers with assistance for valid technical support requests. Tech Support Tasking is NOT free, nor does SAM provide unlimited support. Tech Support Tasking is covered under Support Tickets; separate invoicing is only required if the tasking requires the purchase of additional Support Tickets.

Once a valid Technical Support Ticket is opened, Tech Support Tasking personnel will:

• Investigate the request as reported by the customer

• Assist the customer with their defined need up to the limit of the available Support Ticket(s)

• Refer the customer for other support options when the investigation of the issue warrants it

• Record the result of expending one or more Support Tickets upon completion of the support

What Tier 2 Support Is and Is Not

Tier 2, Tech Support Tasking, can include/cover:

• Urgent response to issues such as BASIS-product failures

• BASIS product licensing

• BASIS product configuration (permissions, security)

• BASIS product SPR reporting (if the report includes a self-contained example)

• Sensitive discussions that may include technical support communications or information about a customer’s potentially private business details.

  NOTE:

  It is the customer’s responsibility to notify BASIS personnel whenever a support discussion encounters any potentially private information that needs to be handled as sensitive.

Tier 2, Tech Support Tasking, does not include/cover the following situations which might be available under Tier 3, Professional Services Tasking:

• Application support (analyzing, evaluating, or modifying the customers’ code)

• Production system issue troubleshooting

• Java tuning

• On-call support

• Support outside of regular Support Hours (including non-business days such as holidays or weekends)

• Resolving OS or network issues

• Training or mentoring the customer on products or best practices

• Urgent discussions for issues if they are not directly the result of BASIS-product failures

  • Examples of invalid Tech Support Tasking would be to resolve issues such as operating system problems, hardware difficulties, network interruptions (to name only a few of the most common problems)

• Longer-running interactions that may result in programs or other deliverables such as those covered under professional services contracts

Tier 2 Workflow

• Tech Support Tasking personnel will:

• Obtain the customer’s information (license, platform, version, etc.).

• Determine whether or not the request falls under an existing Support Ticket or requires that a new Ticket be opened.

• Notify sales personnel if a new Support Ticket is needed, but none are available.

• Record when an available Support Ticket is opened (and is thus no longer available to be used for a different request).

• Identify the customer’s need or goal and attach it to the Support Ticket; it is important to ensure the issue identified is actually the one that is important to the customer.

• Analyze the customer’s symptoms and attempt to determine the actual underlying problem.

• Attach the symptoms and the underlying problem (if it can be determined) to the Support Ticket; it is important to work on the actual root problem whenever possible.

• If at any point in this workflow it turns out that the issue is a Bug in a BASIS product (based on a decision by Tech Support Personnel together with management as necessary), then Tech Support personnel shall:

  1. Create a Bugzilla entry.

  2. Assign it to the best engineering resource for the problem.

  3. Update the Support Ticket to correctly reflect that it was NOT expended and remains available for future use.

  And the engineering personnel shall:

  1. Investigate the Bug.

  2. Fix or reject it, updating the Bugzilla entry accordingly.

• If the issue is found NOT to be a Bug in a BASIS product, then either:

  1. Continue to support the customer until the Support Ticket Incident is resolved or exhausted and then close the Support Ticket.

  2. Close the existing Support Ticket as resolved or exhausted, as appropriate, and offer to do one or more of the following:

     1. Initiate a Professional Services contract (Tier 3).

     2. Schedule On Demand (OD) support (Tier 4).

Tier 3, Professional Services (PS) Tasking

In Tier 3, BASIS Professional Services (PS) personnel provide customers with assistance in designing, developing, or troubleshooting Barista, BBx, and Java programs; configuring or analyzing production environments; or upgrading their systems. PS Tasking is NOT free, nor is it paid for by SAM. It must be covered under one or more professional services contracts established between BASIS and the customer before any support is provided. Sales personnel shall coordinate and establish such contracts and are responsible for invoicing and billing accordingly.

Tier 3, Professional Services Tasking, does not include/cover the following situations which might be available under Tier 4, On Demand tasking:

• On-call support

• Support outside of regular Business Hours (including non-business days such as holidays or weekends)

Professional Services (PS) Tasking Coordination

Once a PS contract is in place, BASIS Professional Services Tasking coordination includes:

• Professional Services requests must be submitted to the appropriate Sales personnel to confirm the scope and other details of the PS contract. Customers can copy PS personnel on any new requests made for support if those personnel have already been involved in that particular PS contract. But this is only to avoid delays or duplication of effort in providing the details of any approved task, not to initiate work.

• Any deliverable or other deadlines shall be negotiated by both Sales and PS personnel in communication with the customer before starting the specific task.

Tier 4, On Demand (OD) Tasking

In Tier 4, BASIS On Demand (OD) personnel provide production or development troubleshooting or analysis activities such as emergency assistance or on-call Subject Matter Expert (SME) type tasks with no deliverables beyond the hourly support.

On Demand (OD) Tasking Responsiveness

The customer shall provide BASIS Sales personnel the following information a minimum of 48 hours before any OD support is needed:

• The skills needed

• The hours/dates needed (minimum of 4 hours per time block)

• The type of support needed (one or more of: on-call until specifically tasked, active support by phone/email, computer login with credentials for investigation, etc.)

At that time, the BASIS Sales personnel shall ensure that a valid support contract is in place, including:

• Determining the charge rate based on:

  1. The number of personnel needed

  2. The type of OD support needed (as defined above)

  3. Whether the need is inside or outside of normal working hours for the BASIS personnel involved

• Coordinating with the needed BASIS personnel to schedule the OD support

When a valid OD contract is already in place, and an OD request is received, BASIS personnel shall:

• Acknowledge receipt of an On Demand request within 8 Business Hours. This correspondence is acknowledgment only, NOT resolution of the request.

Revision Tracking

This section records the significant revisions made to this document over time; the most recent changes are first.

Changes Made in Version 2.0, 15 February 2022:

Version 2.0 was released on 22 February 2022 as a new document in BASIS’ new Flare documentation tool. The original Version 1.0 Google Document was replaced but remained available here.

Section	Item Changed	Revision Description/Purpose
Overview	Heading and text	Inserted explanatory text to make it clear that this document now applies to both BBx Generations and Barista
Software Problem Report	Introductory paragraph	Removed superfluous reference to enhancements
	Second-level bullet	Removed inappropriate text about adding an email to the CC list
	Second top-level paragraph	Inserted text about adding an email to the CC list
Information Needed	List item #5, Supporting Code Details	Renamed from Minimal Sample Program, and split into two bullets: one for BBx Generations and one for Barista (with different details)
Community Forums	Bulleted list	Removed addon-developer from community forum list
Additional Resources	IDE User Group wiki bullet	Clarified the content available on the IDE User Group wiki
Appendix A	Supporting Code Details	Renamed from Minimal Sample Program, and split into two bullets: one for BBx Generations and one for Barista (with different details)
Throughout	Various	Corrected minor typos and misspellings; Added references to include applying to Barista

Original Release

This document was originally released as Version 1.0 of the BBx Generations Customer

Support Handbook, which had its final review on 11 January, 2021.

Appendix A. Software Problem Report Form

Use this Ticket Portal to report any problem you encounter with a BASIS software product. For suggestions, explanations, and details about each piece of information, see Information Needed in a Software Problem Report.

Thank you for reporting this problem! Your detailed information helps us investigate and address your problem as efficiently as possible. Please fill in the fields as completely and accurately as possible. To report this problem, send the completed form to support-ticket@basis.cloud.

To obtain technical support for urgent matters, be sure to clearly state the following when you notify support-ticket@basis.cloud:

• That you wish to open a Support Ticket

• That you require urgent assistance and what that means to you

• Your license information