locked
Treat child classifications as the parent classification for purposes of workflows, etc? RRS feed

  • Question

  • I'm sure the answer to my question is already out there, but I'm not finding anything and can't figure out the right combination of search terms.

    I'm looking for a way to treat the children of a classification as part of the parent classification for the purposes of workflows, views, queues, etc. Basically, I have an incident classification list like this:

    Level 1
        Level 1-1
        Level 1-2
            Level1-2-1
    Level 2
        Level 2-1
            Level 2-1-1

    And so on. No more than three layers deep at any time. My problem is that when I tell a workflow to, for example, apply a template to all incidents with a classification of "Level 2" it takes me at my exact word, and does nothing to child classifications like "Level 2-1" and "Level 2-1-1." Similarly, views containing incidents of classification "Level 2" do not contain incidents of "Level 2-1" and "Level 2-1-1." The only way I can figure out to make everything show up is to have some kind of massive OR statement in my workflow, view, subscription, etc, that basically says "Classification equals "Level 2" or "Level 2-1" or "Level 2-1-1" and so on, which is incredibly time consuming and error prone to create, not to mention this requires manual maintenance each time I add or remove a classification.

    I want the granular classification that the multiple layers provides me. But I want to treat all the sub-levels and sub-sub-levels as all part of the top level category when I'm running logic against the classification field. So is there a way to tell SCSM to treat the children of a classification as "part" of that classification when evalauting logic? This seems like a fairly simple request, but I just can't find any information online.

    Thanks,

    Andrew


    Andrew Topp
    Monday, November 7, 2011 8:51 PM

All replies

  • Hi Andrew,

    I'm afraid you are on the right track, I don't think there is an easy way around this. The sub-levels, sub-sub-levels etc. is just for human eyes. The system still see the classifications etc. as isolated from each other, no matter how we group them in tree structures.

    Monday, November 7, 2011 9:04 PM
  • Per_SC, thanks for the quick reply - can someone from Microsoft confirm this? If that's the case, then this is a critical failure in the product. My current client wants to have a couple hundred different classification categories, and while that may be more than they should have, the product certainly should be able to handle grouping these or some kind of logic that doesn't require me to manually create a hundred clause OR statement every time any type of logic tries to interrogate an incident classification. The client is going to have to radically revamp the way they track incidents if this is the case.

    Is there some way to handle the classification separately? For example, the only logical operators when I'm creating workflow logic from the GUI are basically, "equal", "not equal", "null", "not null". Can I do something like "classification contains?" or key off the relationship in the management pack where I'm storing the classifications, since I know that the parent/child relationships are stored in that management pack? Do I need to manually edit my management pack - is what I'm trying to do possible by editing the XML but not possible from the GUI?


     

     

    Andrew Topp

    • Edited by androidtopp Monday, November 7, 2011 9:51 PM
    Monday, November 7, 2011 9:18 PM
  • Hi,

    There is a syntax called "under" which gives you a certain list item and all its sub-items, but I can't remember how and where it can be used... Maybe someone else does?

    Regards
    //Anders


    Anders Asp | Lumagate | www.lumagate.com | Sweden | My blog: www.scsm.se
    Monday, November 7, 2011 10:11 PM
  • Hi,

    You could extend incident class with two properties (FirstLevelClass, SecondLevelClass) with Authoring Tool. Then you would create a workflow that woud assign those two properties with coresponding classifications based on incident classification. You can do this with SMLets. Than you can use those two properties in views and workflows. It's not a clean solution but it would work.

    Regards!


    http://www.purgar.net
    Monday, November 7, 2011 11:34 PM