diff --git a/serverlessworkflow/modules/ROOT/pages/cloud/operator/using-persistence.adoc b/serverlessworkflow/modules/ROOT/pages/cloud/operator/using-persistence.adoc
index 13e0a735d..3346c289d 100644
--- a/serverlessworkflow/modules/ROOT/pages/cloud/operator/using-persistence.adoc
+++ b/serverlessworkflow/modules/ROOT/pages/cloud/operator/using-persistence.adoc
@@ -9,18 +9,18 @@ This document describes how to configure a SonataFlow instance to use persistenc
 
 == Configuring the SonataFlow CR to use persistence
 
-Kubernetes's pods are stateless by definition. In some scenarios this can be a challenge for workloads that require to maintain the status of 
+Kubernetes's pods are stateless by definition. In some scenarios, this can be a challenge for workloads that require maintaining the status of 
 the application regardless of the pod's lifecycle. In the case of SonataFlow, the context of the workflow is lost when the pod restarts.
-If your workflow requires to recover from such scenarios, you need to make these additions to your Workflow CR:
+If your workflow requires recovery from such scenarios, you must to make these additions to your workflow CR:
 Use the `persistence` field in the `SonataFlow` workflow spec to define the database service located in the same cluster.
 There are 2 ways to accomplish this:
 
 * Using the Platform CR's defined persistence
-When the Platform CR is deployed with its persistence spec populated it enables workflows to leverage on its configuration to populate the persistence
+When the Platform CR is deployed with its persistence spec populated it enables workflows to leverage its configuration to populate the persistence
 properties in the workflows. 
 
 [source,yaml,subs="attributes+"]
-----
+---
 apiVersion: sonataflow.org/v1alpha08
 kind: SonataFlowPlatform
 metadata:
@@ -61,14 +61,14 @@ spec:
 ---
 
 This configuration signals the operator that the workflow requires persistence and that it expects its configuration to be populated accordingly. 
-The operator will add the revelant JDBC properties in the `application.properties` 
+The operator will add the relevant JDBC properties in the `application.properties`
 generated and as part of the pod´s environment so that it can connect to the persistence service defined in the `Platform` CR.
 
 Note that currently only PostgreSQL is the only persistence supported.
 
 * Using the custom defined persistence in the SonataFlow CR
 
-Alternatively you can define a dedicated configuration in the SonataFlow CR instance using the same schema format found in the Platform CRD:
+Alternatively, you can define a dedicated configuration in the SonataFlow CR instance using the same schema format found in the Platform CRD:
 
 [source,yaml,subs="attributes+"]
 apiVersion: sonataflow.org/v1alpha08
@@ -93,8 +93,8 @@ spec:
   ...
 ---
 
-Like in the Platform CR case, the values of the `POSTGRES_USER` and `POSTGRES_PASSWORD` are the keys in the secret that contain the credentials to connect to 
-the postgreSQL instace.
+Like in the Platform CR case, the values of the `POSTGRES_USER` and `POSTGRES_PASSWORD` are the secret keys in the secret that contain the credentials to connect to
+the PostgreSQL instace.
 
 == Conclusion
 You can enable SQL persistence in your workflows by configuring each `SonataFlow` CR instance. And when the `SonataFlowPlatform` CR contains the persistence field configured,