1 Reply Latest reply on Jul 30, 2015 3:46 PM by dmshimself

    Handling multiple incident or change types with 1 LD database

    NickBrown Apprentice



      Here is a concept my team is currently trying to figure out. I reference change in my example, but the same idea is being applied to Incident.


      We have one company with multiple departments with multiple uses for a change process (think Change management - one group needs a change management process a certain way another needs it another way - both follow ITIL workflow but their data is much different from one another). What we have done in the past is have the different objects/attributes all under the same Change object. For example group A has a specific Change process they need - we would build that "bundle" (objects, windows, process) properly all under the change management group. Then Group B has their own as well - we do the same thing - Group B "bundle" of objects, processes, and windows.


      However, what we have found is the objects that are created under the main Change management object (likewise with Incident) for both Group A and Group B are being written to no matter who uses the processes. When Group A creates a Change Ticket they are writing NULL values to any attribute in the Change Management process that is for Group B attributes and vice-a-versa. It may not sound like this is a bad thing but when you start to get into the 100 of thousands of tickets range this starts to add up in the processing time. This matter only gets more complicated if you add Group C, Group D, etc...


      In trying to solve this, came up with two conclusions. We could essentially "recreat" the Change object to create a "Group A Change" object and a "Group B Change" object and essentially link everything that is already linked to the OOTB Change object to our new Group A Change/Group B Change from their corresponding objects. This leads to questions such as, what would happen during an upgrade and schema change to the DB? Is this type of thing even possible due to the OOTB build of LANDESK and the inherited objects from Process? Or is the best solution to simply say, Incident/Change objects only get attributes that apply to ALL Incidents/Changes and anything else needs to essentially be a collection on the Incident/Change and gathered in a new Window? From a workflow perspective, this feels really "slow" and in a way counter-productive from what we're trying to accomplish.


      I guess the question is - has anyone run across this problem? And what's the best solution to resolve it?

        • 1. Re: Handling multiple incident or change types with 1 LD database

          I would have thought it would only write nulls when the change was saved, so most database servers would be able to eat that sort of workload.  But I'll not comment further on that!


          It is not advised to make an object lifecyclable unless LANDESK do this and their SI team would generally charge for that work.


          But what you could consider is getting the Change domain cloned to Change A.  That gives you a legitimate extra change domain with unique privileges specific to that area.  So you can split things out between the two groups.  There are some limitations of a cloning, so I recommend you discuss that idea with someone at LANDESK.  Specifically ask them for a list of functions and features that will not function with a cloned domain.