3 Replies Latest reply on Jan 17, 2017 9:24 AM by florian1

    Can incident cause codes validate off of more than 1 pick list?

    ford_sb Apprentice

      We're in the process of planning our upgrade to HEAT cloud and are using the opportunity to overhaul our categorization. Our current setup is pretty granular (looks like an IT org chart) so we're wanting to go more ITIL (system->symptom) with the categories and use an additional details tab to drill to the specific system.


      One challenge we've hit is dealing with the cause codes. Right now, we have a few learning management websites (Blackboard, Moodle, Canvas..) that have a set of cause codes that would be unique to them, but not other websites. Right now, they are in their own category in HEAT Classic, but we'd like to bring all of our managed websites into the same category in Cloud. That would cause a pretty sizable jumble of causes, since we'd be mingling several other sites together.


      I see that the constraint options for pick lists allow for boolean operations, so my first thought was to create the list of causes and use both the category and values in the additional details tab to determine the appropriate causes.


      For example, if the category was 'Website', could the causes change depending on the website selected from a picklist on an additional details tab?

        • 1. Re: Can incident cause codes validate off of more than 1 pick list?
          florian1 Expert

          You have the possibility to use IncidentDetail.{Category} based on a category chosen but this option is too complex when only one additional Information is needed (see https://community.heatsoftware.com/thread/1903).


          As long as you only need one additional pick list to display I wouldn't go for an additional detail tab but to a constrained Picklist.

          Here's a short draft of how it can look in your database:

          Please note:

          - Instead of having "MgmtWebsite" as an own business object you can use the built-in "SubCategory" as well.

          - This is a pragmatic approach and currently bound to your management Websites only.

             If I were to go with this approach I would have to think about other use cases where I may need this and extend based on my business cases.

             (For example, you can add a validated "Category" field to "MgmtWebsite" and you will be able to apply this logic to other categories as well.)


          Here's a rough "To Do":

          1) Create 3 Validation Business Objects:

          - MgmtWebsite

          -> Field: SiteName (Unicode Text, 255)

          - MgmtWebsiteCauseCode

          -> CauseCode (Unicode Text, 255)

          - MgmtWebsiteCauseCodes

          -> SiteName (Unicode Text, 255, validated by MgmtWebsite.SiteName)

          -> CauseCode (Unicode Text, 255, validated by MgmtWebsiteCauseCode.CauseCode)


          2) Populate your validation business objects

          2a) MgmtWebsite: Add as needed..

          2b) MgmtWebSiteCauseCode: Add as needed..


          3) Map your categories in MgmtWebsiteCauseCodes

          -> e.g.{ "Moodle: xy", "Moodle: xx",  Canvas = "xy"}


          4) Modify the Incident business object:

          a) Add a field to hold the MgmtWebsite: XTN_MgmtWebsite (Unicode Text, 255, validated by MgmtWebsite.SiteName)

          b) Add another field for the Website Cause Code: XTN_MgmtWebsiteCauseCode (Unicode Text, 255, validated by a custom picklist as seen below)

              -> Here's the interesting part:

                  You will now parse XTN_MgmtWebsite from 4a) and will only show the cause codes mapped in MgmtWebsiteCauseCodes:

          c) Add the fields from 4a) + 4b) to the form and use some visibility rules.

          • 2. Re: Can incident cause codes validate off of more than 1 pick list?
            ford_sb Apprentice

            Wow, that's amazing, Florian Thank you for the fantastic input. The method you outlined is what I was envisioning, but I see it makes it much simpler to have a sub type listed. We'll still have the additional detail tabs to capture required details, but I can see the advantage of have the sub type on the main form.


            If you don't mind me asking your opinion, I'd like to get your take on why we're doing this. Our existing setup was configured in 2006, and has a category scheme like this:



                 Desktop Hardware Failure




                 Audio Visual Failure


                      Sound system



            We're planning on changing to something like this for Incidents to capture the reported symptom, and with your subtype recommendation it would look like this:



                           Error Message

                           Incorrect content

                                                 *new subtype with website list*                


                 Computer Hardware

                          Startup problem


                           Error message

                                          *new subtype with computer types*    


            If we go that route, are there any major gotchas we should consider? I'm looking at the ones that may not need a sub call type as it stands now, but it's making me rethink them.


            Thanks again!

            • 3. Re: Can incident cause codes validate off of more than 1 pick list?
              florian1 Expert

              Technically there aren't really many gotchas to be aware of.

              Try to refer to a generic capability in your categories instead of using its special technology name to keep your category-based questionnaires working.

              It's really cumbersome when you have to rename a category and get the IncidentDetail.* object working again ;-)


              When you go with sub categories make sure every category has at least one sub category.

              Required rules based on existing sub categories ("are there any categories for category xy? If yes then true") are not that easy.

              And if you don't force fields to be populated you will always have empty fields.

              • If there aren't any sub categories you can use the same name as you did in your category and choose "auto select on single value" in your picklist.


              In your case I think it's rather an organizational question when defining your service catalog:

              1) Do you really need sub categories? Or is it feasible to just have every Website in your CMDB and link it in each Incident?


              ---- For example:

              Let's say I have a 404 error on "contoso.local".

              If I had every website as a CI in HEAT's CMDB, I could do the following as an analyst:


              • Service: Web Development & Hosting
              • Category: Error Message
              • Summary: Error message on "contoso.local"
              • Description: There is a 404 error when accessing http://contoso.local/sub-page
              • Linked CI = "contoso.local"


              Advantage when you link the CI: You will have meaures for potential service improvements - some examples:

              • . Outages by Website per Service "Web Development & Hosting":
                • Which websites require most of your team's workload?
              • Resolution breaches by Website per Service "Web Development & Hosting"
                • Why does it take us longer to support this site? Do we need to train our teams or is our documentation missing for an easy fault tree analysis?


              Hint: You can simplify any Incident classification by providing some SelfService Incident templates.

              Later on you can use your Event Management processes (using Nagios, SolarWind, Splunk..) as well.


              2) Identify your Services and Service Catalog

              Do you have more Services in your Service Catalog or just these two for a start? If you just started defining and implementing your Services then keep it simple.

              Most of the time there is no generic approach and it's all based on the company's requirements.


              Here are some examples how others define their service catalogs.

              The more advanced/detailed service catalogs are needed when you want to implement Service Level Agreements (SLA), OLA etc:


              "Keep it simple" examples:






              Advanced examples: