At a company as large and as complex as Uber, the volume of internal communication can easily become overwhelming. Our employees use multiple independent systems to send and receive a variety of notifications every single day. These include:

Thus employees receive several action items and approval requests from multiple applications on a daily basis. Unified Action Platform or uAct has been built with a view to help employees keep on top of their assigned tasks and action items. uAct aggregates all such requests into one place for employees to easily view and address. 

Employees go through several applications every day to submit, track, and approve requests. Notifications are sent to request approvers via email. These can easily be lost in a barrage of emails, increasing the turnaround time for requests and a lot of follow-ups! This results in delays, breaches of deadlines, or compliance issues for the company. 

At Uber, we typically have regular notifications generated from at least 20 systems, thus making it difficult to manage the enormous volume of requests. Currently, there is no way to view all pending requests in one place.

uAct was created with the objective to:

uAct aggregates pending actions/ approvals/ requests from multiple applications in two ways:

In order to render requests in the UI, the Request Provider pulls requests from real-time source applications and merges it with the relevant requests from the offline-ingested Requests Store. 

There are 2 main views in uAct’s user interface:

uAct’s UI allows users to save their default view preferences. These user preferences are saved in the User Preferences Store. 

Based on the APIs provided by the source applications, users can act on the requests they see in two ways: 

uAct incrementally onboards new source applications each with multiple configurations. These are maintained in the Config Store (deployed independently and changed dynamically). It contains configuration details like whether the application is enabled for that user; what actions are allowed for this application, whether data is ingested offline or needs to be fetched in real-time, timeout values, etc. 

Experimentation or rollout of features is controlled via Flipr. Flipr creates a feature flag that helps in the rollout of features to a specific set of users, toggling features on/off, etc.

uAct has analytics, insights, alerting, and monitoring mechanisms for debugging issues. Multiple metrics from UI and backend for errors and insights are captured, which is managed via a central observability platform. Failure metrics have been set up to instantly detect and alert on issues. Grafana^® dashboards are also created on top of these metrics for analytics and insights. uAct UI has been integrated with Google Analytics to track the number of active users, click events, and other behavioral insights from end users.

The backend of uAct uses the Onion architecture. It provides loose coupling and high cohesion, thus helping in easy integration with new source applications.

A brief description of its components is as follows:

Currently uAct integrates with 10+ source applications; it is anticipated that with time this number will only increase many times over. Despite this, the application should remain highly performant, scalable, and with low latency for end users. uAct follows a hybrid architecture so that it can cater to different latencies and interfaces offered by the source applications. 

If the source application provides a direct interface to pull data at the user level, and the API latency is within permissible limits, then uAct fetches requests at run time. To limit the latencies further, uAct parallelizes requests at the application level and also employs pagination. This way multiple pages of data are fetched at the same time. The getAction API requests fan-out at multiple levels with strict timeouts. This ensures degradation in any application does not impact the overall experience of users. 

Each source application sends requests to uAct with its own set of fields. So, the main focus in design was to make the request structure consistent and uniform. To solve this problem, uAct only stores fields that are common across source applications, at the schema level. The remaining fields are in a variable-sized JSON object referred to as RequestMetadata. RequestMetadata is converted to a string for efficient storage, retrieval, and transfer.

The request schema:

uAct UI provides flexibility in parsing RequestMetaData. It uses a custom parser to parse application-specific information in the common request card component. As shown below in the first image, Product, Request Level, and Description are populated whereas in the second image Report ID, Last Modified, Last comment, and Country are populated in the same request card component.

Each source application has its own architecture/framework/protocol. Below are some diverse patterns that uAct deals with:

To handle this uAct uses Apache Camel framework, which implements Enterprise Integration Patterns and helps in easy integration with various applications. It provides a rich library of components to interact with other applications out of the box. It allows the creation of new custom components and their associated routes. The routes are invokable via HTTP endpoints as REST service. Apache Camel routes provide cron job schedules to handle long-running jobs. 

Each uAct route does the following:

uAct provides personalization ensuring its UI performance does not degrade. In the future, uAct will support enabling/disabling the visibility of any source application as part of user preference. The getRequest API call has to be sequential to the personalization API call so it should be low latency.

uAct uses CacheFront to store user preferences. CacheFront is an Uber internal integrated caching solution. It is a transparent caching layer on top of Docstore, which eliminates the need to interact with both cache and storage. It provides low-latency reads and writes while abstracting the caching complexity.

