---
sourceDocument: Yokohama Field Service Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/field-service-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Field Service Management

ft:clusterId :

    - fsm

bundleId :

    - fsm

workflow :

    - Customer and Industry


---

# Customizing UI actions for the Now Mobile Agent application

# Customizing UI actions for the Now Mobile Agent application {#ariaid-title1}

Release version: Yokohama  
Updated January 30, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Customizing UI actions for the Now Mobile Agent application

The Now Mobile Agent application allows administrators to create and customize UI actions specifically tailored for mobile users of the Field Service mobile app.
These custom UI actions help end users complete tasks more efficiently on mobile devices by optimizing conditions to use fewer mobile resources compared to the desktop application.
Show full answer Show less  

## Key Features

* **Mobile-specific UI action conditions:** Unlike the desktop version, UI action conditions on mobile do not execute database queries, reducing resource usage on mobile devices.
* **Active/Inactive button configuration:** Buttons can be configured to be active or inactive based on mobile-friendly conditions rather than complex system checks.
* **Administrative control:** Administrators can review and disable unused mobile UI actions to further conserve mobile resources.
* **Studio configuration:** UI actions for the Now Mobile Agent app are customized within Studio, providing a centralized environment for editing mobile UI actions.

## Practical Guidance for Customizing UI Actions

* **Work order task acceptance:** For the Accept button, retain the condition `current.state == 16` to check the record state. Remove desktop-specific system checks (e.g., `(new snsm.SMConfiguration()).isEnabled(...)`) and instead disable the corresponding mobile UI action if the feature is disabled.
* **Assignment condition:** Add the condition `current.assignedto == gs.getUserID()` to ensure the button is active only when the task is assigned to the logged-in user.
* **Self-assigning tasks:** Replace the desktop script include check `(new SMTask()).canAssignToSelf(current)` with mobile-friendly conditions such as `current.assignedto != gs.getUserID()`, task having a scheduled start time, and state being 10 or 16.
* **Role validation:** For role-based checks, assign roles via the UI action's Roles field instead of script-based system checks.
* **Dispatch group validation:** Perform dispatch group validations in the write-back action script, using methods like `smTask.canAssignToSelf(wotGR)` to allow or deny assignment with appropriate error messaging.

## Key Outcomes

* Improved performance and responsiveness of UI actions on mobile devices by minimizing resource-intensive checks.
* Greater control for administrators to tailor mobile UI actions based on mobile-specific logic and user roles.
* Enhanced user experience for Field Service mobile users through relevant and conditionally active action buttons.
* Consistent behavior aligned with desktop functionality while optimizing for mobile constraints.  
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 don't execute any database
queries and therefore don't take up mobile resources. On the mobile application, instead of performing a system check on whether a Field Service configuration is enabled, you can configure the button to be active or inactive.

As an administrator, you can review the mobile UI actions and disable the ones that aren't being used to use less mobile resources.

The following image shows the Now Mobile Agent application open in Studio. The Now Mobile Agent application open in Studio is where you can configure UI actions.

Here's a sample UI action configuration for accepting a work order task.  
The Accept button on the desktop application has the following UI action conditions:

    current.state == 16 && (new StateFlow().validFlow(current, '53d0aea8d7230100fceaa6859e610326', 'manual'));

The system checks these state flow conditions:

1. The `SMconfiguration` record to see if the accept_reject UI action is enabled or disabled using this script:

       (new sn_sm.SMConfiguration()).isEnabled(current, "accept_reject", false)

2. If the task has been self-assigned
{#configure-uiaction-fsm-mobile__ol_lgj_dxh_2gb}  
To modify the UI action for the corresponding button on your mobile device:

1. Don't change the `current.state == 16` condition. It checks for information on the current record.
2. If this condition:

       (new sn_sm.SMConfiguration()).isEnabled(current, "accept_reject", false)

   is set to false, drop this condition and disable the corresponding mobile UI actions on the mobile application.
3. Set the value for the current tasks assigned to field parameter to the logged-in user as shown here: `current.assigned_to == gs.getUserID()`

{#configure-uiaction-fsm-mobile__ol_grr_fxh_2gb}Based on the preceding example, here's the modified condition for the UI action in the mobile application:

    current.state == 16 && current.assigned_to == gs.getUserID()

Here's another sample configuration for self-assigning a task.  
The Assign to Me function on the desktop application has the following UI action conditions:

    (new SMTask()).canAssignToSelf(current)

The `SMTask.canAssignToSelf(task)` script include method performs a system check for these conditions:

1. State of the task
2. Value of the scheduled start time
3. If the task has been self-assigned
4. If the user has the basic and agent roles as defined in the SM Configuration record
5. Whether the user is part of a group handled by the task dispatch group
{#configure-uiaction-fsm-mobile__ol_ffw_scj_2gb}  
On the mobile application, the following UI script condition performs a check for the first three conditions listed before:

    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.  
For the fifth condition, perform the following validation in the `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."));