Product Fix Process

Overview

This article explains the process that the CIMcloud product teams take to fix an “issue” (also referred to as “bug” or “gap”) in the CIMcloud core product.  For the purposes of this article, a product “issue” is something in the CIMcloud’s base package or add-on bundles that is not working the way it was designed or intended to as determined by CIMcloud’s Product Management team.

Process Overview

This is a high-level overview of the process:

• Submit Task – You submit a support task via our ticketing system detailing the issue.
• Confirm & Classify – We confirm that the issue is truly a bug or gap in the product (if not, we will notify you and reroute it as needed) and classify it into one of the three  Product Fix Process Flows below.

The Three (3) Process Flows

If your issue is identified as a true product gap or bug in the core CIMcloud product, we will classify it into one of these three process flows to address or “fix” it on your CIMcloud platform.

• Process Flow #1: It’s Already Fixed in the Latest Version
• Process Flow #2: Critical Fix on Live Site
• Process Flow #3: Fix on Pre-Live Site (or Non-Critical or Future-Scheduled Fix on Live Site)

Product Fix Process Flow Details

The following provides additional details on each of the three process flows to fix core product issues.

Process Flow #1: It’s Already Fixed in the Latest Version

In some cases, the product issue you reported has already been fixed in the latest version of CIMcloud and you just need to be updated to that version.  If that is the case, CIMcloud will work with you to complete a Version Update on your application, which should address the issue.

The Process Steps:

Read this article for more details on the Version Update Process.

Process Flow #2: Critical Fix on Live Site

This process flow is intended to provide an emergency “hot fix” to a bug, that was previously working but is now causing hard errors, in a critical area of your live CIMcloud application.  This is something that may have been introduced or revealed by an internal (i.e. new CIMcloud version or data/setting change) or external (i.e. new browser version) change.

The Process Steps:

Read this article for more details on the Version Update Process.

Step Details:

• Submit Task – See description above.
• Confirm & Classify – See description above.
• Identify & Fix Issue – A member of the CIMcloud technical support team will identify & fix the issue (by modifying code, correcting data, etc).  If the fix requires an actual code change to core CIMcloud software, the following steps will apply. If the code change is needed in a customization that you, the CIM Pro  Services team, or another partner made to the application, the support person will notify you so you can work with those parties to get it addressed (CIMcloud’s support team does not support customizations).
• Create a “Hot Fix” Version – The coding fix will be merged into a new branch of the current version of the CIMcloud core code that you are using so it can quickly and safely be installed (bypassing all product release steps/processes).  This creates a hot fix version.
• Install – The hot-fixed version of the CIMcloud application will be installed on a staging environment so it can be reviewed and tested (this staging environment will also include any customizations that you may have running).  Depending on the severity level of the bug being fixed, the CIMcloud support representative may contact you to coordinate your own review before the next “Publish” step (if it is severe, they will not wait).
• Publish – The hot-fixed version will be published to your live platform allowing your workers and customers to get the fix.  At this point, your lead contact should review the site (including testing critical workflows like ordering and payments) and confirm the emergency hot fix 1) addressed the issue, and 2) did not introduce unintended new issues.
• [later] Version Update – The “Hot Fix” code changes will also be routed to the CIMCloud product team so they can incorporate it into an upcoming release of the product.  When that upcoming release comes out, the fix can be permanently installed on your platform through a standard Version Update to your CIMcloud platform.

Process Flow #3: Fix on Pre-Live Site (or Non-Critical or Future-Scheduled Fix on Live Site)

This process flow is intended to provide a permanent solution to a product issue in the CIMcloud application.  This process flow may apply to issues discovered:

1. During an implementation project before going live,
2. With a non-live feature being implemented (to later turn on) on an already live application,
3. After going live, but caused by a 3rd party change scheduled in the future (typically related to browsers, 3rd party services, etc), or
4. After going live, but related to a non-critical feature in the application.

This process flow is most typically seen when you are implementing one or more complex add-on bundles that are less frequently used and have large variations in configuration options, data complexity, and ERP-synced data.  Complex add-on bundles include: product configurator, multiple erp company files, power customers, multiple currencies, customer sites (if you have large quantities and variations), recurring and future orders, multiple shipments per order, etc.

The Process Steps:

Read this article for more details on the Version Update Process.

Step Details:

• Submit Task – See description above.
• Confirm & Classify – See description above.
• Schedule – A CIMcloud Product Manager will evaluate the task and schedule the work to complete the “fix”.
• Make Changes – This includes planning, developing (programming), and testing the changes made in various product environments.  Once the tests are completed and verified, they are incorporated into a “Release Candidate” version of the CIMcloud product, along with other changes.
  • Note: A Release Candidate is a new version of the product that is going to eventually become an actual supported release, but is still going through testing, validating, and stabilizing steps.
• Customer Preview [if applicable] – At CIMcloud’s option, we may take one or both of the following additional steps:
  • Note: This would only occur if you are the company that found / submitted the bug, and the bug is unique to your application / setup / data.
  • Step 1: Review and test the changes on a sandbox copy of your CIMcloud application and database
  • Step 2: Allow you to review and confirm the changes on the sandbox copy of your application
• Release – The CIMcloud product team will officially release the change into a new version of the CIMcloud application.  This change would likely be one of many things that are included in that release.  The release would most likely be a Patch or Minor release (but could, on rare occasions, be part of a Major release).
  • Note: The type of release your requested change is incorporated into will have a material impact on the work involved to complete the Version Update process.  The “Patch” is the smallest and lowest risk type of release.  The “Major” is the largest release in features, codes changes, work, and potential risk.
• Version Update – The standard Version Update Process will be followed (with your cooperation and participation) to get the release installed, tested/reviewed, and published on your CIMcloud platform.

Typical Lead-Times / Schedule:

When gaps or bugs are reported and confirmed, CIMcloud makes commercially reasonable efforts to address them as quickly as possible.  With that said, there are multiple steps involved in getting changes planned, completed, tested, and released.

Most issues that fall into this process flow (process flow #3) will end up in an upcoming “Patch” release.  These are the most frequent releases.  CIMcloud runs “Patch” releases every week, but it may take several weekly cycles for your issue to flow through to a release.

To help set realistic expectations, the following is considered a reasonably quick turn-around time on issues that are immediately prioritized in the schedule.

• Week 1 – Submit Task > Confirm & Classify
• Week 2 – Schedule > Make Changes [Start]
• Week 3 – Make Changes [Complete]
• Week 4 – Release (that includes your “fix”)
• Week 5 – Version Update (when the “fix” is actually seen on your application)

Note: Critical / blocking issues will be prioritized above non-critical / non-blocking issues.  As a result (and depending on product engineering team backlogs / loads), non-critical issues may sit in the “Schedule” stage for weeks before we start actually working on making the changes.  The scheduling priorities are determined by the CIMcloud Product Management team based on need and impact.