In today’s highly changing tech landscape, new applications are added to the enterprise ecosystem quite frequently. uAct needs to be able to onboard these newer applications seamlessly with minimal or no changes to its existing schema and backend. 

As per the design shown in Figure 3, uAct uses Handler, Controller, Orchestrator, Mapper, and Client layer in sequence.

uAct opted for a design where new applications do not interact at the handler or controller layer. Depending on the type of ingestion being used for a source application, uAct onboards via the following approaches: 

The aim of uAct is to minimize the number of clicks and redirects to different platforms. However, few applications do not allow third-party integrations with their application for actions due to technical and security constraints. For such applications, uAct leverages iFrames to support the actions.

iFrame stands for a nested window on the existing window as shown in the image above. iFrame loads the application’s request page without the need of redirecting the user to a new tab. Enabling iFrames is not straightforward as content security policy prohibits the rendering of external web pages on any website. Also, the uAct domain should be whitelisted in the frame-ancestors of the source application.

Email IDs are used as the unique identifiers of approvers and/or requestors of the requests in most applications. Users can make more informed decisions on the requests in uAct if they could see more details about the requestor, such as name, profile picture, link to Whober (Uber’s employee directory), etc. The main challenge with this requirement was to ensure users aren’t impacted in case of degradation or failure of profile enrichment API. 

In order to solve this problem, uAct decouples the main user request from the profile enrichment flow. Initially, the UI loads the requests without the user profile information. The email IDs of all the employees involved in the requests are collected. The extra requester information is loaded lazily in the background, simultaneously for all requests on the page. Refer to the GIF shown below. 

This way, the user can continue with other activities on the platform even while the profile details are loading. In case the call to fetch employees’ information fails, the UI does not break and shows only the employee’s email. Refer to the GIF below where the employee’s profile image is not rendered and the UI shows a default thumbnail in blue. 

uAct serves as the centralized platform for actions from multiple applications and it contains personal data that should not be accessible to any other user. Hence it becomes vital to have authentication and authorization for handling user data. 

The uAct UI application is managed via company-wide centralized authentication (Onelogin Auth) so only Uber employees can access it. uAct platform also provides an additional layer of authentication and authorization on the backend service. Any call to the backend service passes via Identity and Access Management (IAM) which ensures the user can access only authorized data. For debugging purposes, the admin role for the development team has been defined. All admin activities are getting traced in IAM. 

It is crucial to maintain an audit history for all the actions taken within uAct by users. Actions could be pertaining to important HR requests, systems/application access, etc., which need to be audit logged for legal and compliance reasons. Users can also view all these actions in a dedicated view in the UI.

A majority of pending requests are on direct managers or skip managers. uAct provides a ready filter to view requests from direct and roll-down reports (i.e., My report’s team: skip manager view). uAct maintains the same privacy and confidentiality as on the source applications. Hence managers and skip managers see only those requests that have them in the approval chain.

uAct UI provides the flexibility for users to create their own default view filtering source applications or requesters of their choice.  The platform stores and renders a customized default view to each user.

Users can clean up the clutter in their view by hiding the requests they don’t want to see in uAct. This does not delete the request from uAct or the source application, but only hides it from the UI. The user can easily view such “hidden” requests in a separate view and can opt to “unhide” these when needed.

Now that we have successfully implemented uAct across Uber, achieving our goal of unifying our myriad internal notification systems into a single, convenient platform, here are some of our planned initiatives to upgrade it further:

Leveraging the existing orchestration framework, newer source applications will be integrated with uAct, such as PagerDuty, Jira, GitHub, Coupa, Concur, DocuSign, Asana, ServiceNow, Charter policy, and many more.  

uAct platform will integrate with Slack for notifications. Users will be notified over Slack whenever any new request is assigned to them. Additionally, users will be able to change their notification preferences such as frequency, include/ exclude notifications for certain source applications, etc.

uAct platform will email a consolidated daily or weekly digest/report of all their incoming requests. 

The nudging feature will allow users to send reminders to approvers in order to expedite the action on the request. This will push the request to the top of the list of the approver, so they don’t miss it. In case there is no action on a pending request, requestors can escalate a request to the approvers’ manager. 

With this feature, uAct will allow moderators to create company-wide actionable announcements such as taking annual company surveys, undertaking mandatory security-related tasks, etc. Moderators would be able to schedule posting these announcements, select target audience, and view analytics on it too (number of views/clicks). 

uAct will have the capability to create both personal and shareable action items. Users can create action items for teammates and utilize uAct to track and follow up on such items.