diff --git a/src/reference/defining-flows.xml b/src/reference/defining-flows.xml
index 1e8bcb88..09978256 100644
--- a/src/reference/defining-flows.xml
+++ b/src/reference/defining-flows.xml
@@ -400,6 +400,56 @@ public interface FlowOutcome {
+
+ Variable Scopes
+
+ Web Flow can store variables in one of several scopes:
+
+
+ Flow Scope
+
+ Flow scope gets allocated when a flow starts and destroyed when the flow ends.
+ With the default implementation, any objects stored in flow scope need to be Serializable.
+
+
+
+ View Scope
+
+ View scope gets allocated when a view-state enters and destroyed when the state exits.
+ View scope is only referenceable from within a view-state. With the
+ default implementation, any objects stored in view scope need to be Serializable.
+
+
+
+ Request Scope
+
+ Request scope gets allocated when a flow is called and destroyed when the flow returns.
+
+
+
+ Flash Scope
+
+ Flash scope gets allocated when a flow starts, cleared after every view render, and destroyed when the
+ flow ends. With the default implementation, any objects stored in flash scope need to be Serializable.
+
+
+
+ Conversation Scope
+
+ Conversation scope gets allocated when a top-level flow starts and destroyed when the top-level flow ends.
+ Conversation scope is shared by a top-level flow and all of its subflows. With the default
+ implementation, conversation scoped objects are stored in the HTTP session and should generally be
+ Serializable to account for typical session replication.
+
+
+
+ The scope to use is often determined contextually, for example depending on where a
+ variable is defined -- at the start of the flow definition (flow scope), inside a
+ a view state (view scope), etc. In other cases, for example in EL expressions and
+ Java code, it needs to be specified explicitly. Subsequent sections explain
+ how this is done.
+
+
Calling subflows