Skip navigation
1477 Views 4 Replies Latest reply: Sep 8, 2011 11:53 AM by aparker RSS
Rookie 1 posts since
Jul 19, 2011

Has received 1 of 9 achievements.
Currently Being Moderated

Sep 7, 2011 8:01 PM

After instructions on how to set up conditions for inbound email LDSD 7.4

Hi LANDesk Community,

 

I am hoping someone out there has a plain english way to perform what we want tio achieve.

 

The business is changing the way we handle triage, hence a 3rd party organisation are assigning incidents and service requests for us.  Now as it is like a "pay per action" kind of agreement, we want to place some smarts that will automatically assign incidents to the appropiate support group and only initially touch the open default support group they are triaging.  Preferably not touch the main queue would be the desired result.

 

We have say 4 support groups for example.

 

Operations

Info Management

TDT

Business Apps

 

I'm looking for a way in LANDesk 7.4 on creating rules similiar to what you would set up in outlook.

 

EG: if the subject and|or contains the phrase "delete document" or "delete file" then place the incident directly in the "Info Management" Support Group queue, bypasing the default support queue.

 

I'm hoping someone can supply an answer where I can add some rules or "conditions" that will assist in delivering the appropiate incidents/service requests to the appropiate support groups and avoid triage of the standats default "Support group".  I have had someone from Irontouch suggest setting "Conditions" in "Process Design" but don't know where to start.  Where do you actually add these "conditions" in LANDesk 7.4 "Process Design"?

 

Thanks,

 

Wayne.

  • hewy06 Expert 293 posts since
    Nov 8, 2010

    Has received 7 of 9 achievements.

    Hi Wayne

     

    We don't use inbound mail so I can't advise you there but if you check out this guide it covers basic Process Design

     

    http://community.landesk.com/support/docs/DOC-22092

     

    I'm assuming that an incident is created from an email and the subject line in the email becomes the title field in the incident (that's a guess) so you might have 1 decision to see how the incident was created and if it was from an email (true) then it moves to another decision to see what the title field contains and then moves to an assignment to the relevant group or whatever.

     

    Not having used inbound mail this is all guess work as to how the incident is actually created but I'd say the above guide is where to start.

     

    Helen

  • Apprentice 93 posts since
    Jun 11, 2009

    Has received 2 of 9 achievements.

    Hi Wayne,

     

    In addition to what has already been mentioned, the way we have a (very basic) form of this setup is using conditions and assignments at the beginning of one of our process designs.

     

    In this process we have a condition that checks to see if the incident category has been set yet (among others), which is a simple yes/no check.

    If the answer is yes, then the call proceeds normally to our default 'In Progress' status. On the otherhand, if the check comes back as no then we know it's a call that's been logged externally to our department, such as by email or via the customer portal, for example. This will then be followed by an assigment, which can be created to send the call to whichever group you specify.

     

    So for example:

     

    Condition 1

     

    Is title 'Delete Document'? Y/N

     

    N - Continues onwards to the next condition in the chain

    Y - Is assigned to the group you specified that handles these requests instead (via an assignment).

    |

    |

    |

    Condition 2

     

    Is title 'Delete File'? Y/N

     

    N - Continues onwards to the next condition (or to your default group/status)

    Y - Is assigned to the group you specified that handles file deletions (again, via an assignment).

     

    Take a look at the screen shot below, this shows the beginning of our incident process, it's fairly simple but it does show the category check I mentioned near the top, and also, a few other conditions; so you can see how these checks are done in sequence and flow from one to the other.

     

    It's fairly simple once you have a play around with it.

     

    I'm  not sure how many conditions you can have in a chain, (I think there is a limit) but I'm sure someone here will know - it depsnds how many different calls you're planning to check for, if there's quite a few then something with calculations may be needed, to keep the process design from starting to look like a piece of modern art.

     

    Condition example.JPG

     

     

    I hope this helps a little.

  • hewy06 Expert 293 posts since
    Nov 8, 2010

    Has received 7 of 9 achievements.

    You can have up to 8 conditions/decisions in a sequence.  I have the following printed out and on the desk or else I'd never remember!!

     

    http://community.landesk.com/support/docs/DOC-6885

     

    Helen

  • aparker Employee 593 posts since
    Feb 18, 2009

    Has received 6 of 9 achievements.

    Hi Guys,

     

    I believe this restriction has been removed from 7.3.x onwards.

     

    Andy

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 20 points
  • Helpful Answers - 10 points
LANDESK Community powered by Jive SBS® 4.5.7.1  |  Legal Notices  |  Privacy Policy  |  Icon 

TweeterOn Twitter  |  Icon FacebookOn Facebook © 2007 LANDESK Software