Servicedesk supports Service Level Agreements (SLA) for incident management.  They have  basic parameters that need to be set for them to correctly calculate late times, times for escalation, etc. While testing an issue, we noticed a problem when setting up the following custom scenario configured in the SETUPSLAREQUIREMENTS model contained in the SD.DataServices decision model:

1.  Business hours are set to 8:00 am to 5:00 pm - a 9-hour window each business day.
2.  A 4 hours SLA was desired before the first late activity engages, basically guaranteeing a  4 hour minimum time to work value.

A new incident is entered at 4:00 pm on a working hours date, putting the first late activity to be scheduled  for this case to occur at 11:00 am the following day.  One hour of time from 4:00  to 5:00 pm, and  3 hours from 8:00 am to 11:00 am the following day.  Unfortunately, the resulting SLA date gets set for 8:...

There have been many questions and concerns about the ability to remove changes, incidents, and problems from the Servicedesk database.  Many build up test systems, customizing workflow components,  portal pages and  reports to meet the specific needs of their environment.  They then would like to just start with a fresh database, unencumbered by old data that is not relevant.  Does this capability exist, and how would it be used?  If not, what are the best workarounds to accomodate this issue?

Unfortunately, incidents can be resolved and closed, and changes and problems come to completion and closure.  But not removal or deletion.   Once the items are in the database they are there for good.  There are feature requests underconsideration to change this.  

Working around this problem, however, should not be too discouraging.  Simply reinstalling the environment is the best workaround,   This...

After reviewing the Servicedesk 7 customization guide (Pages 34-35), and knowing that SLA's (Service Level Agreements) were important for Incident Management, I began my quest to modify the SLA for Problem Management.  I had made all of the changes necessary, and created a few problems from my incident pool.  However, I noticed that none of the due dates or late dates had changed.  Where had I gone wrong?

Well,  as it turns out, I did everything correctly.  Further research showed that, during the development and documentation of Servicedesk 7.0, although not required by ITIL, it was thought that having a configurable SLA for problems might be useful for customers.  So a preliminary implementation workflow was started, and included in the customization documentation. After release and further review, it was decided that, since ITIL does not have a SLA requirement for Problem Management, that this documentation and preliminary workflow...

Thank you to all of those who have joined the Altiris Cincinnati User Group.  Please pass the information onto your team members and anyone else in the Cincinnati/Dayton/Northern Kentucky area.  We would love to see this group grow and be able to host an event here in Cincinnati.  Look forward to meeting all of those who use this fantastic product.