docs: update visuals feature flags section

docs/feature-flags/api-keys.mdx

@@ -8,22 +8,25 @@ tags: ['integration', 'feature-flag']
 
 import CenteredImg from '@site/src/components/centered-img/CenteredImg';
 
-The API keys authorizes and control access to the feature flag management system, providing authentication capabilities that ensure secure connections between your application and the server.<br />
-Each API key is associated with a specific environment, allowing you to identify and link your application to the desired user group.
+The API keys authorizes and control access to the feature flag management system, providing authentication capabilities that ensure secure connections between your application and the server.
 
-## Creating an API Key
+Each API key is associated with a specific environment, allowing you to identify and link your application to the desired user group.
 
-To create an API key, you need to be an Admin or have an environment account with the Owner role. Other members can see the APY keys but can't manage them.
+## Key Roles
 
-The API key has 2 roles.
+In Bucketeer, when you create an API key, you have to select a key role. The Key Role defines the permissions and access levels associated with the API key. The available roles are:
 
 - **Client SDK:** Allows all SDKs to evaluate end users on the Bucketeer server.
 - **Server SDK:** Allows the server SDK (Golang) to evaluate end users locally within the SDK.
 - **Public API(Read Only):** This role allows you to read the data in Bucketeer.
 - **Public API(Read and Write):** This role allows you to read and write the data in Bucketeer.
 - **Public API(Admin):** This role allows you to read and write the data including admin settings in Bucketeer.
 
-To generate a new API key, click the **+ Add** button on the **API Keys** page.<br />
+## Creating an API Key
+
+To create an API key, you need to be an Admin or have an environment account with the Owner role. Other members can see the APY keys but can't manage them.
+
+To generate a new API key, access the API Keys panal page and  click **+ New API Key** button. After, provide a descriptive name for the key, select the Environment in which the key will be used, and choose the appropriate Key Role based on your requirements. Finally, click the **Submit** button to generate the API key.
 
 <CenteredImg
   imgURL="img/feature-flags/api-keys/create-api-key.png"

docs/feature-flags/audit-logs.mdx

@@ -18,18 +18,16 @@ To check the logs, access the **Audit Logs** page from the sidebar menu. To chec
 
 ## Filtering logs
 
-By default, the Audit Logs displays the most recent entries. However, you can use the **Sort** button at the top right corner to switch to the **Oldest** first if you need.
-
 Bucketeer system provides several filters you can use to find desired logs, making it easier to inspect and find problem sources. The complete filter options are listed below:
 
-- **Email**: User email who performed the change, such as modifying a flag variation.
+- **Name and Email**: User name and email who performed the change, such as modifying a flag variation. This options is available thorugh the search bar.
 - **Date**: Specify a date range when the logs were created.
 
-<CenteredImg
-  imgURL="img/feature-flags/audit-logs/date.png"
-/>
+    <CenteredImg
+      imgURL="img/feature-flags/audit-logs/date.png"
+    />
 
-- **Entity**: Select the type of entity related to the log source. You can use this option to filter logs related only to changes in Goals, for example. The complete list is presented next:
+- **Kind**: Select the type of entity related to the log source. You can use this option to filter logs related only to changes in Goals, for example. The complete list is presented next:
     - Feature Flag
     - Goal
     - Experiment
@@ -41,9 +39,6 @@ Bucketeer system provides several filters you can use to find desired logs, maki
     - Push
     - Subscription
 
-<CenteredImg
-  imgURL="img/feature-flags/audit-logs/action.png"
-/>
 
 ### Actions
 

docs/feature-flags/code-reference/scan-results.mdx

@@ -57,7 +57,3 @@ To refine the scan results, Bucketeer provides **three filtering options**:
 - **By repository**: View feature flag references within a specific repository.
 - **By branch**: Narrow results to a specific branch in the repository.
 - **By file extension**: Filter results based on file types (e.g., `.js`, `.py`, `.java`).
-
-<CenteredImg
-  imgURL="img/feature-flags/codereference/scan-result-filtering.png"
-/>

