Communications Product Description
This document gives an overview of the ONE product. The ONE product is updated frequently, so specific features and visuals may be different in the released software. ONE is a broad platform capable of handling many use cases. Part of the value proposition of ONE is that new use cases can be implemented for specific customers within ONE while not affecting the rest of the customer base. Correspondingly, this document focuses on describing ONE as a platform versus documenting every feature.
ONE is an enterprise mobility solution. The platform provides a secure and flexible architecture to provide mobile capabilities based on both cloud and on-premises backend systems, as well as supporting use cases solely from the capabilities of the platform (e.g. internal communications, chat, etc). Some customers may solely use the built-in capabilities and will never see the underlying components (e.g. card apps).
The platform is designed to handle two different classes of use cases (card app and micro app). Card app use cases involve data coming from Limeade systems, backend systems or authored from the ONE Communications content creation UI to be stored in the ONE cloud as cards, which can be delivered rapidly to the users. These tend to be activities, social posts, news items, requests to approve a workflow, etc. For card app use cases, these are the main components involved.
- ONE client – a native app running on iOS or Android p
- ONE cloud platform – directs authentication flows, runs card apps, provides connections to other platforms, stores data
- Card app – code that performs the specific tasks of processing data and creating the view of that data to present in the client (as well as enabling any responses)
- Authentication service (IDP) – authenticates the user prior to accessing the cloud platform with the ONE client
- Backend system – is the authoritative system for the business data, provides the source of data to present to users in cards and receives actions (e.g. approving a travel request)
For micro-app use cases, most of the components are identical. The only difference is that the user initiates the flow from their phone and the data is not pre-cached in the cloud (for example, a user could open a search UI within the client, enter a search string, and submit that to SharePoint's search functionality). The micro-app, in this case, provides the definition of the initial UI, the logic to send the search string to the SharePoint search endpoint and the processing to handle the results and format them to the ONE client to display.
Card apps and micro-apps are a mixture of UI formatting instructions along with actual code to process requests. Both card apps and micro-apps can be added to the ONE platform and assigned to users based on group assignments. The ONE platform does not provide any kind of browsing or general remote access functionality. All use cases are explicitly enabled by the specific definition of a card or micro-app and the deployment and assignment of those apps.
The final component of the overall the ONE platform is AppBuilder. AppBuilder is a plugin for Microsoft Visual Studio which allows creation of card apps and micro-apps. Typically, customers do not make use of this tool during the initial phase of deployment. If access to this tool and permission to publish new apps is granted to any employee, then new app needs to go through internal review prior to development and publishing.
At a physical level, the ONE cloud platform runs in multiple Microsoft Azure data centers around the globe. The specific data centers in operation at any given moment can vary, but typically Western Europe, the US, APAC and Australia are in operation. Azure traffic manager automatically routes requests to the nearest data center. Azure database replication automatically copies data among the data centers. Within a given data center, the ONE platform is composed of multiple roles/processes (e.g. receive web requests, process data into cards, etc). This allows automatic scaling both by increasing the capacity of the virtual instance as well as by spawning more instances of a role/process.
The diagram below shows a high-level view of how the ONE platform operates.
A customer may choose to run a ONE Hub to access on-premises systems if they have use cases to integrate with on-premises systems (see upper-right box). This is a Windows service and a SQL Server database running on customer hardware within the customer environment (it is not part of the ONE cloud platform, but it provides secure communication through the Microsoft Service Bus technology).
The client applications (the ONE app on the user’s phone) and the hub connect to the ONE cloud platform through Microsoft’s Azure Traffic Manager service. This serves the purpose of routing traffic to the appropriate Azure facility based on the geographical location from which the request emanates. This service also ensures that traffic is only sent to Azure datacenters that are online (in the unlikely case that an Azure data center is unavailable) which gives global fault tolerance.
Requests are processed by Azure web roles and Azure worker roles are invoked as necessary to fulfill requests. Azure can instantiate and retire instances of roles or scale instance capacity as needed to meet the load.
Read operations are performed from a local database. A primary database is designated within one of Azure data centers. All write operations (recording usage statistics, storing user feedback such as a like action on cloud-based corporate communications, etc.) are made to the primary database. The primary database is automatically replicated to the other datacenters using Azure database replication. Currently, the Azure West US facility houses the primary database and West Europe is the designated failover location to become primary if West US is unavailable.
Authentication services can be performed by the built-in ONE service or (more typically for larger customers) via the customer’s identity provider (ADFS, Ping, etc). The authentication servers only connect to the primary SQL server.
Depending on specific authentication provider used by customer or customer request, authentication may pass through ONE’s federated gateway infrastructure. All customers using ADFS for authentication will use federated gateway no later than November of 2018 (when Microsoft is no longer supporting ACS).
ONE is an extremely flexible platform that can handle a wide variety of use cases. This section deals with the concepts of authentication, key objects, data collection and distribution and data updates.
Before a user is able to participate, authentication to the ONE cloud platform is the first step. The general flow of authentication is that the cloud platform will direct the user to the appropriate authentication service (AzureAD, ADFS, PING, etc). If a customer does not have an authentication service, ONE includes a service as part of the ONE platform. After a user successfully passes authentication, they are redirected to the ONE cloud platform. The user may now perform actions with the ONE cloud such as requesting cards to display in the productivity stream in the client. The characteristics of this login session (token duration, whether the token can be refreshed, etc) are typically determined by the service which authenticated the user.
Some other actions such as interacting with certain backend systems may require additional authentication. In some of these situations, a delegated authentication or a system credential may be possible. In other situations, the user may need to enter credentials for accessing the backend system and ONE will securely store those credentials in a hub to only be used when necessary.
In addition to users, there are a few other key objects in the ONE platform. A tenant is a customer company. All customer data is connected to their tenant by a tenant ID. Within a tenant, users are grouped into roles. The roles provide a mechanism to assign different functionality (micro-apps and card-apps) to different users. A theme is a UI definition that controls the look and feel inside the ONE client experience. As mentioned in the overview, micro-apps and card-apps are a mixture of logic and UI control that deliver a specific use case. Groups are lists of users who can receive cards (groups may also be used to enable specific functionality to limited audiences such as rolling out chat to only some of the users). The Cloud Comms capability uses channels in addition to groups to determine which messages go to which users. Permissions are implemented at both the tenant level and within Cloud Comms to control the specific actions available to specific users. More information on key objects and administration can be found here:
Data comes into the ONE cloud platform for presentation as cards in one of two basic paths:
- The data is authored directly in the Cloud Comms functionality within ONE
- The data is collected from a backend system and transported to ONE
The Cloud Comms functionality in ONE is a complete authoring and message distribution platform. Within Cloud Comms, users can craft a message with text, image, link, etc. Certain controls and behaviors can be enabled for every individual message (e.g. send a push notification, allow the card message to be shared on social media). All of this data is added or uploaded by the author and results in cards, which are stored encrypted and sent to the right user when she logs in to the client. More details on Cloud Comms can be found here:
Cards can also be created from data that comes from backend systems. An SAP system might generate purchase order approval cards. A SharePoint system might generate cards from an issue tracking list. ONE has some pre-built collectors for gathering up the required data and getting it to the ONE cloud. Incoming card data to ONE is handled by a web role that places it temporarily in a queue so that a card processor job can work through the data to create cards. These cards are stored encrypted and sent to end-users when they log in. Customers can determine whether or not card data is sent to the search service for indexing, so that end users can find cards by searching in the clients.
Below is a simple illustration of the concept of data from backend systems creating cards.
In this particular example, a ONE service collector gathers appropriate data and send it to the ONE cloud for processing as cards. The user on the mobile client receives all the available cards when logging in or refreshing the productivity stream, but these user actions do not generate a request that goes all the way to the backend system.
Users can, however, create requests or updates that go to backend systems by either interacting with controls on a card or interacting with micro-apps. In these cases, the web role in the ONE cloud receives the request. The appropriate code for the relevant card-app or micro-app is invoked in the cloud. The request is then turned into a call that goes through an appropriate path to reach the desired backend system (e.g. through the secure tunnel created by the hub in the picture above). If necessary, credentials are retrieved from the hub to authenticate with the backend system. The result can be anything from a simple approve message for a purchase order, to a search query, to creating a new entry in a SharePoint list along with hundreds of other examples. In some cases, the backend system will produce a response (such as providing search results from a query) and this is returned securely all the way back to the client. In all of these cases, the data is not stored in the cloud or on the client.
End-users will largely experience ONE through client applications. Currently, ONE ships native applications for iOS and Android. ONE also provides an HTML interface for end-users. Within a client, the user experience will be primarily dictated by the card-apps and micro-apps assigned. This is an example screenshot from an Android client.
In this example, the user is on the main view of the productivity stream labeled Hub. In this stream, a card that was authored with the Communications capability is displayed. A user can interact with this particular card to like or enter a comment as is shown on the next screenshot.
A different user may have totally different cards based on roles, groups, channels selected, and so forth. Those cards may have totally different content and types of controls. Cards that are specifically designated as tasks (typically those which require a response from the user) can be filtered out of the general stream by clicking on the Tasks tab.
The Services tab gives the user access to the micro-apps that have been assigned to her role.
Each of these icons represents a different use case. Just like with cards, different users can have totally different micro-apps available in their Services tab.
Users have the ability manage their profile by tapping the profile picture icon at the top right allowing the user to view their published content, edit their profile picture and properties and edit their settings by tapping the Settings icon.
This screen lets users upload a profile picture, turn on and off push notifications, and potentially enter credentials to be stored in the hub for accessing additional systems.
Each client has a user experience designed to be consistent with its specific operating system. Because client apps update frequently, the best reference for client capabilities and experience are the publically available ONE apps in the respective app stores.
This section focuses on the supported operating systems and conditions for different elements of the ONE platform. This information will continue to be updated, so customers should always check the latest posted version online. Limeade may make changes in supported operating systems and in supporting specific parts of the ONE platform. Limeade will give customers as much notice as is realistically possible for any end of support scenario.
While ONE may work with other browsers, these are the supported options for the HTML client and HTML administrative interfaces.
- Chrome: (Current -1) and Current
- Edge: (Current -1) and Current
- Firefox: (Current -1) and Current
- Internet Explorer: 11+
ONE currently provides native ONE apps for iOS and Android.
iOS 11.0 and up. Device minimum is iPhone 5s, iPad 5th gen, iPad Mini 2 and up. There is not a version of the app designed specifically for iPad layout.
OS version 5.X (Lollipop) and up. While no devices are explicitly declined, there is a lot of variance in Android devices – please contact Limeade if there are questions about a specific device. There is not a version of the app designed for tablets.
The ONE Hub is only needed for scenarios where a customer is connecting with on-premises backend systems. In those cases, the Hub service needs to be installed on a server with one of the following operating systems.
Windows Server 2012 or later
The server must have .NET Framework 4.7.1 (Full Installation), and the Hub requires a SQL Server (version 2008 or higher) database.
AppBuilder is a tool for creating micro-apps and card apps that run within ONE. AppBuilder is installed as a plugin within Visual Studio and requires version 2015 or higher.
ONE has several integration capabilities. Some of these like the REST or SQL integrations are generalized. Some integrations are built with specific target platforms and corresponding requirements. Please reach out to Limeade to get full list.
The ONE administrative UI allows defining localized labels for parts of the user experience (e.g. the name of a micro-app in the Services tab). The platform supports content being sent in any language (e.g. a card can have a message in French, Japanese, etc). The ONE native clients and the ONE administrative web interface ship with both English, German and French translations.