diff --git a/SAS/TMSS/backend/src/tmss/workflowapp/flows/schedulingunitflow.py b/SAS/TMSS/backend/src/tmss/workflowapp/flows/schedulingunitflow.py
index f89a97496fe0c4662af6cdbc0c54cfdcdc2bda90..b1934afb23cc6fd30eda4c10243c5bbe2467a520 100644
--- a/SAS/TMSS/backend/src/tmss/workflowapp/flows/schedulingunitflow.py
+++ b/SAS/TMSS/backend/src/tmss/workflowapp/flows/schedulingunitflow.py
@@ -44,17 +44,6 @@ class Conditional(Signal):
     node is reached, but after a prior If node evaluated the corresponding TMSS property based on which it still expects
     a signal.
     Also see https://support.astron.nl/jira/browse/TMSS-1562
-    # todo: I'm not 100% sure about this one...
-    #   I get the race condition part, so I see why we cannot simply to an If node followed by a Signal node.
-    #   What I don't get is why we need to augment the two, since to me they follow very different concepts.
-    #   In BPMN, a Conditional seems to simply block on a condition check until the condition is met. This
-    #   should not be related in any way to Signals. So while I do see that this implementation of a conditionally
-    #   active Signal node works, I think it is A) probably not a correctly named entity ("IfElseSignal"?) and B)
-    #   I wonder if a polling solution is more straight-forward. I would expect a (probably polling) implementation of
-    #   a Conditional Node in Viewflow, but at least I don't see it. But I think I would find an If-Node that loops back
-    #   on itself as long as the condition is not met quite a bit clearer than this solution.
-    #   I can see it's nicer than polling, but somehow this mix of condition check via ORM and triggering signals on
-    #   messages on a property change in the same node is brushing me the wrong way.
     """
     task_type = "HUMAN" # makes it show up in the unassigned task lists
     activation_class = ConditionalActivation