docs/feature-flags/creating-feature-flags/auto-operation/auto-operation.mdx

@@ -1,20 +1,26 @@
 ---
-title: Auto Operation
+title: Operations
 # sidebar_position:
 slug: /feature-flags/creating-feature-flags/auto-operation
-description: The Auto Operation feature handles the manipulation of feature flag configurations on your behalf. It executes specific operations automatically based on the conditions set by the user.
+description: The Operations feature handles the manipulation of feature flag configurations on your behalf. It executes specific operations automatically based on the conditions set by the user.
 tags: ['guide', 'automation', 'operation', 'feature-flag']
 ---
 
 import CenteredImg from '@site/src/components/centered-img/CenteredImg';
 
-The Auto Operation feature handles the manipulation of feature flag configurations on your behalf. It executes specific operations automatically based on the conditions you have set.
+The Operation feature handles the manipulation of feature flag configurations on your behalf. It executes specific operations automatically based on the conditions you have set.
 
-On the Feature Flag details page, select the **Auto Operation** tab at the top to check the active and completed operations or to configure new ones.
+On the Feature Flag details page, select the **Operation** tab at the top to check the active and completed operations or to configure new ones.
 
-## How auto operation works
+<CenteredImg
+  imgURL="img/feature-flags/auto-ops-rules/operations-overview.png"
+  alt="Operation panel"
+  borderWidth="1px"
+/>
 
-The auto operation feature consists of two key elements:
+## How operations work
+
+The operation feature consists of two key elements:
 
 - **Operation**: An action triggered by one or more conditions. When the condition is met, the action related to the operation is executed. Currently, Bucketeer supports two types of operations:
 
@@ -23,16 +29,16 @@ The auto operation feature consists of two key elements:
 
 - **Condition**: A condition specifies the circumstances under which the operation is triggered. Multiple conditions can be associated with a single killing operation. On the other hand, only one condition can be related to enabling a feature flag. Similarly, each rollout phase is linked to a condition. It's important to note that the corresponding operation is triggered if any conditions are satisfied.
 
-Based on the operations and conditions, the auto operation works as follows:
+Based on the operations and conditions, the operation works as follows:
 
 1. The server monitors the specified conditions.
 2. When a condition is met, the corresponding operation is executed.
 3. The triggered operation's status changes from **Active** to **Complete** after turning the associated flag ON or OFF.
-4. The operation is moved from the **Active** to the *Completed* panel, indicating that it has been executed.
+4. The operation is moved from the **Active** to the **Completed** panel, indicating that it has been executed.
 
 ## Conditions
 
-As mentioned, a condition must be fulfilled to trigger an auto operation. Currently, Bucketeer provides three condition options, which you can use to configure auto operations in your application:
+As mentioned, a condition must be fulfilled to trigger an operation. Currently, Bucketeer provides three condition options, which you can use to configure operations in your application:
 
 - [Schedule](/feature-flags/creating-feature-flags/auto-operation/schedule): Specify the date and time to enable or kill a flag.
 - [Progressive rollout](/feature-flags/creating-feature-flags/auto-operation/progressive-rollout): Determine a strategy to progressively release a feature flag variation.

docs/feature-flags/creating-feature-flags/auto-operation/event-rate.mdx

@@ -30,18 +30,20 @@ To set up the event rate condition, you need to define the following configurati
 
 Bucketeer system uses the following formula to calculate the event rate:
 
-**Event Rate = (Unique Counter of Goal Events) / (Unique Counter of Evaluation Events)**
+```
+Event Rate = (Unique Counter of Goal Events) / (Unique Counter of Evaluation Events)
+```
 
 Refer to the [Experiments](/feature-flags/testing-with-flags/experiments) and [Evaluate results](/feature-flags/creating-feature-flags/evaluate-results) sections for a better understanding of the user count of goals and evaluations.
 
 ## Setting up auto operation with event rate
 
 To add an event rate condition to a feature flag, you need to follow the steps below:
 
