diff --git a/modules/ROOT/pages/subqueries/subqueries-in-transactions.adoc b/modules/ROOT/pages/subqueries/subqueries-in-transactions.adoc
index d653f9ce5..2b5fb8650 100644
--- a/modules/ROOT/pages/subqueries/subqueries-in-transactions.adoc
+++ b/modules/ROOT/pages/subqueries/subqueries-in-transactions.adoc
@@ -554,9 +554,6 @@ If the transaction still fails after the maximum duration, the failure is handle
 It is particularly suitable for xref:subqueries/subqueries-in-transactions.adoc#concurrent-transactions[concurrent transactions], reducing the likelihood of a query failing due to xref:subqueries/subqueries-in-transactions.adoc#deadlocks[deadlocks].
 
 
-[NOTE]
-Queries using `ON ERROR RETRY` can currently only use the xref:planning-and-tuning/runtimes/concepts.adoc#runtimes-slotted-runtime[slotted runtime].
-
 .Basic retry with default duration
 =====
 
@@ -788,11 +785,13 @@ By default, `CALL { ... } IN TRANSACTIONS` is single-threaded; one CPU core is u
 However, `CALL` subqueries can also execute batches in parallel by appending `IN [n] CONCURRENT TRANSACTIONS`, where `n` is a concurrency value used to set the maximum number of transactions that can be executed in parallel.
 This allows `CALL` subqueries to utilize multiple CPU cores simultaneously, which can significantly reduce the time required to execute a large, outer transaction.
 
-[NOTE]
 The concurrency value is optional.
 If not specified, a default value based on the amount of available CPU cores will be chosen.
 If a negative number is specified (which can only be done through a parameter), the concurrency will be the number of available CPU cores reduced by the absolute value of that number.
 
+[NOTE]
+Queries using `CONCURRENT TRANSACTIONS` can currently only use the xref:planning-and-tuning/runtimes/concepts.adoc#runtimes-slotted-runtime[slotted runtime].
+
 .Load a CSV file in concurrent transactions
 ====