Video Screencast Help

Recurring Incident Capability in ServiceDesk

Created: 02 Dec 2010 | 8 comments
grubu413's picture
3 Agree
1 Disagree
+2 4 Votes
Login to vote

We would like the ability to create incidents on a recurring schedule in ServiceDesk.

I know there are ways to perfrom this action if we use SQL or Change Management but it would be very helpful if this feature was put into ServiceDesk Incident Management.

Comments 8 CommentsJump to latest comment

smassie's picture

I have a number of customers who have recurring incidents set up in HD 6 to provide an audit trail for critical tasks they have to do. for example check on weekly backup status.... they need these for auditing and management reporting purposes. it was very easy to set up in Hd6 and oh that it was as easy to set up in Service desk and didn't require programming expertise that is essential to using workflow.

Please?

0
Login to vote
Nurb4000's picture

Just make a monitor type project that creates a ticket based on your template and have it run on whatever schedule you need.

Sort of like how the mailbox monitor works, but its not 'reading' any data..

0
Login to vote
smassie's picture

Just make a monitor type project...  i.e write a program that does it.... I rest my case

It took me less than 2 mins each to set these up with HD 6 - While doing this in Workflow and SD7 is a rediculously complex and lengthy...

This should be simple to use out of the box functionality and it shouldn't require me to write my own program to achieve what is an essential requirement.

0
Login to vote
Nurb4000's picture

That is sort of the attitude that Symantec has taken with ServiceDesk from what i can tell. "its built on the Workflow platform so you can do anything you want". My impression is its not meant to be a complete 'out of the box' solution for anyone, but be the lowest common denominator starting point for everyone.

And remember its not a replacement/upgrade for helpdesk 6 really, its a new product that is a 'ServiceDesk' .. ( whatever that means, its all marketing speak as far as im concerned )

For what its worth i spent 6 months writing custom code for what i also felt was basic functionality in an enterprise environment.

 

( Tho to be honest coding up a WF to do what was suggested should ake no more than 20 mins. )

0
Login to vote
matzebru's picture

The problem is I have over 55 Notification Policies doing 100 + tasks all on different schedules. Some of these Notification Policies are emailing reports on a schedule but the vast majority of them are creating tickets on daily, weekly, monthly, quarterly, annual and ad hoc schedules (when certain conditions are met). So multiply 20 minutes by 100 and you can see why no longer having the capability we had in NS 6 that was so easy could be considered painful by some.

Myself, I'm really not complaining. I just can see both sides of the coin. I personally see it as an opportunity to review this mass of tasks we have setup in NS 6 and see if they can be trimmed down a bit. Plus, having Workflow experience already, I see it as a welcome challenge to my Workflow skills. But I can certainly see the argument from the other side too.

- Bruce

 *** If a forum post solves your problem, please flag it as a solution. If you like an article or forum post, vote it up. ***

0
Login to vote
smassie's picture

I appreciate SD 7 is a start again from scratch product but there is actually not a lot of difference in the concepts behind HD6 and SD7 - though there is in the core functionality provided and in ease of use.

HD6 was written in VB.net which at the time it was originally developed was the new programming language. It was architected in such a way that if you had some programming skills you could do just about whatever you wanted with the product. And a few of us around the world did just that and created capabilities that customers required and which are still missing from the SD7 product. However HD6 also provided a set of capabiltiies that enabled your basic Service Desk manager to configure the product to do what they wanted quickly and easily.

With SD7 we have moved to newer version of the programming environment - an advanced version of VB.Net called workflow, which uses pictures instead of words and which gives some plusses but also some minuses. But we have lost that high level configuration capability that could be used by the average Service Desk manager. To go from 2 minutes to implement a basic requirement to 20 minutes (with programming skills required) is actually a massive step backwards, and not something your average organisation will accept.

The trouble is we have an emperors new clothes scenario here. Everyone in Symantec is saying Workflow is the answer to the worlds problems because that is what they have been told, when in reality the emperor is naked and all they really have is an advanced Macro porgramming language.

I've been in the IT business for over 30 years and used to sell engineering software. Every engineering software package had a macro programming language based on whatever was the latest programming platform (Pascal, C, VB, etc) These enabled customers to automate processes which involved the engineering software package and whatever else... having this capability was expected. So I don't see anything special about Workflow but rather see it as something that has been long overdue.

And importantly it I don't see it as being an excuse for not providing basic functionality in a product. You might as well give someone VB .Net and tell them it's a helpdesk solution and all they need to do is to use this to create what they want. The thing is IT staff generally are pressed for time and therefore really appreciate solutions that make their lives easier without then having to invest too much time into them... 

0
Login to vote
Nurb4000's picture

I tend to agree that moving to WF in several cases has been a step backwards, but at the same time if the product was sold upfront as a 'development' platform i think most of the hard feelings would be take care of.

What they should have done is continue to offer traditional 'canned' applications with normal features, and then continue to sell WF separately as a development platform. Sort of what was happening with HD6 and WF6.

After dealing with SD for over a year now, i can also tell people that it is NOT an out of the box replacement for heldpesk, even tho it was 'marketed' as one.  

+1
Login to vote
luis_7a15's picture

Hey guys, have you some example of autostart project that creates an incident in a scheduled way?

Thanks.

Luis.

0
Login to vote