-1. Go to the **Auto Operation** tab on the feature Flag page details.
+1. Go to the **Operation** tab on the feature Flag page details.
 2. Click the **+ New Operation** and select **Event Rate**.
 3. Set up the conditions. Define the variation, goal, condition, threshold, and minimum count.
-4. Click **Submit**. 
+4. Click **Create Operation**. 
 
 The image below presents an example of event rate configuration. The current configuration's objective is to turn off the feature flag in case of a high error rate above 5%. A minimum count of 500 is used to avoid misleading turn-offs.
 
@@ -54,7 +56,7 @@ The image below presents an example of event rate configuration. The current con
 
 ## Managing event rates
 
-After creating an event rate, it becomes active and is available in the Auto Operation panel. You can identify it by the **Event Rate** tag or the **Kill Switch Operation** type. The event rate progress information visually displays the current event rate percentage and includes:
+After creating an event rate, it becomes active and is available in the Operation panel. You can identify it by the **Event Rate** tag or the **Kill Switch Operation** type. The event rate progress information visually displays the current event rate percentage and includes:
 
 - The associated goal.
 - The minimum goal count.
@@ -77,4 +79,4 @@ While active, you can edit, stop, or delete the event rate:
 
 ## Event rate lifecycle
 
-When you create an event rate, it will be active and available in the **Active** tab of the Auto Operation panel. The event rate (kill switch operation) continuously monitors the flag operation, counting every condition defined at its creation. When the threshold is reached, it will kill the flag, turning it off. Afterward, the event rate moves to the **Finished** tab.
+When you create an event rate, it will be active and available in the **Active** tab of the Operation panel. The event rate (kill switch operation) continuously monitors the flag operation, counting every condition defined at its creation. When the threshold is reached, it will kill the flag, turning it off. Afterward, the event rate moves to the **Finished** tab.

docs/feature-flags/creating-feature-flags/auto-operation/rollout.mdx

@@ -29,9 +29,9 @@ On the first day of the rollout, 10% of your users will see the new content. On
 
 To add a rollout to a feature flag, you need to follow the steps below:
 
-1. Go to the **Auto Operation** tab on the feature Flag page details.
+1. Go to the **Operation** tab on the feature Flag page details.
 2. Click the **+ New Operation** and select **Progressive Rollout**.
