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.)
- Navigate to Field Decorators.
- Open the out-of-box Open Record action that applies to all reference fields on all tables. (sysid: 172e2043534310108135ddeeff7b12dd)
- Open the Advanced View for the record
- Open the Conditions section of the form.
- 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}}" != "" - Save the record.
- Navigate to an Incident record in a configurable workspace.
- 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.
- Configure an Action Exclusion (sys_workspace_declarative_action_exclusion) record:
- Action assignment: select “assign_to_me” [references the sys_declarative_action_assignment record the exclusion should be applied to)
- Table: select “Incident” [table_name field that specifies the table to exclude the action.]
- 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]
- 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]
- View: Service Operations Workspace [reference field to a UI View (sys_ui_view) record that specifies the view under which the action is excluded.]
- Note, you are required to choose a table or a view in order to save an Action Exclusion record.
- 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, then the 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 action model. 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
- Navigate to List Actions and create a new action, as follows, and save the record:
- Action label: My Assign to Me
- Action name: my_assign_to_me
- Implemented as: Server Script
- Table: Incident
- Under Advanced View, enable the Record Selection Required and Experience Restricted fields
- Navigate to the Conditions tab and set Enable Dynamic Conditions to true
- Fill the Dynamic Script Condition field as:
current.active && current.assigned_to.canWrite() - Add a new condition in the Dynamic Record Conditions condition builder that the Incident record must have priority of 5 - Planning
- 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(); } - 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.
- Open Incidents in your workspace. Verify that the newly created action is there, but it is disabled.
- 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.
