Field Service

Get Involved. Join the Conversation.


    Activity to be Continued on the Next Day
    Topic posted October 5, 2017 by Todd Bronze Medal: 1,250+ Points 
    183 Views, 4 Comments
    Activity to be Continued on the Next Day

    I wanted to put this out here to see how others may be handling this use case.  Say a Field Tech has 5 activities assigned to them and start and finish 4 of them, he starts the 5th but can't finish it and would need to finish it the next day.  It is my understanding that Suspend status is for completing the activity later on the same day, but we are needing to Suspend it and then start it up again on the next day.  It isn't necessarily a multi day activity it is just that he couldn't quite finish it.

    Any input would be appreciated.




    • Shaun Nicely - Helix Business Solutions

      Hi Todd,

      There are 2 ways I can think of to handle this requirement. 

      1) Suspend Activity - You are correct when a technician suspends an activity OFS will create a clone of the original activity as a non-ordered activity on the technician's route to be completed that day. This activity can then be rescheduled either by the technician (if they have that ability) or a dispatcher/manager to the next business day. 

      2) 'Not Done' status - The not done status is meant to be used in cases like this, where the technician is unable to complete the activity for any reason. The technician would select 'Not Done' (with an appropriate reason, such as 'Reschedule for tomorrow') and OFS can be configured to send an outbound notification to the host system with the information. The host system can then process this notification and create a new pending activity on the technician's schedule for the next day. 

      I hope this helps give you some ideas. Please let me know if you have any questions. 



    • Brett Wallace

      Hi Todd,

      I agree with Shaun, on these two solutions.

      I would like to add, that the theory behind the suspend functionality is to be used for completion of the activity on the same day. Whilst this is the theory, there is nothing stopping you from doing as you and Shaun suggest and suspending the activity, rescheduling / moving it and completing the next day or some day later. In fact most of my clients prefer to use this method over the not done for a number of reasons, and the use of either method really depends on your business requirements / processes. E.g Does the activity have to be completed by the same technician? 

      Some reasons to consider using suspend:

      1. Creating a new activity for the next day is done by OFSC natively, unlike "not done" case. Although it does require rescheduling, this can be done at the point of suspension by the technician (if they have permission).

      2. In most cases it does not involve extra middleware / external system work to create a new activity as in the not done case.

      3. If the activity has to be completed by the same technician, less effort is required by people/system/integration to make sure the new activity goes back to the same technician as opposed to using not done method.

      4. Working out the duration across both activities may be easier through reporting.

      Lastly I want to highlight a common misconception. When the activity is suspended, the original activity is suspended and a clone activity is created as "pending" and not ordered. This is not correct.

      What happens is the clone is created and then placed in the route at the position the original activity with a status of "suspended" and the original activity is changed back to a status of "pending" and made not ordered. Hence the original activity moves forward to be completed. This behaviour makes sense because it means the external systems can still reference the activity without changes (in most cases).



    • Todd

      Thanks for your input Brett and that is the idea I had was to suspend it and then have technician Move it to the next to then complete.  The upstream system was updated and the cloned activity is still tied back to the upstream system.  The next thing I'm looking at is if the Duration that is being updated in the upstream system will take into account both days.  For example, if I start it today and work 30 minutes then suspend it and move to tomorrow, the clone is made in pending status I start that cloned activity the next day and end it working for 60 minutes.  I would need the duration in the upstream system to reflect 90 total minutes.  All our activities are being created as not ordered so that the technicians can decide which one to work first as this isn't a mobile situation.  In our case the same technician will always work on it and they will potentially get paid by the total time worked on all activities which is also sent to an upstream system.  Are you saying we couldn't capture the total duration of both days?  Any other thoughts except reporting that could accomplish this?


    • Brett Wallace

      Initially I thought you might be able to update a property on the original activity with the duration from the suspended activity, and then report it all through when the activity is finally complete, however from what I can tell the system does not support this. 

      So to capture the time for both activities (and more, if they suspend activity multiple times) you should use the suspend event to send the duration of the suspended activity to the upstream application, which then adds this duration to the existing duration value stored in your upstream system. Then on the complete event you again send the duration, and have the upstream system  add this as well which will give you the total of all activities.