User role permissions in mobile apps
Summarize
Summary of User role permissions in mobile apps
This feature enables ServiceNow customers to control access to various components within mobile apps by assigning user role permissions. Roles determine which parts of the app different users or groups can see and interact with, supporting tailored access based on job function or responsibility. Roles can be nested, allowing hierarchical permission management, and they dynamically adjust access when user roles change.
Show less
Key Features
- Role-based access control: Assign roles to users or groups to restrict or grant access to mobile app components.
- Nested roles: Permissions assigned to one role automatically apply to any roles nested within it.
- Component-level control: User roles can be applied to these mobile components:
- Native Client (app-level features like themes, navigation, offline access)
- Screens (restrict access to specific screens, e.g., managers only)
- Launcher screens (customizable launch points visible only to certain roles)
- UI sections within launcher screens (fine-grained access to UI elements)
- Functions (limit actions users can perform, such as incident reassignment)
- Dynamic role updates: When users change roles (e.g., department moves), their app access updates automatically.
- Priority of roles over user criteria: When both user roles and user criteria apply, user roles should generally be prioritized for efficiency and responsiveness.
- Offline support: Role permissions apply even when using the app offline.
Practical Application
- Prevent users in one function (e.g., ITSM) from accessing unrelated applications (e.g., FSM).
- Limit sensitive screens or data views to managers or specific job roles.
- Create launcher screens tailored to different roles with distinct UI sections.
- Restrict certain functions like incident reassignment to specific roles only.
- Use roles to manage access based on skill and job function, and use user criteria for segmentation by location or department.
Key Outcomes
By implementing user role permissions in mobile apps, ServiceNow customers can ensure secure, role-appropriate access to mobile app content and functions. This improves security, user experience, and operational efficiency by limiting users to only the components and actions relevant to their role, while supporting dynamic role changes and offline use.
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.
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.