Field Service

Get Involved. Join the Conversation.


    Chris Phillips
    Routing linked activities in different buckets
    Topic posted April 22, 2019 by Chris PhillipsSilver Medal: 2,000+ Points, tagged Routing / Optimization 
    74 Views, 1 Comment
    Routing linked activities in different buckets
    How to automate scheduling of linked activities in different buckets

    Hello all,

    I'd like to reach out to the OFSC community for ideas/suggestions regarding routing linked activities. I am currently working to implement OFSC to a new area within our business. As part of their process, there are linked dependencies where activities must be done either at the same time as one another, or for one to start after an interval of when the other has finished. Typically we'd achieve this through link templates. The challenge we currently have however, is that these activities are across different business teams who are defined as separate buckets in our resource tree. 

    My understand is that routing will only consider the activities in the routing bucket when it runs.

    Currently we will have Activity A linked to Activity B

    Activity A is in Bucket A, and Activity B is in bucket B. Ideally we would want to be able to run routing on either bucket, and for OFSC to identify the links between the two and route both activites, regardless of the bucket they are in. I believe this is not possible with current functionality. 

    Other than creating a routing bucket at a higher level within the resource tree and having all activities being created in this bucket, does anybody on this forum have any suggests on how we might be able to achieve this?


    Kind Regards




    • Graham Sawell

      Hi Chris,

      It’s a tough one without the detail, but my recommendation would be to move the logic to a bucket level higher.

      I’ve seen clients routing teams separately because they don’t trust the engine to partition off work adequately or to gain more control over the schedule, or sometimes just because the uphill struggle with change and implementation means that battles are carefully chosen, with areas like this seen as bridges to cross in later phases.

      The benefits of OFSC’s heuristics are easily handicapped by smaller sets of data to work with, which then amount to hard limitations as far as efficiency is concerned, but also regularly dampen the operation’s ability to trace a decision back to its origins, as well as to improve and automate a level of calm in the controlled chaos of the day-to-day.

      The part that sticks out to me here is that to effectively evaluate the decision of who does the linked job, we either have to consider the priorities and limitations of both teams, or we have to consider the priories of one group and force the other side to adhere. If we're going to consider the priorities of the other team, that means we're doing exactly the same as higher level bucket would, only with more to maintain and fewer benefits.

      I’d sooner look to give OFSC all the tools to make a decision across two teams and come to a compromise. Not to mention that there may also be great opportunities currently missed, perhaps they work entirely different functions, but that could be an opportunity for more cross-skilling or a more efficient PPM schedule that takes advantage of opportunistic ‘right place right time’ moments to hit two birds with one stone. There’s something to be said for those moments where there’s a ‘call to arms’ situation, and you need only consult one bucket, especially in reactive cases.

      If there’s too much pressure from the business or a genuinely exceptional reason not to work this way, then your next best bet would be to force the scheduling of the linked job. I’ve not found an acceptable way to do this OOTB (it’s likely deliberately designed this way), but I’ve used the Find matching resources API to find the best match and force it on the schedule in circumstances that have called for it (

      I hope this helps. Any questions just shout.