diff --git a/examples/README.md b/examples/README.md
index 0bf7f396..e5a9dafc 100644
--- a/examples/README.md
+++ b/examples/README.md
@@ -174,7 +174,7 @@ Which is added to the states data and becomes the workflow data output.
                 "name": "${ .person.name }"
               }
            },
-           "actionDataFilter": {
+           "dataFilter": {
               "results": "${ {greeting: .greeting} }"
            }
         }
@@ -206,7 +206,7 @@ states:
       refName: greetingFunction
       arguments:
         name: "${ .person.name }"
-    actionDataFilter:
+    dataFilter:
       results: "${ {greeting: .greeting} }"
   end: true
 ```
@@ -252,7 +252,7 @@ Note that in the workflow definition you can see two filters defined. The event
 
 ```json
 {
-  "eventDataFilter": {
+  "dataFilter": {
     "data": "${ .data.greet } "
   }
 }
@@ -265,7 +265,7 @@ The second, a state data filter, which is defined on the event state itself:
 
 ```json
 {
-  "stateDataFilter": {
+  "dataFilter": {
      "output": "${ .payload.greeting }"
   }
 }
@@ -320,7 +320,7 @@ filters what is selected to be the state data output which then becomes the work
      "type":"event",
      "onEvents": [{
          "eventRefs": ["GreetingEvent"],
-         "eventDataFilter": {
+         "dataFilter": {
             "data": "${ .greet }",
             "toStateData": "${ .greet }"
          },
@@ -335,7 +335,7 @@ filters what is selected to be the state data output which then becomes the work
             }
          ]
      }],
-     "stateDataFilter": {
+     "dataFilter": {
         "output": "${ .payload.greeting }"
      },
      "end": true
@@ -367,7 +367,7 @@ states:
   onEvents:
   - eventRefs:
     - GreetingEvent
-    eventDataFilter:
+    dataFilter:
       data: "${ .greet }"
       toStateData: "${ .greet }"
     actions:
@@ -375,7 +375,7 @@ states:
         refName: greetingFunction
         arguments:
           name: "${ .greet.name }"
-  stateDataFilter:
+  dataFilter:
     output: "${ .payload.greeting }"
   end: true
 ```
@@ -452,7 +452,7 @@ result of the workflow execution.
       }
    }
  ],
