User role permissions in mobile apps

  • Release version: Australia
  • Updated March 12, 2026
  • 3 minutes to read
  • Summarize
    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

    This document outlines how to control the visibility of mobile app components by applying user role permissions. User roles dictate which components are accessible to specific groups, enhancing security and user experience within the app.

    Show full answer Show less

    Key Features

    • Role Assignments: The admin role grants access to all components, and roles can be nested to extend permissions to all users linked to a role.
    • Dynamic Role Management: Adjust user roles based on departmental changes, ensuring users only access relevant data (e.g., transitioning from sales to finance).
    • Component Support: User roles are applicable in Native Client, screens, launcher screens, UI sections, and functions, allowing for granular access control.
    • Access Restrictions: Limit user access to applications and specific screens based on assigned roles, such as preventing ITSM users from accessing FSM applications.
    • Function Limitations: Control specific actions users can perform within the app, enhancing security by limiting capabilities based on role (e.g., restricting incident reassignment).

    General Guidelines

    • Utilize user roles for segmentation based on user skills and definitions, while user criteria should be used for factors like location and department.
    • When possible, prioritize user roles over user criteria to streamline operations and improve responsiveness.
    • User roles are effective even in offline modes, ensuring continued access control regardless of connectivity.

    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.

    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.
    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.
    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.
    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.

    General guidelines for using user roles

    • 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.
    • 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.