doc: approval workflows revamp

docs/documentation/platform/access-controls/access-requests.mdx

@@ -6,7 +6,7 @@ description: "Learn how to request access to sensitive resources in Infisical."
 In certain situations, developers need to expand their access to a certain new project or a sensitive environment. For those use cases, it is helpful to utilize Infisical's **Access Requests** functionality. 
 
 This functionality works in the following way: 
-1. A project administrator sets up a policy that assigns access managers (also known as eligible approvers) to a certain sensitive folder or environment. 
+1. A project administrator sets up an access policy that assigns access managers (also known as eligible approvers) to a certain sensitive folder or environment. 
 ![Create Access Request Policy Modal](/images/platform/access-controls/create-access-request-policy.png)
 ![Access Request Policies](/images/platform/access-controls/access-request-policies.png)
 
@@ -14,7 +14,10 @@ This functionality works in the following way:
 ![Access Request Create](/images/platform/access-controls/request-access.png)
 ![Access Request Dashboard](/images/platform/access-controls/access-requests-pending.png)
 
-3. An eligible approver can approve or reject the access request. 
+3. If the access request matches woth a policy that has a **Soft** enforcement level, the requester could bypass the policy and get access to the resource without approval.
+![Access Request Bypass](/images/platform/access-controls/access-request-bypass.png)
+
+4. An eligible approver can approve or reject the access request. 
 ![Access Request Review](/images/platform/access-controls/review-access-request.png)
 
 4. As soon as the request is approved, developer is able to access the sought resources. 

docs/documentation/platform/pr-workflows.mdx

@@ -18,10 +18,22 @@ In a similar way, to solve the above-mentioned issues, Infisical provides a feat
 
 ### Setting a policy
 
-First, you would need to create a set of policies for a certain environment. In the example below, a generic policy for a production environment is shown. In this case, any user who submits a change to `prod` would first have to get an approval by a predefined approver (or multiple approvers).
+First, you would need to create a set of policies for a certain environment. In the example below, a generic change policy for a production environment is shown. In this case, any user who submits a change to `prod` would first have to get an approval by a predefined approver (or multiple approvers).
 
 ![create secret update policy](../../images/platform/pr-workflows/secret-update-policy.png)
 
+### Defining enforcement level
+
+The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need approval prior merging. A **Soft** enforcement level means that a change requests that matches the policy could be bypassed if the requester provides a reason for the bypass. If a change request is bypassed, the approvers will be notified via email.
+
+Take into account that a **Soft** enforcement level is more flexible and allows for more flexibility in the approval process but it's more prone to human error.
+
+### Example of creating a change policy
+
+When creating a policy, you can choce the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**.
+
+![create panel secret update policy](../../images/platform/pr-workflows/create-change-policy.png)
+
 ### Example of updating secrets with Approval workflows
 
 When a user submits a change to an enviropnment that is under a particular policy, a corresponsing change request will go to a predefined approver (or multiple approvers).