- "stateDataFilter": {
+ "dataFilter": {
     "output": "${ .results }"
  },
  "end": true
@@ -485,7 +485,7 @@ states:
       refName: solveMathExpressionFunction
       arguments:
         expression: "${ .singleexpression }"
-  stateDataFilter:
+  dataFilter:
     output: "${ .results }"
   end: true
 ```
@@ -1127,7 +1127,7 @@ The data output of the workflow contains the information of the exception caught
           }
        }
     ],
-    "stateDataFilter": {
+    "dataFilter": {
        "output": "${ .exceptions }"
     },
     "transition": "ApplyOrder",
@@ -1216,7 +1216,7 @@ states:
        refName: provisionOrderFunction
        arguments:
         order: "${ .order }"
-   stateDataFilter:
+   dataFilter:
     output: "${ .exceptions }"
    transition: ApplyOrder
    onErrors:
@@ -1322,12 +1322,12 @@ In the case job submission raises a runtime error, we transition to an Operation
               "name": "${ .job.name }"
             }
           },
-          "actionDataFilter": {
+          "dataFilter": {
             "results": "${ .jobuid }"
           }
       }
       ],
-      "stateDataFilter": {
+      "dataFilter": {
           "output": "${ .jobuid }"
       },
       "transition": "WaitForCompletion"
@@ -1350,12 +1350,12 @@ In the case job submission raises a runtime error, we transition to an Operation
               "name": "${ .jobuid }"
             }
           },
-          "actionDataFilter": {
+          "dataFilter": {
             "results": "${ .jobstatus }"
           }
       }
       ],
-      "stateDataFilter": {
+      "dataFilter": {
           "output": "${ .jobstatus }"
       },
       "transition": "DetermineCompletion"
@@ -1441,9 +1441,9 @@ states:
        refName: submitJob
        arguments:
         name: "${ .job.name }"
-      actionDataFilter:
+      dataFilter:
        results: "${ .jobuid }"
-   stateDataFilter:
+   dataFilter:
     output: "${ .jobuid }"
    transition: WaitForCompletion
  - name: WaitForCompletion
@@ -1458,9 +1458,9 @@ states:
        refName: checkJobStatus
        arguments:
         name: "${ .jobuid }"
-      actionDataFilter:
+      dataFilter:
        results: "${ .jobstatus }"
-   stateDataFilter:
+   dataFilter:
     output: "${ .jobstatus }"
    transition: DetermineCompletion
  - name: DetermineCompletion
@@ -2625,7 +2625,7 @@ For this example we assume that the workflow instance is started given the follo
                        "data": "${ .patientInfo }",
                        "consumeEventRef":  "VetAppointmentInfo"
                     },
-                    "actionDataFilter": {
+                    "dataFilter": {
                         "results": "${ .appointmentInfo }"
                     }
                 }
@@ -2667,7 +2667,7 @@ states:
        produceEventRef: MakeVetAppointment
        data: "${ .patientInfo }"
        consumeEventRef: VetAppointmentInfo
-      actionDataFilter:
+      dataFilter:
        results: "${ .appointmentInfo }"
    timeouts:
     actionExecTimeout: PT15M
@@ -3431,7 +3431,7 @@ the data for an hour, send report, and so on.
               }
             }
           ],
-          "eventDataFilter": {
+          "dataFilter": {
             "toStateData": "${ .readings }"
           }
         }
@@ -3515,7 +3515,7 @@ states:
     actions:
     - functionRef:
         refName: LogReading
-    eventDataFilter:
+    dataFilter:
       toStateData: "${ .readings }"
   end: true
 - name: GenerateReport
@@ -4164,7 +4164,7 @@ Its results are then merged back into the state data according to the "toStateDa
    "actions": [
     {
      "functionRef": "Increment Current Count Function",
-     "actionDataFilter": {
+     "dataFilter": {
       "toStateData": ".counts.current"
      }
     }
@@ -4204,7 +4204,7 @@ states:
    type: operation
    actions:
     - functionRef: Increment Current Count Function
-      actionDataFilter:
+      dataFilter:
        toStateData: ".counts.current"
    transition: Check if full
 ```
@@ -4344,7 +4344,7 @@ states:
   onEvents:
   - eventRefs:
     - ETA Deadline Event
-    eventDataFilter:
+    dataFilter:
       data: "${ .results.status }"
       toStateData: "${ .status }"
   transition: Deliver Order
@@ -4360,10 +4360,10 @@ states:
       refName: Charge For Order Function
       arguments:
         order: "${ .order.id }"
-    actionDataFilter:
+    dataFilter:
       results: "${ .outcome.status }"
       toStateData: "${ .status }"
-  stateDataFilter:
+  dataFilter:
     output: '${ . | {"orderid": .id, "orderstatus": .status} | .orderstatus += ["Order
       Completed"] }'
   end: true
@@ -4390,7 +4390,7 @@ states:
         refName: Submit Order Function
         arguments:
           order: "${ .order }"
-      actionDataFilter:
+      dataFilter:
         results: "${ .results.status }"
         toStateData: "${ .status }"
     - functionRef:
@@ -4399,7 +4399,7 @@ states:
           customer: "${ .customerId }"
           restaurantid: "${ .order.restaurantId }"
           delivery: " ${ .delivery }"
-      actionDataFilter:
+      dataFilter:
         results: "${ .results.status }"
         toStateData: "${ .status }"
   end: true
@@ -4424,7 +4424,7 @@ states:
   onEvents:
   - eventRefs:
     - Order Picked Up Event
-    eventDataFilter:
+    dataFilter:
       data: "${ .data.status }"
       toStateData: "${ .status }"
     actions:
@@ -4435,7 +4435,7 @@ states:
   onEvents:
   - eventRefs:
     - Order Delievered Event
-    eventDataFilter:
+    dataFilter:
       data: "${ .data.status }"
       toStateData: "${ .status }"
   end: true
@@ -4511,7 +4511,7 @@ We assume that our workflow input has the runtime-imposed quota:
      "eventRefs":[
       "CustomerEvent"
      ],
-     "eventDataFilter":{
+     "dataFilter":{
       "data":"${ .customerId }",
       "toStateData":"${ .eventCustomerId }"
      },
@@ -4527,7 +4527,7 @@ We assume that our workflow input has the runtime-imposed quota:
      ]
     }
    ],
