diff --git a/docs/concepts/dev-setup.md b/docs/concepts/dev-setup.md
index 8e0fce333..97d4a8857 100644
--- a/docs/concepts/dev-setup.md
+++ b/docs/concepts/dev-setup.md
@@ -82,6 +82,12 @@ Run the [`bootstrap`](https://github.com/demisto/content/blob/master/.hooks/boot
 .hooks/bootstrap
 ```
 
+After the bootstrap script completes, install an extra [`plugin`](https://github.com/python-poetry/poetry-plugin-shell) to get poetry shell to work by running:
+
+```bash
+poetry self add poetry-plugin-shell
+```
+
 After the script completes, you can activate the newly created virtual environment by running:
 
 ```bash
diff --git a/docs/integrations/context-standards-mandatory.md b/docs/integrations/context-standards-mandatory.md
index d2d0e5bfc..223430b51 100644
--- a/docs/integrations/context-standards-mandatory.md
+++ b/docs/integrations/context-standards-mandatory.md
@@ -450,7 +450,7 @@ The following is the format for an Endpoint.
     "EntityAType": "STRING, The type of the source of the relationship.",
     "EntityBType": "STRING, The type of the destination of the relationship.",
     "ID": "STRING, The endpoint's ID.",
-    "IPAddress": "STRING, The endpoint's IP address.",
+    "IPAddress": "STRING, The endpoint's IP address OR LIST, one or more IP addresses.",
     "Domain": "STRING, The endpoint's domain.",
     "MACAddress": "STRING, The endpoint's MAC address.",
     "DHCPServer": "STRING, The DHCP server of the endpoint.",
@@ -493,7 +493,7 @@ The following is the format for an Endpoint.
       description: The endpoint's operation system.
       type: String
     - contextPath: Endpoint.IPAddress
-      description: The endpoint's IP address.
+      description: The endpoint's IP address or list of IP addresses.
       type: String
     - contextPath: Endpoint.ID
       description: The endpoint's ID.
diff --git a/docs/integrations/dynamic-ui-fields.md b/docs/integrations/dynamic-ui-fields.md
new file mode 100644
index 000000000..972b73c9e
--- /dev/null
+++ b/docs/integrations/dynamic-ui-fields.md
@@ -0,0 +1,63 @@
+# Dynamic UI and Parameter Management for Integrations
+
+This guide outlines new features for integrations: controlling parameter order, the `engine_placeholder` field (type 23), and the `triggers` section. These enhancements improve user experience and enable more dynamic configuration.
+
+## 1. Parameter Order Control
+
+The order of parameters in the YAML file determines their display order in the user interface. This applies to standard parameters only; built-in parameters, such as `Log Level` and the `Do Not Use by Default` checkbox ,and other system parameters, are static and cannot be repositioned. An exception is made for the `engine` dropdown, as detailed below.
+
+## 2. Specifying Engine Location (Type 23)
+
+The `engine` dropdown's location in the user interface is now explicitly defined using the `engine_placeholder` field (type 23). This replaces the previous implicit handling.  Built-in parameters such as `log_level` remain static and cannot be repositioned.  Positioning the `engine` dropdown is achieved by placing the `engine_placeholder` within the YAML configuration.  The `engine` dropdown then appears at the `engine_placeholder`'s location.
+
+**YAML Structure:**
+
+```yaml
+- name: engine_placeholder
+  type: 23
+  section: Connect
+```
+
+**Important Note:** This functionality is not currently available for Cortex XSOAR 6.x.  Using `engine_placeholder` in Cortex XSOAR 6.x UI will create a non-functional parameter with the name `engine_placeholder`.
+
+
+## 3. Implementing Dynamic Behavior with Triggers
+The `triggers` section enables dynamic UI behavior based on user input and enables you to define conditions and effects to control the visibility (`hidden`) and required status (`required`) of UI elements.
+
+**YAML Structure:**
+
+```yaml
+triggers:
+  - conditions:
+      - name: <field_to_check> # Field whose value determines the effect
+        operator: <operator>   # (exists, not_exists, equal, not_equal)
+        value: <value>         # Value to compare against (required only for equal/not_equal)
+    effects:
+      - name: <field_to_affect> # Field whose properties are modified
+        action:
+          required: <true/false> # Set to true to make the field required, false otherwise
+          required: true       # Makes the field mandatory if the condition is met
+          # hidden: <true/false>  Can also be used here to hide/show the field.
+          # Other UI actions are also possible.
+```
+
+**Example:** Hide the `token` field if the `username` field has a value:
+
+```yaml
+triggers:
+  - conditions:
+      - name: username
+        operator: exists
+    effects:
+      - name: token
+        action:
+          hidden: true
+```
+
+The example demonstrates how to dynamically hide UI elements based on the existence of a username.  This prevents unnecessary display of the token field and avoids confusion.
+
+**Note:** Multiple conditions within a trigger use an "AND" relationship; all conditions must be true for the effect to apply.
+
+
+
+For a complete example, see the generic webhook integration.
diff --git a/sidebars.js b/sidebars.js
index f47812037..97b7dad03 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -160,6 +160,8 @@ const sidebars = {
             "integrations/yml-from-python-code-gen",
             "integrations/fetch-incidents-lookback",
             "integrations/Trust-any-certificate",
+            "integrations/dynamic-ui-fields"
+
           ]
         }
       ]