docs: Update audit log and triggers solving comments

docs/feature-flags/audit-logs.mdx

@@ -8,7 +8,7 @@ tags: ['log', 'audit-logs']
 
 The Audit Logs feature stores all log history from the current Environment. You can use the logs to identify problems, or who performed modification in your project flags. 
 
-To access the logs associated with the current environment, select **Audit Logs** on the dashboard sidebar. To check logs from other environments, you first need to change to the desired environment and then access the Audit Logs page.
+To check the logs, access the **Audit Logs** page from the sidebar menu. To check logs from other environments, you first need to change to the desired environment and then access the Audit Logs page.
 
 ## Filtering logs
 
@@ -30,7 +30,7 @@ To make it easier to inspect and find problems source, the Bucketeer system prov
     - Push
     - Subscription
 
-### Existing triggers
+### Actions
 
 Several actions can create a log in Bucketeer. The toggle below contain a table listing all possible action that can generate new logs. 
 

docs/feature-flags/creating-feature-flags/trigger.mdx

@@ -10,11 +10,11 @@ import CenteredImg from '@site/src/components/centered-img/CenteredImg';
 
 Flag triggers are a feature that Bucketeer provides to let you change the flag's state (ON/OFF) by calling a URL. As a result, you can use this option to enable or disable flags during CI/CD (Continuous Integration/Continuous Deployment) pipelines or based on an APM (Application Performance Monitoring) integration.
 
-To access the trigger page on the Bucketeer dashboard, select the **Feature Flags** tab, choose the desired flag, and click on its name. Select the **Trigger** tab at the top of the new page. You can check the existing triggers related to the current feature flag.
+On the Feature Flag details page choose the desired flag, and click on its name. Select the **Triggers** tab at the top to check the existing triggers related to the current feature flag.
 
 ## How to use triggers
 
-You can use the trigger feature to automate the remote flag's state control using Webhook URLs. You can integrate triggers with any tool capable of performing a POST request, enabling you to activate or deactivate flags based on specific operational health thresholds or when you receive specific alerts. You can link each flag to one or more triggers used by one or more tools or alert systems.
+You can use the trigger feature to automate the remote flag's state control using Webhook URLs. You can integrate triggers with any tool capable of performing a POST request. Using such integrations, you to enable or disable flags based on specific operational health thresholds or when you receive specific alerts. You can link each flag to one or more triggers used by one or more tools or alert systems.
 
 One common integration of triggers is with APM solutions, such as:
 
@@ -51,7 +51,7 @@ When you create a trigger, you will receive a Trigger URL. It's important to cop
 
 :::
 
-The Trigger URL includes the authentication token, so all you need to do to activate the trigger is to perform a POST request using the Trigger URL. You must keep the Trigger URL safe and secure, as it contains sensitive information. Anyone with access to the Trigger URL can modify the state of your system flag.
+The Trigger URL includes the authentication token, so all you need to do to enable the trigger is to perform a POST request using the Trigger URL. You must keep the Trigger URL safe and secure, as it contains sensitive information. Anyone with access to the Trigger URL can modify the state of your system flag.
 
 :::warning Trigger URL linkage
 
@@ -86,11 +86,13 @@ Each trigger presents the following information:
 
 :::info Triggered execution
 
-The Triggered Times and Last Triggered will only be updated if the trigger action changes the flag state. For instance, if the flag was initially ON, and the trigger was executed to turn it OFF, then the Triggered Times and Last Triggered will be updated. However, suppose the flag was initially OFF, and the trigger action was also intended to turn it OFF. In that case, there will be no changes to the Triggered Times and Last Triggered because the flag state was not changed.
+The Triggered Times and Last Triggered will be updated every time the trigger request is received, even if the flag state doesn't change. For instance, Triggered Times and Last Triggered will be updated even in the case when a trigger tries to turn OFF a flag that is already OFF. 
+
+Triggered Times and Last Triggered aren't updated, only in case the trigger is disabled when the trigger request is received.
 
 ::: 
 
-After creating a trigger, you can perform four actions on it through the Bucketeer dashboard by clicking on the ellipsis (**...**) located at the top right corner of the trigger card:
+After creating a trigger, you can perform four actions on it through the Bucketeer dashboard by clicking on the **Action** menu (**...**) located at the top right corner of the trigger card:
 
 - **Edit**: Use this option to update the trigger description. 
 - **Disable**: Deactivate the trigger without removing or changing the Trigger URL. Despite receiving a POST request, the Bucketeer system will not execute the trigger action when disabled.
@@ -99,9 +101,9 @@ After creating a trigger, you can perform four actions on it through the Buckete
 
 :::info Reset operation
 
-Resetting a trigger does not restart Triggered Times and Last Triggered information.
+Resetting a trigger doesn't reset Triggered Times and Last Triggered information.
 
-A new field shows up on the trigger card, informing the date of the last reset.
+If you reset a trigger, the reset date will be displayed on the trigger card. This way you can quickly check if a trigger was reseted before and when it was done.
 
 :::