These are already fully functioning pre-conditions. There is no more that you need to do with them, but you need to review the task processes that you are going to use to ensure that they have the correct end statuses to match the main process behaviour. Typically, customers use the standard task processes that come out of the box, but they also build their own to cover a number of scenarios that enhance the function of the service desk.
I was thinking if it was an already fully functioning pre-condition that there would be an action I could select that would send one to the "all tasks at end state" \ resolve \ resolve Notify
I think I'm starting to understand this a little better.
It passed via the notify originator and Knowledge to Resolved
If you select the Notify Originator check box on the Resolution window, the person to whom the Incident is currently assigned is notified that the Incident has been resolved. (This is done using a reminder as an automatic action.)
"Are all Tasks at End state?" is what is called a precondition. This means, this statement must be met before you are able to see or have access to what follows. In this case, if there any tasks not at the "End State", then you will not be able to use the "Resolve" process action or the action listed in the other precondition of which we can't see the action. So, once the precondition is met, you can see whatever is following those preconditions.
The Notify Originator check mark box is a Boolean could be used to route/direct the process flow to one of the decision points(diamond). The Decision point asks a question and follows the answer to the question. So if that check mark box is being referenced in the "Resolve Notify Originator" decision point, then the answer was yes(since it was check marked or vice-versa, depending on build), it will follow the yes process line.
Hope this helps.