question

First of, you entered "item.dispatcherNo" in the "Send to Port" option. That one controls through which output port the item will leave the queue. In both cases there is only one connection, so that option should just remain as "First Available".

Instead you want to open the code for the "Use Transport" option. There, the dispatcher, the task sequence is send to, is set to "current.centerObjects[1]". Here you should replace the 1 with "item.dispatcherNo" to send the tasks to the correct dispatcher (instead of the one connected first).

Do the same in the code of the "Use Operator" option of the processors.

current.inObjects[1].centerObjects[1] 

becomes

current.inObjects[1].centerObjects[item.dispatcherNo]

Now, to sending the tasksequence of the "mixed"-operator, who ends his shift, back to the correct dispatcher. As this will not trigger the "Pass To" option of the operator I instead connected it to a new dispatcher, that then connects back to the original ones.

In this dispatcher's "Pass To" option, I use the fact that the second task of the task sequences is loading the item. That way I can get a reference to the item and the label on it, to send the sequence to the correct dispatcher.

TaskSequence taskSequence = param(1);
Dispatcher current = ownerobject(c);
/**Dependant on item label - custom*/

TaskSequence.Task LoadTask = taskSequence.tasks[2];    // Second task is load task

return LoadTask.involved1.dispatcherNo;    // involved1 points to item in load task

If you have more that one type of task sequence in your main model you might to find a different way to get a reference to the involved item.

These changes were made in the attached model.

shiftsample_1.fsm

With all of this said though, I would suggest you think about using a process flow for this logic instead. Using the operators as a resource, distinguished by a label to be able to query for the correct "type", would likely be easier than using dispatchers and 3d-model-logic.