diff --git a/build.gradle b/build.gradle
index 36674bcac0d..79be9f34de5 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1,5 +1,5 @@
 buildscript {
-	ext.kotlinVersion = '1.3.40'
+	ext.kotlinVersion = '1.3.50'
 	repositories {
 		maven { url 'https://repo.spring.io/plugins-release' }
 	}
diff --git a/src/reference/asciidoc/dsl.adoc b/src/reference/asciidoc/dsl.adoc
index a5dbd5b3001..0e6e16acdba 100644
--- a/src/reference/asciidoc/dsl.adoc
+++ b/src/reference/asciidoc/dsl.adoc
@@ -816,6 +816,24 @@ When you configure a sub-flow as a lambda, the framework handles the request-rep
 Sub-flows can be nested to any depth, but we do not recommend doing so.
 In fact, even in the router case, adding complex sub-flows within a flow would quickly begin to look like a plate of spaghetti and be difficult for a human to parse.
 
+[NOTE]
+====
+In cases where the DSL supports a subflow configuration, when a channel is normally needed for the component being configured, and that subflow starts with a `channel()` element, the framework implicitly places a `bridge()` between the flow's input channel and that channel.
+For example, in this `filter` definition:
+
+[source,java]
+----
+.filter(p -> p instanceof String, e -> e
+	.discardFlow(df -> df
+                         .channel(MessageChannels.queue())
+                         ...)
+----
+the Framework creates internally a `DirectChannel` bean for injecting into the `MessageFilter.discardChannel`.
+Then it wraps the subflow into an `IntegrationFlow` starting with this implicit channel for subscription and places a `bridge` before the mentioned `channel()` in the flow.
+When an existing `IntegrationFlow` bean is used as a subflow reference, there is no such bridge in between since the framework can resolve the first channel from the flow bean.
+This information is not available yet from inline subflows.
+====
+
 [[java-dsl-protocol-adapters]]
 === Using Protocol Adapters