BACKGROUND

Enterprises use enterprise mobility management (“EMM”) systems to manage which applications can access work files and how those applications operate on enterprise-owned, or otherwise EMM system-enrolled, devices utilized by enterprise members (“users”). However, these applications can use different services for receiving and transmitting notifications. Often, the services employed for those purposes are not under the control of an EMM system. Further, the EMM system cannot assume availability of a notification push platform. As a result, this can place notifications outside of the enterprise's management and control, and add to uncertainty regarding whether the proper notifications are reaching users.

For similar reasons, enterprises have very little flexibility over which notifications are sent to users. It is therefore common for enterprises to be limited to using pre-defined notifications that are native to particular applications, despite their ineffectiveness relative to other types of notification that would be beneficial to the enterprise.

Users are also inundated by notifications from various applications. To compound this issue, enterprises have little control over which notifications take precedence. In fact, enterprises may not even know which personal applications a user has installed on their user device. These other applications can issue any number of notifications that cause notifications from managed enterprise applications to get overlooked or buried.

Therefore, a need exists for a notification platform that can be managed by an enterprise.

SUMMARY

Examples described herein include systems and methods for a notifications platform that can be managed in an EMM system. A notifications service can execute and receive notifications from external unmanaged applications and internal managed applications. The notifications can be stored and prioritized in an example. An administrative console can allow an administrator to whitelist or blacklist different types of notifications and control which types of notifications are presented to users. The lists can be tenant specific. In one example, the lists can be used to prioritize notifications. For example, notifications having a minimum priority threshold that are for a managed enterprise application can be displayed above notifications for an unmanaged application. The console can give administrators control over which notifications, managed or unmanaged, are prioritized for display to users.

In one example, the notifications can include a tenant identifier and a user identifier. The tenant identifier can allow a management server to retrieve tenant-specific preferences (e.g., blacklists) for how notifications are prioritized and displayed on a user device. The user identifier can identify which user for that tenant will receive the notification. A load balancer can create additional instances of the notification service as workload demands.

In some examples, a notification builder tool can be provided in a graphical user interface (“GUI”). The notification builder tool can be part of an administrative console that includes options for creating notifications and managing which notifications are sent to users. The notification builder tool can include options for creating notifications, including a definition option and a content creation option, for example. The definition option can define parameters of a notification. For example, the definition option can include options for naming a notification, selecting recipients of the notification, and selecting a priority of the notification. The content creation option can include options for building the notification from a predefined or a custom template, as well as fields for providing the content to be displayed in the notification. The content creation option can also include a preview window that displays how the notification will appear. The preview window can be updated in real-time as the notification content is created.

In one example, a content creation option can also include an action button creation tool. The action button creation tool can allow a user, such as an administrator in an enterprise organization, to create an action button that can be included in a notification. The action button creation tool can, as an example, provide fields for text to be displayed on the button before and after the button is interacted with by a user. The behavior type of the action button can also be included. Examples of behavior types can include “Open In”, application programming interface (“API”), and “API with Parameters.” In an example, “Open In” can direct the user to a web page upon the user's selection of the action button, “API” initiates an API call based on default configurations when a user interacts with the action button, and “API with Parameters” initiates an API call when a user interacts with the action button according to additional custom parameters defined by the administrator. The GUI can also provide options to select a method and API endpoint. In an example, the GUI can provide an option to make the action repeatable. In another example, the GUI can provide an option to place the action button in a different position in the notification than the predefined position.

Creating a notification can cause the notification to be sent to selected user devices. A GUI can include a dashboard page that allows an administrator to view the status of created notifications. The GUI can also provide information relating to which selected users have viewed or interacted with the notification.

In some examples, a console can include options for prioritizing both custom and non-custom notifications. An administrator can set a priority level of notification types. An API can include a code representing priority with a notification when it is sent to a user device. The user device can then prioritize a display of the notification accordingly. In one example, a highest priority level application can require a user to respond to the notification prior to lower level notifications being displayed. This can ensure important work-related notifications are dealt with prior to notifications for unmanaged applications.

The examples summarized above can each be incorporated into a non-transitory, computer-readable medium having instructions that, when executed by a processor associated with a computing device, cause the processor to perform the stages described. Additionally, the example methods summarized above can each be implemented in a system including, for example, a memory storage and a computing device having a processor that executes instructions to carry out the stages described.

Both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the examples, as claimed.

