Customizing UI actions for the Now Mobile Agent application
Summarize
Summary of Customizing UI actions for the Now Mobile Agent application
Enhance user efficiency in the Field Service mobile application by creating custom UI actions. Unlike the desktop version, mobile UI action conditions do not execute database queries, conserving mobile resources. Administrators can enable or disable UI actions explicitly, improving performance by removing unused actions.
Show less
Key Features
- Custom UI actions can be configured without database queries, reducing resource consumption.
- Administrators can review and disable unused mobile UI actions to optimize performance.
- UI action conditions must be adapted for mobile, maintaining essential checks like state and assignment.
Key Outcomes
By customizing UI actions, ServiceNow customers can streamline mobile operations, allowing users to efficiently manage tasks. This configuration leads to faster response times and a more tailored experience for field service agents, ultimately improving service delivery.
Make it easier for your end users to get things done faster with the Field Service mobile application by creating custom UI actions.
The configurations for UI action conditions are different in Field Service mobile applications than those in the desktop application. Unlike the desktop application, the UI action conditions on mobile do not execute any database queries and therefore do not take up mobile resources. On the mobile application, instead of performing a system check on whether a Field Service configuration is enabled or disabled, you can explicitly configure the button to be active or inactive.
As an administrator, you can review the mobile UI actions and disable the ones that are not being used to use less mobile resources.
The image below shows the Field Service Mobile application open in Studio. This is where you can configure UI actions.
current.state == 16 && (new StateFlow().validFlow(current, '53d0aea8d7230100fceaa6859e610326', 'manual'));- The
SMconfigurationrecord to see if the accept_reject UI action is enabled or disabled using this script:(new sn_sm.SMConfiguration()).isEnabled(current, "accept_reject", false) - If the task has been self-assigned
- Do not change the
current.state == 16condition. It checks for information on the current record. - If this
condition:
is set to false, drop this condition and disable the corresponding mobile UI actions on the mobile application.(new sn_sm.SMConfiguration()).isEnabled(current, "accept_reject", false) - Set the value for the current tasks assigned to field parameter
to the logged in user as shown here:
current.assigned_to == gs.getUserID()
current.state == 16 && current.assigned_to == gs.getUserID()Here is another sample configuration for self-assigning a task.
(new SMTask()).canAssignToSelf(current)SMTask.canAssignToSelf(task) script include method performs a system
check for these conditions:- State of the task
- Value of the scheduled start time
- If the task has been self-assigned
- If the user has the basic and agent roles as defined in the SM Configuration record
- Whether the user is part of a group handled by the task dispatch group
current.assigned_to != gs.getUserID() && !(current.expected_start.nil()) && (current.state == 10 || current.state == 16)
For the fourth condition, you can add a specific role to the Roles
field.wot_assign_to_me write-back action
item:if (smTask.canAssignToSelf(wotGR))
smTask.assignToMe(gs.getUserID(), input.sys_id);
else
gs.addErrorMessage(gs.getMessage("Not a valid task assignment."));