diff --git a/authentik/flows/migrations/0018_oob_flows.py b/authentik/flows/migrations/0018_oob_flows.py
index 7d146bec1..875f85f5b 100644
--- a/authentik/flows/migrations/0018_oob_flows.py
+++ b/authentik/flows/migrations/0018_oob_flows.py
@@ -14,7 +14,7 @@ return not akadmin.has_usable_password()"""
 PREFILL_POLICY_EXPRESSION = """# This policy sets the user for the currently running flow
 # by injecting "pending_user"
 akadmin = ak_user_by(username="akadmin")
-context["pending_user"] = akadmin
+context["flow_plan"].context["pending_user"] = akadmin
 return True"""
 
 
diff --git a/website/docs/flow/stages/email/index.md b/website/docs/flow/stages/email/index.md
index d9ebc532b..51472df4a 100644
--- a/website/docs/flow/stages/email/index.md
+++ b/website/docs/flow/stages/email/index.md
@@ -13,11 +13,11 @@ By default, the email is sent to the currently pending user. To override this, y
 For example, create this expression policy and bind it to the email stage:
 
 ```python
-request.context["email"] = "foo@bar.baz"
+request.context["flow_plan"].context["email"] = "foo@bar.baz"
 # Or get it from a prompt
-# request.context["email"] = request.context["prompt_data"]["email"]
+# request.context["flow_plan"].context["email"] = request.context["prompt_data"]["email"]
 # Or another user attribute
-# request.context["email"] = request.context["pending_user"].attributes.get("otherEmail")
+# request.context["flow_plan"].context["email"] = request.context["pending_user"].attributes.get("otherEmail")
 return True
 ```
 
diff --git a/website/docs/flow/stages/user_write.md b/website/docs/flow/stages/user_write.md
index 7c9fb624c..fb9acf6ad 100644
--- a/website/docs/flow/stages/user_write.md
+++ b/website/docs/flow/stages/user_write.md
@@ -14,6 +14,6 @@ Starting with authentik 2022.5, users can be added to dynamic groups. To do so,
 from authentik.core.models import Group
 group, _ = Group.objects.get_or_create(name="some-group")
 # ["groups"] *must* be set to an array of Group objects, names alone are not enough.
-request.context["groups"] = [group]
+request.context["flow_plan"].context["groups"] = [group]
 return True
 ```
diff --git a/website/docs/releases/v2022.7.md b/website/docs/releases/v2022.7.md
index 7b9aa92e9..cbfbb5ca1 100644
--- a/website/docs/releases/v2022.7.md
+++ b/website/docs/releases/v2022.7.md
@@ -14,6 +14,10 @@ slug: "2022.7"
     In earlier versions, cyclic group relations can lead to a deadlock when one of groups in the relationship are bound to an application/flow/etc.
     This is now limited to 20 levels of recursion.
 
+-   Change in context behaviour for policies executed within flows
+
+    In previous versions, the policy context would be set to a reference to the currently active flow plan context. This makes it so any changes to `context` wre directly reflected in the flow context. The context has been changed to only include the values, and as such updates like this won't be reflected in the flow. Instead, `context['flow_plan']` is now set, which contains a full reference to the flow Plan, allowing for more customisability than previously. Context changes can be mad by modifying `context['flow_plan'].context`.
+
 ## New features
 
 -   User paths