You can use Task blocks to halt the request until the task is completed, at which point you can have a different task fire for Team B. If Team B is only linked to the completed line of the task for Team A, they will only get a task created once Team A finishes their work and completes their task.
Here is an example.
Tasks are sent to multiple teams, but the WF wont complete until all the tasks have been completed (Through the join block). You could just as easily put another task block after the join.
Thanks Chris that example is very helpful! Can you explain what the "Invoke Workflow" block does that you have right before the stop? and why you use that type of block as opposed to another task block?
Thanks and apologies for what I know is a 101 type question.
As the name implies, it just fires another workflow. This one is a special case in terms of request offerings and you will see this same thing in many of the OOTB offerings.
It's so the service request can still 'manage' ad-hoc tasks that weren't added as a part of the main fulfillment workflow.
This is the workflow that gets launched. All it really does it wait until all tasks have been completed in the offering, at which point it updates to fulfilled.
The wait block has a timer of 10 days, so if it's not able to update to fulfilled after 10 days, it throws an error. Since the previous WF was already using a join block to wait for the automated tasks to complete, this is for any tasks that weren't a part of that WF.
So in the case of the above example, it basically has a 'sub-process' that is watching the status of all tasks while the main offering is responsible for the lifecycle of the automated tasks. It has a 10 day timeout if it sees that all tasks aren't completed. This allows you to create tasks that weren't a part of the initial automation and still have them be tracked in some sense. Once all automated tasks are completed, a 10 day timer starts for the completion of any tasks that are still on the service request. If they are all completed or cancelled, it will update the offering to fulfilled. If it times out, it will send the error notification out instead, telling you to check the tasks of that offering. It then stops.
I would recommend you add that last block to the workflows like that if you expect ad-hoc tasks to be added and wish to track against them.
In your case, you'd probably want next task blocks to only fire once the previous task has been completed, so you would daisy chain them a bit differently.