Hi Roel,

The reason for the distinction here is that for committed activities, the order in which the resource carries out the work is pre-determined by the input data. This means that for each committed activity the DSE will only need to calculate a single journey to the committed activity, from whichever activity the resource is scheduled to visit before (or perhaps the resource home location). For schedulable activities, the DSE can choose where to schedule each activity, and so potentially could be scheduling it after any other activity in the schedule, and starting at many different times. This of course massively increases the number of potential journeys that need to be considered, and so the number of calls that would need to be made to a real time travel provider in order to use this data for schedulable activities. Unfortunately this can’t be used efficiently on any reasonable sized schedule, even if it were only applied to a limited number of activities. As such, we only recommend using this feature for committed activities.

Thanks,

Paul

Hi @Paul Smith,

Thanks for the response, that makes a lot of sense. If the activity for which the travel is getting calculated is not committed yet,  it would basically have to calculate the travel for all possible resources/times in order to know all the possibilities and get the resource with the shortest travel time allocated.

Taking this into account, would there maybe be a way to get this data only for exception cases? For example there is an urgent task coming in and it needs to be assigned to the closest available resource, is there a way to get the travel time for all or a selected set of resources that uses the real-time travel data?

Thanks,
Roel

Hi Roel,

There isn’t anything to do this at present. I guess the best thing to do would be to raise a request for it and then we could look into what might be possible (I think you do that via the ideas page).

Thanks,

Paul