---
sourceDocument: Brazil Mobile Configuration and Navigation
sourceDocumentLink: https://www.servicenow.com/docs/r/mobile

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Mobile Configuration and Navigation

ft:clusterId :

    - mobile

bundleId :

    - mobile

workflow :

    - Development, Data and Analytics


---

# User role permissions

# User role permissions in mobile apps {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 User role permissions in mobile apps

ServiceNow enables administrators to control mobile app component visibility by applying user role permissions.
Assigning user roles defines which app components are accessible to specific user groups, ensuring tailored access based on job functions and responsibilities.
Roles can be nested for streamlined management, allowing permission inheritance across related roles.
This setup is essential for aligning app access with organizational changes, such as department transfers.
Show full answer Show less  

## Key Features

* **Role-based Access Control:** Assign roles to users or groups to regulate access to mobile app components.
* **Role Nesting:** Permissions assigned to a role automatically extend to nested roles.
* **Component Coverage:** Roles control access to Native Client, screens, launcher screens, UI sections, and functions within mobile apps.
* **Native Client Restrictions:** Limit app-level functionalities and prevent users from accessing entire applications.
* **Screen and Launcher Screen Permissions:** Restrict access to specific screens or launcher screens based on user roles, such as limiting sensitive data views to managers.
* **UI Section Control:** Permit only designated roles to view specific UI sections within launcher screens, useful for role-specific content delivery.
* **Function-level Restrictions:** Limit actions users can perform, e.g., preventing certain roles from reassigning incidents.
* **Integration with User Criteria:** While roles define access by skill and function, user criteria can be used for segmentation by attributes like location or department.
* **Offline Support:** User roles apply even when users operate offline.

## Practical Application for ServiceNow Customers

By assigning user roles in mobile apps, you can:

* Ensure users see only the components relevant to their responsibilities, enhancing security and user experience.
* Adapt access quickly when users change roles or departments, maintaining appropriate permissions without manual overrides.
* Streamline permissions management by prioritizing user roles over user criteria when both apply, improving system performance.
* Limit access to sensitive UI elements and actions, reducing the risk of unauthorized operations.

Implementing these user role permissions helps maintain compliance, supports operational efficiency, and tailors mobile app interactions to organizational needs.  
Control the visibility of different components of mobile apps by applying user role permissions.
Apply user roles to determine which components are accessible within mobile apps for specific groups of users. The admin role, for instance, enables access to all components. Once a role is assigned, this access extends to all
users or groups linked to that role. Additionally, roles can be nested within other roles, so that any permission assigned to one role automatically applies to any inclusive roles.

For example, if an employee moves from the sales department to the finance department, you can assign them roles that relate to their new position, and remove roles that relate to their former position. This means that the user
no longer has access to the UI sections showing sales data visualizations, and instead has access to the UI sections showing financial data visualizations.  
Note:  
If you don't select user roles for any of these components, any user who has access to the mobile app can see that component. However, users still may not see certain components, as user criteria permissions may be defined.

For a full list of components where you can apply user roles and user criteria, see [Mobile components where user roles and user criteria permissions apply](https://www.servicenow.com/docs/cjXPauuNyBHEp_Fnnbl5vw "Lists of mobile components that can be applied to user roles, user criteria, or to both these access control mechanisms.").

User roles are supported in the following components: Native Client, screens, launcher screen, UI sections, and functions.  

Native Client and applications
:   Limit a user's ability to access certain applications in the mobile app. For example, prevent IT Service Management (ITSM) users from accessing Field Service Management (FSM) applications. Native Client relates to app level functionality and includes components like mobile themes, empty state, navigation bar, geolocation, and offline. You can also define that
    users don't have permission to view an app. For example, you want to prevent agents having access to the Now Mobile app.

Screens
:   Allow only users with specified roles to access screens within your mobile applications. For example, enabling only managers to view user records for all their employees. For more information, see  [Mobile screen types](https://www.servicenow.com/docs/zrZCJVdPvN7Jn0NsaasXaQ "Learn how to use screens in ServiceNow mobile. Use screens to make your mobile app functionality available to your end users.").

Launcher screens
:   Allow only users with specified roles to access launcher screens within your mobile apps. For example, create a launcher screen that only employees with a manager role can see. Additionally, create a launcher screen
    with an employee role that everyone can view. For more information on launcher screens, see [Launcher screens](https://www.servicenow.com/docs/1FM80vqwHNYjCdCY947MhQ "Launcher screens serve as landing pages or home pages. Using a launcher screen, you can access screens in various formats, as well as search, do quick actions, and find user information.").

UI sections
:   Limit a user's ability to access certain UI sections within a launcher screen in the mobile app. For example, assign a development role to certain UI sections, and permit only users with specified development roles to
    view these UI sections. For more information on launcher screen UI sections, see [Launcher screen UI sections](https://www.servicenow.com/docs/NxZekz2Jqcfwl~AqJHNNCQ "UI sections contain the screens, analytics previews, and record information on your launcher screens.").

Functions
:   Only allow users with certain roles to perform specified actions in the app. For example, limit an IT Infrastructure Library (ITIL) user's ability to reassign an incident from a swipe action. For more information on
    limiting user access by role to a specific function, see the steps for creating each function type listed in [Mobile functions](https://www.servicenow.com/docs/S07J7y0Y8OAhp2XABpaP5Q "Configure functions in Mobile App Builder to determine which actions users can perform in the mobile app.").

## General guidelines for using user roles {#sg-roles-permissions__section_bkn_slc_dcc}

* Use user roles if the segmentation is based on the user's skill and role definition. Use user criteria, if the segmentation is based on things like, location, companies, departments, and groups.
* Some components can be associated with both user roles and user components, whereas other components are associated with one access control mechanism. For a list of how the components are associated, see [Mobile components where user roles and user criteria permissions apply](https://www.servicenow.com/docs/cjXPauuNyBHEp_Fnnbl5vw "Lists of mobile components that can be applied to user roles, user criteria, or to both these access control mechanisms.").
* For components where you can assign both user roles and user criteria, prioritize assigning user roles unless there's a specific need otherwise, as this approach streamlines operations and improves system responsiveness.
* User roles are supported in offline.
{#sg-roles-permissions__ul_bsv_tlc_dcc}
* **[Assign mobile user roles permissions](https://www.servicenow.com/docs/XBpCClQV5LxmhhvoY6y4Kg)**   
  Apply user roles to determine which components are accessible within mobile apps for specific groups of users.

