# Getting started In this guide, we will create a simple action type for changing the priority on a ticket. We will configure submission criteria to make sure that the priority is `P0`, `P1`, or `P2`, and that the ticket status is `Open`. ## Prerequisites For this guide, we will use a `Demo Ticket` object type, which has four properties: * `Ticket ID` * `Title` * `Priority` * `Status` We also have two demo objects available: |Ticket ID|Title |Status|Priority| |---------|---------------|------|--------| |PDS-123 |Demo Ticket One|Open |P2 | |PDS-124 |Demo Ticket Two|Closed|P1 | You can recreate these in your Ontology if desired, but it is not essential. For a user to be able to take an action defined in an action type configuration, [additional configuration is required](../../object-link-types/allow-editing/index.md#set-up-the-prerequisites). If running Object Storage v2, the user must enable edits with a toggle. If running Object Storage v1 (Phonograph), a writeback dataset must be created. [Object Storage v1](../../object-databases/object-storage-v1/index.md) is in a [planned deprecation](../../platform-overview/development-life-cycle/index.md) phase of development; [migrate to Object Storage v2](../../object-backend/osv1-osv2-migration/index.md). ## Create a new action type We start by creating a new action type for changing the ticket's priority. In the Ontology Manager, select **Action types** on the left sidebar, then choose **New action type** at the top right of the view. ![Create a new action type](../../../assets/8dd0491c8a317100ce8cdad70b52a0f92f0f8c66dc4df9bb5235cc046f71f310.webp) The creation wizard allows you to configure the most important features of an action type. On the **Action type** step, open the **Object** tab, select the `Demo Ticket` object type, then choose **Modify object(s)** under **Object actions**. On the **Mapping** step, add the `Priority` property by selecting **Add property**. On the **Metadata** step, enter an **Action type name** for your action type. Continue to the final step and select **Create**. You can now see the full detailed view of your action type. You can make additional adjustments, like adding a **Description** in the **Overview** tab or adding additional properties to modify in the **Rules** tab. ## Edit parameters Select the **Parameters** tab to get an overview of the parameters. The `Ticket` and `Priority` parameters have already been created based on the **Rule**. ![Actions form](../../../assets/fe322426e6a324fcce800c6077edf198f87101e51c321953b4aac76c3c44bbc2.webp) Select the `Priority` parameter to limit the values it can take on. Change the constraints from **User input** to **Multiple choice**. This will allow you to pick what values can be chosen for this parameter. Add `P0`, `P1`, and `P2` as options. If you applied your action to an object now, you could change the priority of a ticket to `P0`, `P1`, or `P2`. You will now add submission criteria that will restrict you to only changing the priority for open tickets. ![Priority parameter](../../../assets/b3b401e38aefb84a7ad9ebd87f5b9234feb2df86735ec9d517f4fd42efcc7a7e.webp) ## Add submission criteria Open the submission criteria section in the **Security & Submission Criteria** tab from the sidebar. Create a new condition by selecting **Condition** in the **Execution** section. Using the **Parameter** condition template, set a condition on the `Ticket` object parameter's `Status` property. Using the `is` operator, you can then do an exact string comparison between the ticket status and the specific value `Open`. ![Submission criteria](../../../assets/54230e3033418d52cd6e7ba3e1615878c06043b6ff339daae7973e8b8b55d803.webp) Add a failure message so users can see why an action has failed. Your action definition is now complete, and you can configure it to show up next to the Object View in Object Explorer. ## Add the action to an Object View Go to **Demo Ticket One** and edit its Object View. Add a new widget to the top, and choose the **Actions** widget. In the sidebar, select **Add Item**. Copy the action RID from the Ontology Manager and paste it into the Action RID field. Name the label "Change Ticket Priority". ![Add the action to an Object View](../../../assets/9fe87606f1f6f71b56c08e289be4adabdf79c2c946a4c2763ae8143aa5fad5e0.webp) By default, the action form will show every parameter as a field in the action form, including the `Ticket` parameter. Additionally, an action does not know that it should fill the current object in for the `Ticket` parameter. We will configure the action form to hide the ticket field (so the user cannot change the status of a different ticket), and set its value to the current object. Under **Default value**, select **Add Item**. Type the parameter ID for the `Ticket` parameter—in this tutorial, we set it to `ticket`. Change the value type to **Environment variable** and select **Current object**. Finally, change the display option to **Hidden**. ![Configure the action form](../../../assets/a39ac1fd3defd7dedc6f3f17984298f15769fdc98396761f48d8324c51d9c2fa.webp) You will now see the action button on the preview page: ![Action button on Preview page](../../../assets/2432b3753eb92cffdb53e4d75fa4acfe007b21b6a8e288525de347087b3e44f9.webp) You can now save and publish the Object View. ## Apply the action Before you apply an action, you can validate its submission criteria, rules, and resulting edits with a [test run](../test-run/index.md) in Ontology Manager. Visit an open ticket and select the **Change Ticket Priority** button we configured. You should see the action form appear over the view. Clicking into the **Priority** field will show the single selected submission criterion we configured on the parameter: ![Changing ticket priority with action](../../../assets/33fcf0a442162333bcad3c8cea707f4fed6e79e626bfb7c78fed394e5047c585.webp) Pick a priority and select **Submit**. The form will disappear and the object view will update with the new priority. Our submission criteria said that it should not be possible to run this action on a closed ticket. If we open Demo Ticket Two, which is closed, we see the following: ![Submission criteria prevents action from running on closed ticket](../../../assets/f16c57c62442f0b6340b0df69060e2f619b64c6b0095e1ae3eb97e76b1deb2dc.webp) ## Resolve conflicting user edits (actions) and datasource updates Object instances in the Foundry Ontology can be created and modified by both input datasources and user edits/actions. When a single object instance (that is, a row or object with a specific primary key value) receives data from both the input datasource and user edits, these received values must be transparently resolved with a conflict resolution strategy. There are two strategies for resolving conflicts: * Strategy 1: Apply user edits (default) * Strategy 2: Apply most recent value (may not be available on your enrollment) [Learn more about how to resolve conflicting user edits and datasource updates.](../../object-edits/how-edits-applied/index.md#resolve-conflicting-user-edits-and-datasource-updates) ## Next steps * [Explore the other action types you can build, including link, function, webhook, and scenario actions.](../explore-action-types/index.md) * [Learn more about action permissions.](../permissions/index.md) * [Create a function-backed action.](../function-actions-getting-started/index.md) * [Use an action elsewhere in the platform.](../use-actions/index.md) * [Resolve conflicting user edits (actions) and datasource updates](../../object-edits/how-edits-applied/index.md#resolve-conflicting-user-edits-and-datasource-updates)