backend update

docs/actions-and-automations/actions-and-automations.md

@@ -14,29 +14,37 @@ Self-service actions drive developer productivity by providing a consistent and
 For real-world examples of self-service actions, check out our [live demo](https://demo.getport.io/self-serve).
 :::
 
-For more information and instructions for creating self-service actions, click [here](/).
+For more information and instructions for creating self-service actions, click [here](/actions-and-automations/create-self-service-experiences).
 
 ## 2. Automations
 
 Use events in your infrastructure as triggers to run custom workflows. Automations can be used to enforce policies, send notifications, or run any other logic you wish.  
 They are a safe and efficient way to perform routine and repetitive tasks, freeing up your team to focus on other priorities.
 
-For more information and instructions for defining automations, click [here](/).
+For more information and instructions for defining automations, click [here](/actions-and-automations/define-automations).
 
 ## Comparison
 
 Technically speaking, the difference between self-service actions and automations is the **trigger**:
 - **Self-service actions** are triggered manually by a user, and are typically used for tasks that require user input and/or approval. Actions can have defined user inputs.
 - **Automations** are triggered by events in your infrastructure, and are typically used for tasks that are routine and repetitive. Automations do not have user inputs.
 
-### Identical backend
+### Identical backend & progress reflection
+
+#### Backend
 
 For both self-service actions and automations, you define the logic that runs when the action is triggered.  
 Port supports a wide range of backend options to execute your logic, including GithHub workflows, Jenkins pipelines, custom webhooks, and more.  
 
 The same backend infrastructure is used for self-service actions and automations, making the backend part of the process identical for both.
 
-For more information on available backends and how to set them up, click [here](/).
+For more information about available backends and how to set them up, click [here](/actions-and-automations/setup-backend).
+
+#### Progress reflection
+
+When an action or automation is triggered, Port creates an "Action run" object that represents the execution. You can interact with this object to get/set the status of the run, view/add logs, and more.  
 
+This object is identical for both self-service actions and automations.
 
+For more information about the "Action run" object and how to interact with it, click [here](/actions-and-automations/reflect-action-progress).
 

docs/actions-and-automations/automations/automations.md → docs/actions-and-automations/define-automations/automations.md

@@ -21,8 +21,8 @@ Port uses the same actions for automations and for [self-service actions](/actio
 
 Automations are comprised of two parts:
 
-1. **Trigger** - An event in your software catalog that you want to act upon. This can be any one of the events defined [here](/actions-and-automations/automations/setup-trigger).
-2. **Action** - The logic that you want to execute when the trigger event occurs. This can be any one of the actions defined [here](/actions-and-automations/automations/setup-action). 
+1. **Trigger** - An event in your software catalog that you want to act upon. This can be any one of the events defined [here](/actions-and-automations/define-automations/setup-trigger).
+2. **Action** - The logic that you want to execute when the trigger event occurs. This can be any one of the actions defined [here](/actions-and-automations/define-automations/setup-action). 
 
 When an event occurs in your software catalog, Port will automatically trigger the associated action, given that the automation is enabled.  
 
@@ -65,8 +65,8 @@ The table below describes the fields in the JSON structure (fields in **bold** a
 | `title` | The automation's title. |
 | `icon` | The automation's icon. |
 | `description` | A description that can be used to explain the automation. |
-| **`trigger`** | An object containing data about the automation's trigger. See [Setup trigger](/actions-and-automations/automations/setup-trigger) for more information. |
-| **`invocationMethod`** | An object containing data about the automation's invocation method. See [Setup action](/actions-and-automations/automations/setup-action) for more information. |
+| **`trigger`** | An object containing data about the automation's trigger. See [Setup trigger](/actions-and-automations/define-automations/setup-trigger) for more information. |
+| **`invocationMethod`** | An object containing data about the automation's invocation method. See [Setup action](/actions-and-automations/define-automations/setup-action) for more information. |
 | `publish` | A boolean value indicating whether the automation is enabled or disabled (`false` by default). |
 
 ## Define an automation
@@ -76,7 +76,7 @@ Automations are defined in the [Automations page](https://app.getport.io/setting
 1. Click on the `+ New automation` button in the top-right corner. This will open a JSON form where you can define the automation's configuration.
 
 2. Change the JSON configuration to match your desired automation:
-   * Setup the [trigger](/actions-and-automations/automations/setup-trigger).
-   * Define the [action](/actions-and-automations/automations/setup-action) that will be executed when the trigger event occurs.
+   * Setup the [trigger](/actions-and-automations/define-automations/setup-trigger).
+   * Define the [action](/actions-and-automations/define-automations/setup-action) that will be executed when the trigger event occurs.
 
 3. Make sure to set the `publish` field to `true` if you want to enable the automation. When finished, click `Save`.

docs/actions-and-automations/automations/setup-trigger.md → docs/actions-and-automations/define-automations/setup-trigger.md

@@ -59,7 +59,7 @@ The table below describes the fields in the JSON structure under the `trigger` k
 | --- | --- |
 | **`type`** | The automation's trigger type. Should be set to `automation`. |
 | **`event`** | An object containing data about the event that triggers the automation. |
-| **`event.type`** | The [trigger event type](/actions-and-automations/automations/setup-trigger#available-triggers). |
+| **`event.type`** | The [trigger event type](/actions-and-automations/define-automations/setup-trigger#available-triggers). |
 | **`event.blueprintIdentifier`** | The identifier of the blueprint whose entities will trigger the automation. |
 | `condition` | An optional object containing `jq` expressions used to determine which entities the automation will be triggered for. See [Conditions](/actions-and-automations/create-self-service-experiences/setup-ui-for-action/#conditions) for more information. |
 | `condition.type` | The type of condition. Should be set to `JQ`. |

docs/actions-and-automations/setup-backend/setup-backend.md

@@ -15,7 +15,7 @@ import TabItem from "@theme/TabItem"
 </center>
 <br/>
 
-Port's self-service actions support a variety of backends that can be triggered when a user invokes an action.
+Port's self-service actions and automations support a variety of backends that can be used when triggered.
 
 Here is the basic backend model:
 
@@ -26,7 +26,7 @@ When creating an action, you can define the payload that will be sent every time
 
 Executing a self-service action involves the following steps:
 
-1. **The action is triggered in Port** - the trigger can either be a user executing an action via the UI, or an automation triggering an action via Port's API.
+1. **The action is triggered in Port** - the trigger can either be a user executing a self-service action via the UI, or an automation triggering an action.
 2. **The payload is sent to your backend** - the payload, as defined by the action's creator, is sent to your backend. The backend can be a URL, a dedicated Kafka topic or one of your CI/CD workflows/pipelines.
 3. **Your backend receives the payload and handles the request** - depending on the action, your backend might open a PR, create a cloud resource, provision a new environment, or perform any other logic you would like.
 4. **Your backend updates Port on the status of the execution** - You can [enrich the action run object](/actions-and-automations/reflect-action-progress/) in Port by adding logs, attaching links to other workflows or pipelines that help fullfil the request and add a final success/fail status once the action is complete.