-   "stateDataFilter":{
+   "dataFilter":{
     "output":"${ .count = .count + 1 }"
    },
    "transition":"CheckEventQuota"
@@ -4583,7 +4583,7 @@ states:
    onEvents:
     - eventRefs:
        - CustomerEvent
-      eventDataFilter:
+      dataFilter:
        data: "${ .customerId }"
        toStateData: "${ .eventCustomerId }"
       actions:
@@ -4591,7 +4591,7 @@ states:
           refName: NotifyCustomerFunction
           arguments:
            customerId: "${ .eventCustomerId }"
-   stateDataFilter:
+   dataFilter:
     output: "${ .count = .count + 1 }"
    transition: CheckEventQuota
  - name: CheckEventQuota
diff --git a/roadmap/README.md b/roadmap/README.md
index 902262c3..9f84dba9 100644
--- a/roadmap/README.md
+++ b/roadmap/README.md
@@ -36,6 +36,7 @@ _Status description:_
 | ✔️| Update the `dataInputSchema` top-level property by supporting the assignment of a JSON schema object [workflow schema](https://github.com/serverlessworkflow/specification/tree/main/specification.md#workflow-definition-structure)  |
 | ✔️| Add the new `WORKFLOW` reserved keyword to workflow expressions  |
 | ✔️| Update `ForEach` state iteration parameter example. This parameter is an expression variable, not a JSON property  |
+| ✔️| Renamed data filter properties (`stateDataFilter`, `actionDataFilter`, ...) into `dataFilter` both to avoid redundancy and improve definition readability
 | ✏️️| Add inline state defs in branches |   |
 | ✏️️| Update rest function definition |   |
 | ✏️️| Add "completedBy" functionality |   |
diff --git a/schema/workflow.json b/schema/workflow.json
index dae1bd54..12914e99 100644
--- a/schema/workflow.json
+++ b/schema/workflow.json
@@ -419,7 +419,7 @@
           },
           "additionalItems": false
         },
-        "eventDataFilter": {
+        "dataFilter": {
           "description": "Event data filter",
           "$ref": "#/definitions/eventdatafilter"
         }
@@ -474,7 +474,7 @@
           },
           "additionalItems": false
         },
-        "actionDataFilter": {
+        "dataFilter": {
           "description": "Action data filter",
           "$ref": "#/definitions/actiondatafilter"
         },
@@ -754,7 +754,7 @@
           },
           "required": []
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
@@ -821,7 +821,7 @@
           "$ref": "#/definitions/end",
           "description": "State end definition"
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
@@ -938,7 +938,7 @@
           "$ref": "#/definitions/end",
           "description": "State end definition"
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
@@ -1071,7 +1071,7 @@
           "const": "switch",
           "description": "State type"
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
@@ -1145,7 +1145,7 @@
           "const": "switch",
           "description": "State type"
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
@@ -1258,7 +1258,7 @@
           "description": "Next transition of the workflow if there is valid matches",
           "$ref": "#/definitions/transition"
         },
