Over the past couple of releases our teams have made some updates to the declarative actions functionality (with more to come!). This article highlights those changes across Utah and Vancouver.

## Utah

#### **New condition option: scripted client condition for Forms**

Leverage scripted client conditions to dynamically show/hide DAs in the Form or Field Decorator action models without needing to save the form or refresh the page.

**What’s changed?**

This is similar to the pre-existing “Client Conditions” field (which are also evaluated at runtime without needing a form to reload), but client conditions have limitations. The new Scripted Client Conditions provides more flexibility and the ability to evaluate whether an action should show/hide based on changes to action model property, including all form fields.

* The Scripted Client Condition field is available in the Declarative Action Assignment form for Field Decorators and Form action models.
* Access to evaluate all action model properties
* Evaluation of Scripted Client Condition field after form field edits
* Showing/Hiding DAs based on evaluated result of Scripted Client Condition expression

_Example:_

Let's set up the Open Record field decorator to show/hide based on the value of the Short Description field on an Incident Form. (This can be applied to a DA Assignment record for the UI Action Bar too.)

1. Navigate to Field Decorators.
2. Open the out-of-box Open Record action that applies to all reference fields on all tables. (sysid: _172e2043534310108135ddeeff7b12dd)_
3. Open the **Advanced View** for the record
4. Open the **Conditions** section of the form.
5. In the **Scripted Client Conditions** field enter the following which evaluates that the **Short Description** field is not empty before showing the Open Record DA for reference fields.:
_"{{fields.short\_description.value}}" != ""_
6. Save the record.
7. Navigate to an Incident record in a configurable workspace.
8. Modify the Short Description field to be empty and click off the field. Do not save the form.

Any reference field on the Incident form that has a value set would also have an Open Record Icon:

When the Short Description field is modified to be empty, the Scripted Client Condition field content would be evaluated and would evaluate to false, thus setting the Open Record DA to be hidden:

#### **Global Declarative Actions for Forms**

Create global, experience-agnostic Declarative Actions that show up without any additional configuration.

**What’s changed?**

Previously, there was no way to create a DA that would appear across all experiences without additional configuration. Now you can create an action and see it on all applicable experiences/places.

* On the Declarative Action Assignment record for the Form data model, you will now see a new Boolean field called “Enable for all configurable experiences”. By default this will be false.
* If set to true, the action will appear in all applicable experiences.

## Vancouver

#### **Hide Declarative Actions from a view and/or table**

You may now exclude actions based on view (sys\_ui\_view), or a combination of view and table.

**What’s changed?**

Previously, there was only the option to exclude a DA based on table. Adding support for exclusion based on view is another option to provide more flexibility on when and where actions appear.

Example:

_Let’s exclude the “Assign to me” action from all incident tables using the “Service Operations Workspace” view._

1. Configure an **Action Exclusion** (_sys\_workspace\_declarative\_action\_exclusion_) record:
1. **Action assignment**: select “assign\_to\_me” \[references the _sys\_declarative\_action\_assignment_ record the exclusion should be applied to)
2. **Table:** select “Incident” \[_table\_name_ field that specifies the table to exclude the action.\]
3. **Exclude this table**: true \[boolean field that expresses that the action should be excluded from the specified table when the field is set to true\]
4. **Exclude all child tables:** false \[boolean field that expresses that the action should be excluded from all child tables of the specified table (but not that table) when the field is set to true\]
5. **View**: Service Operations Workspace \[reference field to a **UI View** (_sys\_ui\_view_) record that specifies the view under which the action is excluded.\]
2. Note, you are required to choose a table **or** a view in order to save an Action Exclusion record.
3. Since both _Table_ and a _View_ have been selected in our example, the action will be excluded for the corresponding table using the specified view (in this case, all incident lists that use the “Service Operations Workspace” view won’t have the “Assign to me” action). If the user fills in a _View_ only_,_ thenthe action will be excluded whenever that _the specified view is shown_, regardless of table. If the user fills in only _Table_, then the action will be excluded on that table, regardless of view.

#### **Conditionally enable actions based on record(s) selected in the List**

Enable or disable actions based on conditions of individual records selected in the List or Related List at runtime.

