1 of 1 people found this helpful
Remember that the design of ServiceDesk is not arbitrary, although it does allow expansion of process design in a lot of different directions. At the core, it's designed to rely on ITIL principles, so it has some limitations that way, in terms of keeping sight of who is the responsible party in regards to a particular incident/unit of work.
Also I think they might have limited some design decisions to keep us from over complicating things (on second thought, nah, that is still plenty possible) and making bad process designs that are doomed to stay open forever and violate every SLA.
I think you have to work within the 1-request =>many tasks model. I can't say for sure whether it's possible to make your process invoke another instance of itself, but I wouldn't think so.
I have successfully chained tasks by using an external batch file to update the LANDesk database.
1. Create the task in advance, but dont schedule it
2. Use a SQLCMD command to set the time for the task to start to the current time.
3. Ensure any other value that the task relies on (max retries) are also set.
The task will start at the time set, or if the time is in the past, it will start immediately. Here is my example batch, where I read a number of tasks in from a text file, an run them one after another.
echo Created New Log > C:\TaskService.log
Time /t >> C:\TaskService.log
Date /T >> C:\TaskService.log
for /F %%A in (c:\Task.que) do call :SetStatus %%A
exit /b 99
timeout /t 4 > nul
echo Starting Task %1 >> c:\TaskService.Log
sqlcmd -S tcp:annmondb01 -d LANDesk -Q "update LD_TASK SET MAX_RETRIES = '0' WHERE (LD_TASK_IDN = %1)" >> c:\TaskService.Log
sqlcmd -S tcp:annmondb01 -d LANDesk -Q "update LD_TASK SET TIMES_TRIED = '0' WHERE (LD_TASK_IDN = %1)" >> c:\TaskService.Log
sqlcmd -S tcp:annmondb01 -d LANDesk -Q "update LD_TASK SET RESCHEDULE_TYPE = '2' WHERE (LD_TASK_IDN = %1)" >> c:\TaskService.Log
sqlcmd -S tcp:annmondb01 -d LANDesk -Q "update LD_TASK SET NEXT_START = getdate( ) WHERE (LD_TASK_IDN = %1)" >> c:\TaskService.Log
timeout /t 4 > nul
sqlcmd -S tcp:annmondb01 -d LANDesk -Q "update LD_TASK SET TASK_STATUS = '0' WHERE (LD_TASK_IDN = %1)" >> c:\TaskService.Log
timeout /t 10 > nul
sqlcmd -S tcp:annmondb01 -d LANDesk -Q "SELECT task_status FROM ld_task WHERE (LD_TASK_IDN=%1)" | find /V "rows affected)" | find "1"
if %errorlevel% == 0 goto BeginAgain
echo Task %1 Completed >> c:\TaskService.Log
This reads in the task numbers from the TASK.QUE file.
I've seen a couple of solutions. The first is to have an incident process called 'Task'. The process flow looks like the regular task process but allows you to have a long chain of parent child relationships as you can always add/create child.
The second is to add a relationship from Task to Incident You can then have an action on a Task which creates an Incident which can then have a Task which ... and so on.
Both designs have their place and I've actually found it be quite a rare requirement. Sometimes the incident process itself can be used to control the creation of tasks and that might be another route to look at
Can you let me know how to link task process like task A , task B and Task C with incident process liken Incident A , Incident B and Incident C?
Well if we are talking about the first option (having an incident process called task and using this just like a task) then you just use standard LDSD functionality to link process together. Add Parent/child, create parent/child, detach and so on.
For the second option I commented on, linking is probably not the right word as linking is done specifically by hard coded operations within LDSD. What you can do is add a new relationship in object designer from the task object to the incident object. That gives you a way in a task process of being able to create an incident from a task process and link them together as part of that creation. This worked well for the client who needed it. However I haven't looked into wether you could detach things - it wasn't needed for that design. I hope this helps.
I just found it. My Scenario was like that Dear Support,
My Scenario is that : I have 2 Incident Processes Say " Normal Incident Process" and "General Incident Process".
I have "Add Task" As an optional Action and I have 2 task Process now first one is " Normal Incident Task Process" and second one is " General Incident task Process". But "Add Task" optional action is common for both Incident Processes which are " "normal Incident Process" and "General Incident Process". So, how can I configure 2 tasks Process with 2 Incident Processes. I know that If I can create Manual Action
I just found that when optional action is Added to the status like “Add task” then it’s default task process can also be linked.
Dave, Can you let me know regarding the Logic behind the "Is Active" Boolean Attribute in Add Reminder ? beside "Is Active" is there any calculation or else going on ?
In your process make sure you use the property in process designer on the action creating the task to select the specific task process you want. The default process may be what you want, but you can also chose another one.
Is active simply means the reminder hasn't been sent yet. It will be cleared by the outbound process when that sends the email. No calculation, just standard functionality of LANDesk. I recommend reading the following article ...
Thanks for your reply. I just check the doc All I need to understand I just created Task Reminder under Incident Management Module and created similar "Is Active" Attribute with same name. Is that fine .... or I need to do else ?
The standard task reminder already has everything you need, including the Is Active attribute. If you don't have that attribute I recommend you don't go any further and instead raise a support call with your local support team. You could also restore the standard OOTB database and take a look there for comparison.