diff --git a/Design:-Using-environment-variables.md b/Design:-Using-environment-variables.md
index bef3abd..b899947 100644
--- a/Design:-Using-environment-variables.md
+++ b/Design:-Using-environment-variables.md
@@ -9,6 +9,7 @@ The basic usability of the `$(ENV_VAR)` approach has issues. It can only be used
  - [Project Settings](#2-project-settings)
  - [Subflow Instance Properties](#3-subflow-instance-properties)
  - [Compound Env Vars](#4-compound-env-vars)
+ - [JSONata support for env vars](#5-jsonata-support-for-env-vars)
 
 ### 0. Update existing env var syntax
 
@@ -60,3 +61,11 @@ With the proposed TypedInput addition we can be more flexible. The question is h
 Both the Project Settings and Subflow Instance properties list would also support this format.
 
 This does mean compound env vars would only be possible using these new features - not in any arbitrary node property `<input>`. But a compound env var could be declared in Project Settings of Subflow Instance Properties which is then available as a simple `${NEW_ENV_VAR}` to use anywhere in the flow.
+
+5. JSONata support for env vars
+
+We'll add a new function to our JSONata setup to allow env vars to be retrieved:
+
+    $env('ENV_VAR')
+
+