**What’s changed?**

Previously, if an admin wanted to enable/disable List Declarative Actions based on conditions of each record selected in the list, they would have to run condition checks in the server scripts bound to each action. These scripts would run after the user has clicked the action button and if the conditions were not met, they would be presented with an error message which can be a frustrating experience.

* The system property _glide.list.actions\_conditional\_evaluation\_enabled_ controls whether the feature is enabled or not. The property is shipped out of box and enabled by default.
* To allow dynamic evaluation of a **List** or **Related List Action**, the system administrator first needs to set the _Record Selection Required_ to true and keep _Experience Restricted_ false in the **Action Assignment** record.
* To define the dynamic evaluation of a **List or Related List Action**, there are new fields _Enable Dynamic Evaluation_, _Dynamic Script Condition_, _Dynamic Record Conditions_ under the **Advanced View** in the **Condition** section of the **Action Assignment** records that have a **List** or **Related List Action Model:**
* _Enable Dynamic Evaluation_ is a boolean field that controls whether the feature should apply or not to this specific action.
* _Dynamic Script Condition_ is a condition string field that has access to _current_ record (as a selected record on the list) and the _parent_ record if the declarative action applies to the **Related List** actionmodel. If its expression is evaluated to be false, the action is displayed but disabled, if it’s evaluated to be true, the action is enabled.
* _Dynamic Record Conditions_ is a condition builder field dependent on the table (it builds a condition using the columns of the table). If it’s evaluated to be false, the action is displayed but disabled, if it’s evaluated to be true, the action is enabled.
* Note, it’s possible slowness and unresponsiveness may be experienced if this feature is used in combination with the **Select All** feature, that selects all records in a list, as conditions will need to be evaluated for all the selected records especially if the list is particularly large.

_Example:_

_Let’s create a new list action that assigns an active incident to the current user if the incident has a low priority of **5 - Planning**_​​​​​​​

1. Navigate to **List Actions** and create a new action, as follows, and save the record:
1. **Action label:** My Assign to Me​​​​​​​
2. **Action name**: my\_assign\_to\_me​​​​​​​
3. **Implemented as:** Server Script​​​​​​​
4. **Table**: Incident
2. Under **Advanced View**, enable the _Record Selection Required_ and _Experience Restricted_ fields
3. Navigate to the **Conditions** tab and set _Enable Dynamic Conditions_ to true
4. Fill the **Dynamic Script Condition** field as:
```
current.active && current.assigned_to.canWrite()​
```
5. Add a new condition in the _Dynamic Record Conditions_ condition builder that the _Incident_ record must have _priority_ of _5 - Planning_
6. Under **Advanced View**, in **Server Script** section, fill in the _Server Script_ field as follows:
```
assignToMe();
function assignToMe() {
if (!current.active || !current.assigned_to.canWrite()) {
gs.addErrorMessage(gs.getMessage('{0}, You do not have permission to update assigned to', [current.number]));
return;
}
current.assigned_to = gs.getUserID();
current.update();
}​
```
7. Since we set the field _Experience Restricted_ to true, we need to add the action to a **Workspace's Action Configuration** for it to appear an **Incident** list in a **Workspace**. Navigate to the **Action Configuration Related List**, and use the **Edit...** action to add the declarative action to the configuration associated with your experience.
8. Open _Incidents_ in your workspace. Verify that the newly created action is there, but it is disabled.
9. Observe the following behavior:
* The action appears **disabled** if there are no records selected.
* The action will only be **enabled** if every selected record satisfies the **dynamic conditions** of the action, the incident is active and has a priority of _5 - Planning_.
* If the action is executed, the _Assigned To_ field of the selected record(s) has changed to the current user.

Labels:

* [Next Experience Release Updates](https://www.servicenow.com/community/next-experience-articles/tkb-p/next-experience-kb/label-name/next%20experience%20release%20updates?labels=next+experience+release+updates)
* [UI Framework Next Experience](https://www.servicenow.com/community/next-experience-articles/tkb-p/next-experience-kb/label-name/ui%20framework%20next%20experience?labels=ui+framework+next+experience)

[](https://www.servicenow.com/now-platform/latest-release.html)