-        "eventDataFilter": {
+        "dataFilter": {
           "description": "Event data filter definition",
           "$ref": "#/definitions/eventdatafilter"
         },
@@ -1288,7 +1288,7 @@
           "$ref": "#/definitions/end",
           "description": "Explicit transition to end"
         },
-        "eventDataFilter": {
+        "dataFilter": {
           "description": "Event data filter definition",
           "$ref": "#/definitions/eventdatafilter"
         },
@@ -1385,7 +1385,7 @@
           "type": "object",
           "description": "JSON object which can be set as states data input and can be manipulated via filters"
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
@@ -1506,7 +1506,7 @@
           },
           "required": []
         },
-        "stateDataFilter": {
+        "dataFilter": {
           "description": "State data filter",
           "$ref": "#/definitions/statedatafilter"
         },
diff --git a/specification.md b/specification.md
index 9364266a..307ac186 100644
--- a/specification.md
+++ b/specification.md
@@ -319,7 +319,7 @@ The workflow data output is the data output of the last executed workflow state.
 
 ```json
 {
-    "stateDataFilter": {
+    "dataFilter": {
       "input": "${ .orders }",
       "output": "${ .provisionedOrders }"
     }
@@ -330,7 +330,7 @@ The workflow data output is the data output of the last executed workflow state.
 <td valign="top">
 
 ```yaml
-stateDataFilter:
+dataFilter:
   input: "${ .orders }"
   output: "${ .provisionedOrders }"
 ```
@@ -380,7 +380,7 @@ we can define a state filter:
 
 ```json
 {
-  "stateDataFilter": {
+  "dataFilter": {
     "input": "${ {fruits: .fruits} }"
   }
 }
@@ -406,7 +406,7 @@ The first way would be to use both "input", and "output":
 
 ```json
 {
-  "stateDataFilter": {
+  "dataFilter": {
     "input": "${ {vegetables: .vegetables} }",
     "output": "${ {vegetables: [.vegetables[] | select(.veggieLike == true)]} }"
   }
@@ -424,7 +424,7 @@ The second way would be to directly filter only the "veggie like" vegetables wit
 
 ```json
 {
-  "stateDataFilter": {
+  "dataFilter": {
     "input": "${ {vegetables: [.vegetables[] | select(.veggieLike == true)]} }"
   }
 }
@@ -452,7 +452,7 @@ The second way would be to directly filter only the "veggie like" vegetables wit
 
 ```json
 {
-  "actionDataFilter": {
+  "dataFilter": {
     "fromStateData": "${ .language }",
     "results": "${ .results.greeting }",
     "toStateData": "${ .finalgreeting }"
@@ -464,7 +464,7 @@ The second way would be to directly filter only the "veggie like" vegetables wit
 <td valign="top">
 
 ```yaml
-actionDataFilter:
+dataFilter:
   fromStateData: "${ .language }"
   results: "${ .results.greeting }"
   toStateData: "${ .finalgreeting }"
@@ -504,7 +504,7 @@ We can use an action data filter to filter only the breads data:
 "actions":[
     {
        "functionRef": "breadAndPastaTypesFunction",
-       "actionDataFilter": {
+       "dataFilter": {
           "results": "${ {breads: .breads} }"
        }
     }
@@ -540,7 +540,7 @@ and have the following action definition:
 "actions":[
     {
        "functionRef": "breadAndPastaTypesFunction",
-       "actionDataFilter": {
+       "dataFilter": {
           "results": "${ [ .breads[0], .pasta[1] ] }",
           "toStateData": "${ .itemsToBuyAtStore }"
        }
@@ -587,7 +587,7 @@ If `useResults` is not specified (or it's value set to `true`), action results,
 
 ```json
 {
-    "eventDataFilter": {
+    "dataFilter": {
        "data": "${ .data.results }"
     }
 }
@@ -597,7 +597,7 @@ If `useResults` is not specified (or it's value set to `true`), action results,
 <td valign="top">
 
 ```yaml
-eventDataFilter:
+dataFilter:
   data: "${ .data.results }"
 ```
 
@@ -651,7 +651,7 @@ a workflow with a single event state and show how data filters can be combined.
             "type": "event",
             "onEvents": [{
                 "eventRefs": ["CustomerArrivesEvent"],
-                "eventDataFilter": {
+                "dataFilter": {
                     "data": "${ .customer }",
                     "toStateData": "${ .customerInfo }"
                 },
@@ -664,7 +664,7 @@ a workflow with a single event state and show how data filters can be combined.
                                 "customerName": "${ .customerInfo.name } "
                             }
                         },
-                        "actionDataFilter": {
+                        "dataFilter": {
                             "fromStateData": "${ { hello, customerInfo } }",
                             "results": "${ .greetingMessageResult }",
                             "toStateData": "${ .finalCustomerGreeting }"
@@ -672,7 +672,7 @@ a workflow with a single event state and show how data filters can be combined.
                     }
                 ]
             }],
-            "stateDataFilter": {
+            "dataFilter": {
                 "input": "${ .greetings } ",
                 "output": "${ { finalCustomerGreeting } }"
             },
@@ -736,7 +736,7 @@ workflow execution at which data filters are invoked and correspond to the numbe
 **(1) Workflow execution starts**: Workflow data is passed to our "WaitForCustomerToArrive" event state as data input.
 Workflow executes its starting state, namely the "WaitForCustomerToArrive" event state.
 
-The event state **stateDataFilter** is invoked to filter its data input. The filters "input" expression is evaluated and
+The event state **dataFilter** is invoked to filter its data input. The filters "input" expression is evaluated and
 selects only the "greetings" data. The rest of the state data input should be disregarded.
 
 At this point our state data should be:
@@ -758,7 +758,7 @@ At this point our state data should be:
 }
 ```
 
-**(2) CloudEvent of type "customer-arrival-type" is consumed**: Once the event is consumed, the "eventDataFilter" is triggered.
+**(2) CloudEvent of type "customer-arrival-type" is consumed**: Once the event is consumed, the "dataFilter" is triggered.
 Its "data" expression selects the "customer" object from the events data. The "toStateData" expression
 says that we should add/merge this selected event data to the state data in its "customerInfo" property. If this property
 exists it should be merged, if it does not exist, one should be created.
@@ -788,7 +788,7 @@ At this point our state data contains:
 ```
 
 **(3) Event state performs its actions**:
-Before the first action is executed, its actionDataFilter is invoked. Its "fromStateData" expression filters
+Before the first action is executed, its dataFilter is invoked. Its "fromStateData" expression filters
 the current state data to select from its data that should be available to action arguments. In this example
 it selects the "hello" and "customerInfo" properties from the current state data.
 At this point the action is executed.
@@ -804,7 +804,7 @@ We assume that for this example "greetingFunction" returns:
 }
 ```
 
-After the action is executed, the actionDataFilter "results" expression is evaluated to filter the results returned from the action execution. In this case, we select only the "greetingMessageResult" element from the results.
+After the action is executed, the dataFilter "results" expression is evaluated to filter the results returned from the action execution. In this case, we select only the "greetingMessageResult" element from the results.
 
 The action filters "toStateData" expression then defines that we want to add/merge this action result to
 state data under the "finalCustomerGreeting" element.
@@ -836,7 +836,7 @@ At this point, our state data contains:
 
 **(4) Event State Completes  Execution**:
 
-When our event state finishes its execution, the states "stateDataFilter" "output" filter expression is executed
+When our event state finishes its execution, the states "dataFilter" "output" filter expression is executed
 to filter the state data to create the final state data output.
 
 Because our event state is also an end state, its data output becomes the final [workflow data output](#Workflow-data-output). Namely:
@@ -1689,7 +1689,7 @@ For example let's use another inline expression:
 
 ```json
 {
-   "stateDataFilter": {
+   "dataFilter": {
        "output": "${ .applicant | {applicant: .name, contactInfo: { email: .email, phone: .phoneNumbers }} }"
    }
 }
@@ -2133,7 +2133,7 @@ Serverless Workflow defines the following Workflow States:
 | exclusive | If `true`, consuming one of the defined events causes its associated actions to be performed. If `false`, all of the defined events must be consumed in order for actions to be performed. Default is `true`  | boolean | no |
 | [onEvents](#OnEvents-Definition) | Define the events to be consumed and optional actions to be performed | array | yes |
 | [timeouts](#Workflow-Timeouts) | State specific timeout settings | object | no |
-| [stateDataFilter](#State-data-filters) | State data filter definition| object | no |
+| [dataFilter](#State-data-filters) | State data filter definition| object | no |
 | [transition](#Transitions) | Next transition of the workflow after all the actions have been performed | string or object | yes (if `end` is not defined) |
 | [onErrors](#Error-Definition) | States error handling definitions | array | no |
 | [end](#End-Definition) | Is this state an end state | boolean or object | yes (if `transition` is not defined) |
@@ -2281,7 +2281,7 @@ Note that `transition` and `end` properties are mutually exclusive, meaning that
 | actionMode | Should actions be performed sequentially or in parallel. Default is `sequential`  | enum | no |
 | [actions](#Action-Definition) | Actions to be performed | array | yes |
 | [timeouts](#Workflow-Timeouts) | State specific timeout settings | object | no |
-| [stateDataFilter](#State-data-filters) | State data filter | object | no |
+| [dataFilter](#State-data-filters) | State data filter | object | no |
 | [onErrors](#Error-Definition) | States error handling and retries definitions | array | no |
 | [transition](#Transitions) | Next transition of the workflow after all the actions have been performed | string or object | yes (if `end` is not defined) |
 | [compensatedBy](#Workflow-Compensation) | Unique name of a workflow state which is responsible for compensation of this state | string | no |
@@ -2355,7 +2355,7 @@ the [Workflow Timeouts](#Workflow-Timeouts) section.
 | type | State type | string | yes |
 | [dataConditions](#Switch-state-Data-Conditions) | Defined if the Switch state evaluates conditions and transitions based on state data. | array | yes (if `eventConditions` is not defined) |
 | [eventConditions](#Switch-State-Event-Conditions) | Defined if the Switch state evaluates conditions and transitions based on arrival of events. | array | yes (if `dataConditions` is not defined |
-| [stateDataFilter](#State-data-filters) | State data filter | object | no |
+| [dataFilter](#State-data-filters) | State data filter | object | no |
 | [onErrors](#Error-Definition) | States error handling and retries definitions | array | no |
 | [timeouts](#Workflow-Timeouts) | State specific timeout settings | object | no |
 | defaultCondition | Default transition of the workflow if there is no matching data conditions or event timeout is reached. Can be a transition or end definition | object | yes |
@@ -2507,7 +2507,7 @@ Note that `transition` and `end` properties are mutually exclusive, meaning that
 | completionType | Option types on how to complete branch execution. Default is "allOf" | enum | no |
 | numCompleted | Used when branchCompletionType is set to `atLeast` to specify the least number of branches that must complete in order for the state to transition/end. | string or number | yes (if `completionType` is `atLeast`) |
 | [timeouts](#Workflow-Timeouts) | State specific timeout settings | object | no |
-| [stateDataFilter](#State-data-filters) | State data filter | object | no |
+| [dataFilter](#State-data-filters) | State data filter | object | no |
 | [onErrors](#Error-Definition) | States error handling and retries definitions | array | no |
 | [transition](#Transitions) | Next transition of the workflow after all branches have completed execution | string or object | yes (if `end` is not defined) |
 | [compensatedBy](#Workflow-Compensation) | Unique name of a workflow state which is responsible for compensation of this state | string | no |
@@ -2618,7 +2618,7 @@ Note that `transition` and `end` properties are mutually exclusive, meaning that
 | name | Unique State name | string | yes |
 | type | State type | string | yes |
 | data | JSON object which can be set as state's data input and can be manipulated via filter | object | yes |
-| [stateDataFilter](#state-data-filters) | State data filter | object | no |
+| [dataFilter](#state-data-filters) | State data filter | object | no |
 | [transition](#Transitions) | Next transition of the workflow after injection has completed | string or object | yes (if `end` is not defined) |
 | [compensatedBy](#Workflow-Compensation) | Unique name of a workflow state which is responsible for compensation of this state | string | no |
 | [usedForCompensation](#Workflow-Compensation) | If `true`, this state is used to compensate another state. Default is `false` | boolean | no |
@@ -2770,7 +2770,7 @@ You can also use the filter property to filter the state data after data is inje
           }
         ]
      },
-     "stateDataFilter": {
+     "dataFilter": {
         "output": "${ {people: [.people[] | select(.age < 40)]} }"
      },
      "transition": "GreetPersonState"
@@ -2797,7 +2797,7 @@ You can also use the filter property to filter the state data after data is inje
       lname: Mill
       address: 1234 SomeStreet
       age: 30
-  stateDataFilter:
+  dataFilter:
     output: "${ {people: [.people[] | select(.age < 40)]} }"
   transition: GreetPersonState
 ```
@@ -2850,7 +2850,7 @@ Note that `transition` and `end` properties are mutually exclusive, meaning that
 | mode | Specifies how iterations are to be performed (sequentially or in parallel). Default is `parallel` | enum  | no |
 | [actions](#Action-Definition) | Actions to be executed for each of the elements of inputCollection | array | yes |
 | [timeouts](#Workflow-Timeouts) | State specific timeout settings | object | no |
-| [stateDataFilter](#State-data-filters) | State data filter definition | object | no |
+| [dataFilter](#State-data-filters) | State data filter definition | object | no |
 | [onErrors](#Error-Definition) | States error handling and retries definitions | array | no |
 | [transition](#Transitions) | Next transition of the workflow after state has completed | string or object | yes (if `end` is not defined) |
 | [compensatedBy](#Workflow-Compensation) | Unique name of a workflow state which is responsible for compensation of this state | string | no |
@@ -3169,7 +3169,7 @@ referenced [Event Definition](#Event-Definition).
 Once the completion (callback) event is received, the Callback state completes its execution and transitions to the next
 defined workflow state or completes workflow execution in case it is an end state.
 
-The callback event payload is merged with the Callback state data and can be filtered via the "eventDataFilter" definition.
+The callback event payload is merged with the Callback state data and can be filtered via the "dataFilter" definition.
 
 If the defined callback event has not been received during this time period, the state should transition to the next state or end workflow execution if it is an end state.
 
@@ -3645,7 +3645,7 @@ The `contextAttributeValue` property defines the value of the defined CloudEvent
 | eventRefs | References one or more unique event names in the defined workflow [events](#Event-Definition) | array | yes |
 | actionMode | Specifies how actions are to be performed (in sequence or in parallel). Default is `sequential` | enum | no |
 | [actions](#Action-Definition) | Actions to be performed | array | no |
-| [eventDataFilter](#Event-data-filters) | Event data filter definition | object | no |
+| [dataFilter](#Event-data-filters) | Event data filter definition | object | no |
 
 <details><summary><strong>Click to view example definition</strong></summary>
 <p>
@@ -3751,7 +3751,7 @@ This is visualized in the diagram below:
 | [retryRef](#retry-definition) | References a defined workflow retry definition. If not defined uses the default runtime retry definition | string | no |
 | nonRetryableErrors | List of references to defined [workflow errors](#Defining-Errors) for which the action should not be retried. Used only when `autoRetries` is set to `true` | array | no |
 | retryableErrors | List of references to defined [workflow errors](#Defining-Errors) for which the action should be retried. Used only when `autoRetries` is set to `false` | array | no |
-| [actionDataFilter](#Action-data-filters) | Action data filter definition | object | no |
+| [dataFilter](#Action-data-filters) | Action data filter definition | object | no |
 | sleep | Defines time periods workflow execution should sleep before / after function execution | object | no |
 | [condition](#Workflow-Expressions) | Expression, if defined, must evaluate to `true` for this action to be performed. If `false`, action is disregarded | string | no |
 
@@ -3931,7 +3931,7 @@ Here is an example of using the `arguments` property:
 The `invoke` property defines how the function is invoked (sync or async). Default value of this property is
 `sync`, meaning that workflow execution should wait until the function completes. 
 If set to `async`, workflow execution should just invoke the function and should not wait until its completion.
-Note that in this case the action does not produce any results and the associated actions actionDataFilter as well as 
+Note that in this case the action does not produce any results and the associated actions dataFilter as well as 
 its retry definition, if defined, should be ignored.
 In addition, functions that are invoked async do not propagate their errors to the associated action definition and the 
 workflow state, meaning that any errors that happen during their execution cannot be handled in the workflow states 
@@ -4002,7 +4002,7 @@ that can be handled in the states `onErrors` definition. In case the `consumeEve
 The `invoke` property defines how the function is invoked (sync or async). Default value of this property is
 `sync`, meaning that workflow execution should wait until the function completes (the result event is received).
 If set to `async`, workflow execution should just produce the trigger event and should not wait for the result event.
-Note that in this case the action does not produce any results (payload of the result event) and the associated actions eventDataFilter as well as
+Note that in this case the action does not produce any results (payload of the result event) and the associated actions dataFilter as well as
 its retry definition, if defined, should be ignored.
 Functions that are invoked via events (sync or async) do not propagate their errors to the associated action definition and the
 workflow state, meaning that any errors that happen during their execution cannot be handled in the workflow states
@@ -4072,7 +4072,7 @@ defined in the sub-workflow definition.
 The `invoke` property defines how the subflow is invoked (sync or async). Default value of this property is
 `sync`, meaning that workflow execution should wait until the subflow completes.
 If set to `async`, workflow execution should just invoke the subflow and not wait for its results.
-Note that in this case the action does not produce any results, and the associated actions actionDataFilter as well as
+Note that in this case the action does not produce any results, and the associated actions dataFilter as well as
 its retry definition, if defined, should be ignored.
 Subflows that are invoked async do not propagate their errors to the associated action definition and the
 workflow state, meaning that any errors that happen during their execution cannot be handled in the workflow states
@@ -4404,7 +4404,7 @@ definitions are mutually exclusive, meaning that you can specify either one or t
 | eventRef | References an unique event name in the defined workflow events | string | yes |
 | [transition](#Transitions) | Transition to another state if condition is `true` | string or object | yes (if `end` is not defined) |
 | [end](#End-Definition) | End workflow execution if condition is `true` | boolean or object | yes (if `transition` is not defined) |
-| [eventDataFilter](#Event-data-filters) | Event data filter definition | object | no |
+| [dataFilter](#Event-data-filters) | Event data filter definition | object | no |
 | [metadata](#Workflow-Metadata) | Metadata information| object | no |
 
 <details><summary><strong>Click to view example definition</strong></summary>
@@ -4448,7 +4448,7 @@ The `eventRef` property references a name of one of the defined workflow events.
 If the referenced event is received, you can specify either the `transition` or `end` definitions
 to decide what to do, transition to another workflow state, or end workflow execution.
 
-The `eventDataFilter` property can be used to filter event data when it is received.
+The `dataFilter` property can be used to filter event data when it is received.
 
 Note that `transition` and `end`
 definitions are mutually exclusive, meaning that you can specify either one or the other, but not both.