Reword

Author: javiereguiluz

workflow.rst

@@ -368,7 +368,6 @@ order:
     * ``workflow.[workflow name].completed``
     * ``workflow.[workflow name].completed.[transition name]``
 
-
 ``workflow.announce``
     Triggered for each transition that now is accessible for the subject.
 
@@ -378,7 +377,12 @@ order:
     * ``workflow.[workflow name].announce``
     * ``workflow.[workflow name].announce.[transition name]``
 
-    You can avoid triggering those events by using the context::
+    After a transition is applied, the announce event tests for all available
+    transitions. That will trigger all :ref:`guard events <workflow-usage-guard-events>`
+    once more, which could impact performance if they include intensive CPU or
+    database workloads.
+
+    If you don't need the announce event, disable it using the context::
 
         $workflow->apply($subject, $transitionName, [Workflow::DISABLE_ANNOUNCE_EVENT => true]);
 
@@ -509,14 +513,6 @@ missing a title::
 
     The optional second argument of ``setBlocked()`` was introduced in Symfony 5.1.
 
-.. note::
-
-    When using guard listeners which imply intensive workloads (CPU, Database
-    or longer-running code blocks), if you only want them to be fired when strictly
-    necessary (only when ``Workflow::can()`` or ``Workflow::apply()`` is executed),
-    be sure to disable ``Workflow::DISABLE_ANNOUNCE_EVENT`` as indicated in
-    :ref:`Choosing which Events to Dispatch <workflow-chosing-events-to-dispatch>`
-
 .. _workflow-chosing-events-to-dispatch:
 
 Choosing which Events to Dispatch