Merge pull request mendix#6142 from Robinfr/microflow-validation-best-practices

Microflow validation best practices

Author: Yiyun333

content/en/docs/howto7/general/dev-best-practices.md

@@ -310,6 +310,32 @@ Use microflow [error handling](/howto7/logic-business-rules/set-up-error-handlin
 
 Complex processes and important business logic (like workflow processing or validations) must include debug and trace [logging](/refguide7/logging/). Logging actions must write the current state and progress of the process and must include a request ID or other identifying information. The log node should be the name of the module. This will greatly assist error analysis.
 
+#### 4.2.6 Validating Inputs in Microflows
+
+When microflows are invoked from the client side, it is important to validate the inputs. By having validations, you prevent incorrect, inappropriate, or potentially harmful data from being used in your microflows. This protects your application against security vulnerabilities. The following presents the best practices regarding the integrity and validation of inputs in your microflows.
+
+##### 4.2.6.1 Implementing Validation Checks
+
+Adding validation checks is vital for ensuring that input data conforms to the expected data type, format, range, or other application-specific constraints. For instance, if a numeric input is expected within a defined range, validation checks should confirm that the input is indeed numeric and falls within the specified range.
+
+##### 4.2.6.2 Managing Unexpected Values
+
+When building microflows, it is important to account for the potential occurrence of unexpected values. These could be empty values, or values outside the expected range or format. It is also important to ensure that read-only attributes only contain expected values.
+
+{{% alert color="warning" %}}
+We strongly recommend adding validation checks to all microflows inputs, including read-only attributes. 
+
+We also recommend avoiding storing intermediary values in attributes (such as, *TotalPrice*). Instead, calculate these values when needed to ensure you have the correct values.
+{{% /alert %}}
+
+Microflows should incorporate mechanisms to detect unexpected values and respond suitably – this might involve returning an error message to the end-user or executing a fallback operation. 
+
+##### 4.2.6.3 Updating Validation Logic Regularly
+
+As the application evolves, the validation logic within microflows should be updated accordingly to reflect changes in business logic or data models. This regular review and update of validation checks ensures that microflows remain secure and function correctly over time.
+
+By prioritizing the validation of inputs in microflows, you not only enhance the security of your application, but also ensure a more predictable and stable user experience. This practice underscores the development of reliable and robust applications.
+
 ### 4.3 Warnings and Modeler Feedback
 
 No warnings should be visible in the Modeler, unless explicitly documented with a reason. Warnings can indicate many issues, including maintainability and security risks, which must be resolved.

content/en/docs/howto8/general/dev-best-practices.md

@@ -329,6 +329,32 @@ Use microflow [error handling](/howto8/logic-business-rules/set-up-error-handlin
 
 Complex processes and important business logic (like workflow processing or validations) must include debug and trace [logging](/refguide8/logging/). Logging actions must write the current state and progress of the process and must include a request ID or other identifying information. The log node should be the name of the module. This will greatly assist error analysis.
 
+#### 4.2.6 Validating Inputs in Microflows
+
+When microflows are invoked from the client side, it is important to validate the inputs. By having validations, you prevent incorrect, inappropriate, or potentially harmful data from being used in your microflows. This protects your application against security vulnerabilities. The following presents the best practices regarding the integrity and validation of inputs in your microflows.
+
+##### 4.2.6.1 Implementing Validation Checks
+
+Adding validation checks is vital for ensuring that input data conforms to the expected data type, format, range, or other application-specific constraints. For instance, if a numeric input is expected within a defined range, validation checks should confirm that the input is indeed numeric and falls within the specified range.
+
+##### 4.2.6.2 Managing Unexpected Values
+
+When building microflows, it is important to account for the potential occurrence of unexpected values. These could be empty values, or values outside the expected range or format. It is also important to ensure that read-only attributes only contain expected values.
+
+{{% alert color="warning" %}}
+We strongly recommend adding validation checks to all microflows inputs, including read-only attributes. 
+
+We also recommend avoiding storing intermediary values in attributes (such as, *TotalPrice*). Instead, calculate these values when needed to ensure you have the correct values.
+{{% /alert %}}
+
+Microflows should incorporate mechanisms to detect unexpected values and respond suitably – this might involve returning an error message to the end-user or executing a fallback operation. 
+
+##### 4.2.6.3 Updating Validation Logic Regularly
+
+As the application evolves, the validation logic within microflows should be updated accordingly to reflect changes in business logic or data models. This regular review and update of validation checks ensures that microflows remain secure and function correctly over time.
+
+By prioritizing the validation of inputs in microflows, you not only enhance the security of your application, but also ensure a more predictable and stable user experience. This practice underscores the development of reliable and robust applications.
+
 ### 4.3 Warnings and Studio Pro Feedback
 
 No warnings should be visible in Studio Pro, unless explicitly documented with a reason. Warnings can indicate many issues, including maintainability and security risks, which must be resolved.

content/en/docs/refguide/modeling/dev-best-practices.md

@@ -360,6 +360,32 @@ Use microflow [error handling](/refguide/error-handling-in-microflows/) for all
 
 Complex processes and important business logic (like workflow processing or validations) must include debug and trace [logging](/refguide/logging/). Logging actions must write the current state and progress of the process and must include a request ID or other identifying information. The log node should be the name of the module. This will greatly assist error analysis.
 
+#### 4.2.6 Validating Inputs in Microflows
+
+When microflows are invoked from the client side, it is important to validate the inputs. By having validations, you prevent incorrect, inappropriate, or potentially harmful data from being used in your microflows. This protects your application against security vulnerabilities. The following presents the best practices regarding the integrity and validation of inputs in your microflows.
+
+##### 4.2.6.1 Implementing Validation Checks
+
+Adding validation checks is vital for ensuring that input data conforms to the expected data type, format, range, or other application-specific constraints. For instance, if a numeric input is expected within a defined range, validation checks should confirm that the input is indeed numeric and falls within the specified range.
+
+##### 4.2.6.2 Managing Unexpected Values
+
+When building microflows, it is important to account for the potential occurrence of unexpected values. These could be empty values, or values outside the expected range or format. It is also important to ensure that read-only attributes only contain expected values.
+
+{{% alert color="warning" %}}
+We strongly recommend adding validation checks to all microflows inputs, including read-only attributes. 
+
+We also recommend avoiding storing intermediary values in attributes (such as, *TotalPrice*). Instead, calculate these values when needed to ensure you have the correct values.
+{{% /alert %}}
+
+Microflows should incorporate mechanisms to detect unexpected values and respond suitably – this might involve returning an error message to the end-user or executing a fallback operation. 
+
+##### 4.2.6.3 Updating Validation Logic Regularly
+
+As the application evolves, the validation logic within microflows should be updated accordingly to reflect changes in business logic or data models. This regular review and update of validation checks ensures that microflows remain secure and function correctly over time.
+
+By prioritizing the validation of inputs in microflows, you not only enhance the security of your application, but also ensure a more predictable and stable user experience. This practice underscores the development of reliable and robust applications.
+
 ### 4.3 Workflows
 
 Guidelines below can help you choose a short yet meaningful name for your workflow:

content/en/docs/refguide9/modeling/dev-best-practices.md

@@ -360,6 +360,32 @@ Use microflow [error handling](/refguide9/error-handling-in-microflows/) for all
 
 Complex processes and important business logic (like workflow processing or validations) must include debug and trace [logging](/refguide9/logging/). Logging actions must write the current state and progress of the process and must include a request ID or other identifying information. The log node should be the name of the module. This will greatly assist error analysis.
 
+#### 4.2.6 Validating Inputs in Microflows
+
+When microflows are invoked from the client side, it is important to validate the inputs. By having validations, you prevent incorrect, inappropriate, or potentially harmful data from being used in your microflows. This protects your application against security vulnerabilities. The following presents the best practices regarding the integrity and validation of inputs in your microflows.
+
+##### 4.2.6.1 Implementing Validation Checks
+
+Adding validation checks is vital for ensuring that input data conforms to the expected data type, format, range, or other application-specific constraints. For instance, if a numeric input is expected within a defined range, validation checks should confirm that the input is indeed numeric and falls within the specified range.
+
+##### 4.2.6.2 Managing Unexpected Values
+
+When building microflows, it is important to account for the potential occurrence of unexpected values. These could be empty values, or values outside the expected range or format. It is also important to ensure that read-only attributes only contain expected values.
+
+{{% alert color="warning" %}}
+We strongly recommend adding validation checks to all microflows inputs, including read-only attributes. 
+
+We also recommend avoiding storing intermediary values in attributes (such as, *TotalPrice*). Instead, calculate these values when needed to ensure you have the correct values.
+{{% /alert %}}
+
+Microflows should incorporate mechanisms to detect unexpected values and respond suitably – this might involve returning an error message to the end-user or executing a fallback operation. 
+
+##### 4.2.6.3 Updating Validation Logic Regularly
+
+As the application evolves, the validation logic within microflows should be updated accordingly to reflect changes in business logic or data models. This regular review and update of validation checks ensures that microflows remain secure and function correctly over time.
+
+By prioritizing the validation of inputs in microflows, you not only enhance the security of your application, but also ensure a more predictable and stable user experience. This practice underscores the development of reliable and robust applications.
+
 ### 4.3 Workflows
 
 Guidelines below can help you choose a short yet meaningful name for your workflow: