Getting started

In this guide, we’ll 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’ll use a Demo Ticket object type, which has four properties:

• Ticket ID
• Title
• Priority
• Status

We also have two demo objects available:

You can recreate these in your Ontology if desired, but it’s not essential.

Note that for a user to be able to take an Action defined in an Action type configuration, additional configuration is required. For Object Storage V1 (Phonograph), a writeback dataset must be created; for Object Storage V2, the user must enable edits with a toggle.

Create a new Action type

We start by creating a new Action type for changing the ticket’s priority. In the Ontology Manager, click Action type on the left sidebar, then choose New Action type at the top right of the view.

The creation wizard allows you to configure the most important features of an Action type. Enter a Display name for your Action type. Next, select the Change object(s) option and set it to Modify. From the following dropdown, select the Demo Ticket object type and add the Priority property by clicking on Add property. Finally, click Create in the bottom right.

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 Forms tab to get an overview of the parameters. The Ticket and Priority parameter have already been created based by the Rule.

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.

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 Status object parameter's Ticket property. Using the is operator, you can then do an exact string comparison between the ticket status and the specific value Open.

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, click Add Item. Copy and paste the Action RID from the Ontology Manager and paste it into the Action RID field. Name the label “Change Ticket Priority”.

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, click 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.

You will now see the Action button on the preview page:

You can now save and publish the Object View.

Apply the Action

Visit an open ticket and click 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:

Pick a priority and click 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:

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 (limited beta)

Learn more about how to resolve conflicting user edits and datasource updates.

Next Steps

• Learn more about Actions permissions.
• Create a Function-backed Action.
• Use an Action elsewhere in the platform.
• Resolve conflicting user edits (Actions) and datasource updates