-3. Configure the rollout and click **Submit**. Check the [Template rollout](#template-rollout) or [Manual rollout](#manual-rollout) sections to learn how to configure the rollout.
+3. Configure the rollout and click **Create Operation**. Check the [Template rollout](#template-rollout) or [Manual rollout](#manual-rollout) sections to learn how to configure the rollout.
 
 :::caution Restrictions
 
@@ -61,7 +61,7 @@ The rollout provides two main options when setting it up:
 
 If you choose to use the Template rollout, you need to define the following configurations before submitting it:
 
-- **Variation**: Choose the variation to roll out. You should not choose the same variation selected as [OFF variation](/feature-flags/creating-feature-flags/targeting#the-targeting-page). Otherwise, it could affect what the end users see.
+- **Flag Variation**: Choose the variation to roll out. You should not choose the same variation selected as [OFF variation](/feature-flags/creating-feature-flags/targeting#the-targeting-page). Otherwise, it could affect what the end users see.
 - **Start Date**: The rollout starting date and time. 
 - **Increment**: The percentual increment used at each rollout release phase. This option will define, as a result, the total number of rollout releases. If you choose 10%, ten stages are required to reach the total rollout.
 - **Frequency**: The frequency of each rollout phase (hourly, daily, weekly) will be released. The first phase will depend on the **Start Date** value you selected, and the remaining phases will rely on this starting point. 
@@ -98,11 +98,10 @@ The image below summarizes an example of a configuration using the Manual config
 
 ## Managing rollouts
 
-After creating a rollout, it becomes active and is available in the Auto Operation panel. You can identify the rollout by the **Progressive Rollout** tag or the **Enable Operation** type. The rollout progress information displays all rollout phases, including the respective dates, times, and the total percentage released at each phase. The progress information also includes:
+After creating a rollout, it becomes active and is available in the Operation panel. You can identify the rollout by the **Progressive Rollout** tag or the **Enable Operation** type. The rollout progress information displays all rollout phases, including the respective dates, times, and the total percentage released at each phase. The progress information also includes:
 
 - **Increment**: The percentage increment used at each rollout release phase (only available for Template rollouts).
 - **Start Date**: The date when the progressive rollout will start.
-- **Variation**: The flag variation being released.
 - **Frequency**: The frequency of each rollout phase (hourly, daily, weekly), (only available for Template rollouts).
 
 The following image shows an example of progress information for a progressive rollout:
@@ -126,19 +125,19 @@ While active, you can stop or delete the rollout:
 
 ## Roullout lifecycle
 
-When you create a rollout, it will be active and available in the **Active** tab of the Auto Operation panel. The first rollout stage (0%) displays the date and time of its creation. As each stage is reached, the progress information panel updates, providing clear visual information about the current rollout progress. After all rollout stages are completed, the rollout moves to the **Finished** tab. The following image presents an example of progress information for a running rollout.
+When you create a rollout, it will be active and available in the **Active** tab of the Operation panel. The first rollout stage (0%) displays the date and time of its creation. As each stage is reached, the progress information panel updates, providing clear visual information about the current rollout progress. After all rollout stages are completed, the rollout moves to the **Finished** tab. The following image presents an example of progress information for a running rollout.
 
 <CenteredImg
   imgURL="img/feature-flags/auto-ops-rules/running-rollout.png"
   alt="Running rollout example"
   borderWidth="1px"
 />
 
-## Combining auto operations
+## Combining operations
 
-You can combine the usage of available [auto operations](/feature-flags/creating-feature-flags/auto-operation) from Bucketeer. For example, you can define a progressive rollout, a [schedule](/feature-flags/creating-feature-flags/auto-operation/schedule), and a [event rate](/feature-flags/creating-feature-flags/auto-operation/event-rate) conditions for the same flag. 
+You can combine the usage of available [operations](/feature-flags/creating-feature-flags/auto-operation) from Bucketeer. For example, you can define a progressive rollout, a [schedule](/feature-flags/creating-feature-flags/auto-operation/schedule), and a [event rate](/feature-flags/creating-feature-flags/auto-operation/event-rate) conditions for the same flag. 
 
-It's vital to note that turning off a flag by schedule or event rate conditions has a higher priority than the progressive rollout. Therefore, if your flag has a running progressive rollout and an Auto Operation is triggered, the system will stop the progressive rollout. The progressive rollout will be moved to the **Finished** tab, where you can check the last rollout state or use it as a reference for future rollouts.
+It's vital to note that turning off a flag by schedule or event rate conditions has a higher priority than the progressive rollout. Therefore, if your flag has a running progressive rollout and an operation is triggered, the system will stop the progressive rollout. The progressive rollout will be moved to the **Finished** tab, where you can check the last rollout state or use it as a reference for future rollouts.
 
 ## Restrictions and rules
 
@@ -163,8 +162,8 @@ If you need to update a flag that has a running progressive rollout associated w
 - The default strategy on the [Targeting](/feature-flags/creating-feature-flags/targeting) tab can't be modified.
 - You're not able to add or remove variations to the flag. However, you can edit the values, names, and descriptions of the existing variations.
 
-### Other Auto Operations
+### Other operations
 
 Progressive rollouts can be created for flags, whether they're enabled or disabled. 
 
-If either manual intervention or Auto Operations turn OFF a flag, the default strategy percentage will remain the last progressive rollout update value. Consequently, if the flag is turned back on in the future, the default strategy percentage will be the last updated value when the progressive rollout is stopped.
+If either manual intervention or a operation turn OFF a flag, the default strategy percentage will remain the last progressive rollout update value. Consequently, if the flag is turned back on in the future, the default strategy percentage will be the last updated value when the progressive rollout is stopped.