Best Known Method: Working with Preconditions and automatic actions

Version 9

    Verified Product Versions

    Service Desk 7.6Service Desk 7.7.xService Desk 7.8.xService Desk 2016.xAsset Manager 2016.xService Desk 2017.x

    The following best known method is designed to explain how to how use preconditions with automatic actions. It is recommended that all design work is done within a test environment.


    The scope of the LANDESK Support services do not include the provision of assistance with regards to customer’s unique requirements. Should assistance be required to produce processes aligned with specific business needs we recommend to contact LANDESK Professional Services or your preferred LANDESK partner.


    What are Preconditions and how are they used?

    Preconditions are used to prevent a process moving forward without a predefined condition being met first. Preconditions may be used in the process after a status in the process. Some examples are given the diagram below:




    Preconditions are useful for tasks such as automatically closing Incidents, Problems or Changes on creation or making actions available when certain criteria are met.


    When are Preconditions re-evaluated?



    1) Preconditions which are followed by automatic actions are only evaluated when the status is first entered.


    This means that if a status is entered and the value being evaluated is changed after saving the precondition and automatic action will not be re-evaluated.


    2) From 7.5 the preconditions are re-evaluated when changes are made as and the process updated (for example the category on an Incident)


    The following process shows how using an automatic action with a precondition behaves. When an incident is logged with ‘next status’ in the Title field, the process will then move forward to the 'closed' status. If the Incident is logged with a different value in the title field and the Incident is saved, then the title field is changed to 'next status' the process would then not move forward. The close option would be displayed but the process would not automatically pass to the 'closed' status.






    3) Status changes in linked processes


    When a the status of linked process is updated, the process will reevaluate any preconditions with automatic actions. For example, if a change is added to a problem and the Change process status changes, a pre condition with an automatic action in the Problem process would be re-evaluated. This means that pre conditions can be based on the status of linked processes. A status Change in the change process could be referenced in the Problem process. Then a status change in the Problem process could be referenced in change process and so on. The processes can refer to each other a maximum of three times in any one set of status changes.


    The example below shows how an update in the Task process can move the Incident process forward which happens after the status is entered. The following Incident process would move to ‘closed’ when the ‘move process forward’ action is selected in the Task process.


    Can I have a precondition fire after a set period of time? No, Preconditions only re-evaluate when the on the events mentioned in the section above. It is possible to use a scheduled bulk action see solution 2 from below.


    Problem: The process is not Two sets of preconditions followed by automatic actions



    The following process shows how using two preconditions and automatic actions in a row behave. If the incident is logged with 'next status' in both the title and description fields, the process will move forward to the 'resolved' status. It would then show the close action but would not move forward to 'close'. It is not possible to use two preconditions with automatic actions as shown below. This is because the process could loop indefinitely if the process linked back to a previous status.



    When using a precondition and an automatic action are there any ways to move the process forward?

    If the above processes used manual actions they would work as expected. The process would display resolve and close as available actions when the preconditions were passed. The following examples are ways in which the process can be designed instead of using manual actions or with additions. Whether they are suitable would depend on the process that is being designed.


    Solution 1) Add an additional precondition that checks if that checks if a fall through is going to occur


    The extra decision will prevent the fall through if both conditions are true. If the second condition is false (in the example Is description next status) then the process will wait at the status till it is resolved to true.





    Solution 2) Use a manual action with a scheduled action



    A scheduled action can be set to run a manual action at a particular time.  The scheduled action can be set up as below when using the process above.






    Task Process