What is a hybrid application? How to build a hybrid app without code

Hybrid apps are having a moment. We’ll start by explaining the concept of both an “app” and a “hybrid app.” Then we’ll show you how to create hybrid apps using the Openprise RevOps Automation Platform, along with two real-life examples.

If There’s an App for Everything, Why Hybrid Apps?

Even in this age of “There’s an app for that!” companies still find themselves in situations where they can’t easily automate certain processes given what’s on hand. So they’re faced with the following choices:

Waiting for a technology vendor to add it as a new feature and limp along with a manual process
Hacking together a process using multiple systems and dealing with the manageability nightmare when business requirements constantly change
Writing a custom app and taking on the burden of maintaining custom code while meeting all the required security and privacy compliance mandates

None of these options are appetizing. Hacking a piecemeal solution or writing your own code can create more problems than it solves. And hoping a vendor will come up with the right solution for you sometime in the future is not exactly a viable strategy.

There’s a fourth option. Consider creating hybrid applications (hybrid apps) using the Openprise RevOps Automation Platform—all without writing a single line of code.

What’s an App?

An “app” is basically a piece of software that does something. A business app is usually an app that automates or manages a set of business data and processes. The modern use of the word “app” also implies a relatively lightweight and simple software application, not a large piece of flexible enterprise software, which usually gets labeled as “system” or “platform.” The emergence of mobile platforms like iOS and Android, as well as Software-as-a-Service, has created an app revolution where the number of apps has exploded, leading to the saying, “There’s an app for that!”

Any app usually has three layers in its architecture: data, logic, and user interface (UI). A normal app delivers these three layers as a single package, like an app you can download from your App Store, or a SaaS application you can subscribe to. If you’re going to build an app, you’ll need to decide how to store the data, how to code the logic, and select a UI technology.

What’s a Hybrid App?

A “hybrid app” is where the three layers of UI-logic-data are distributed across multiple platforms and systems, but the app behaves like it’s a single app.

The Openprise RevOps Automation Platform makes it simple to create these hybrid apps so you can add critical missing functionality to your favorite business systems/platforms without writing custom code.

The best way to illustrate this is with a few real-world examples.

Hybrid App Example: A Lead Routing App for CRM

Routing a lead to a sales rep and assigning an account to a territory is a universal need for every sales organization. Customer Relationship Management (CRM) platforms all have some routing capability. This usually consists of a basic rule-based feature that works fine for the simplest of scenarios, then quickly becomes unmanageable when the routing requirement becomes more complex. For most medium to large enterprises, these routing rules are never sufficient, so custom coding is a last resort. For example, Salesforce offers a basic routing rule feature, and for more advanced routing users resort to writing APEX code. Even for companies that buy a dedicated lead routing app, they often find themselves writing custom code, plug-ins, and/or extensions, or worse yet, engage the vendor to develop custom code for that add-on app.

Many Openprise customers, including our own Sales Operations team, have built lead routing, account assignment, and deal registration apps using Openprise, hybrid architecture.

The Data Layer

For this app we’re focused on a lead, a contact, or an account, where the CRM is the system of record. That means the data layer is the CRM. This data is synchronized to Openprise, so data actually resides in both the CRM and Openprise.

To support complex routing logic, other data sets may be required, like Opportunity, Account, Meeting, Event, Campaign Membership, or even custom data objects like Deal Registration. In most cases, the CRM is also the system of record for the supporting data, but it doesn’t have to be. Required data can be aggregated into Openprise from multiple sources, like ERP, marketing automation, helpdesk, product database, or even third-party data providers, so even the data layer can be a hybrid data set on its own. This is especially the case if you’re using Openprise as your Customer Data Platform (CDP). If you’re not familiar with the concept of a CDP or the Openprise Agile CDP solution, you may find this webinar useful.

The Logic Layer

While data can be a hybrid of data from different sources, the logic layer is handled exclusively by Openprise using our orchestration engine. In a typical lead routing process, the Openprise bots would handle tasks like:

Cleaning, standardizing, segmenting, enriching, and validating the lead data
Cleaning, standardizing, segmenting, and enriching account data for matching
Match lead to account
Routing leads using a combination of methods that can include but aren’t limited to:
- Company size, industry, or any profile data
- Geography
- Status or lead source
- Round-robin, load balancing, or shark-tank method
- Service level agreement driven re-routing
Identifying and managing exceptions

Here’s an example of a typical lead routing job in Openprise:

The UI Layer

Not all apps need a UI, but most do. For a hybrid app, the UI can be any number of options inside or outside of Openprise, for example:

A custom object / screen in the CRM
A Google Sheet
A web app from the Openprise App Factory
A Chrome Extension from the Openprise Browser Extension Factory
Any app calling an API from the Openprise API Factory

If an app has different types of users, like end users and administrators, they can use different types of UIs on different platforms to interact with the same Openprise hybrid app. The hybrid approach makes it possible for each type of user to interact with the app from their “native environment,” without requiring the user to learn a new app. Using a native UI like a page in the CRM enables you to leverage any audit and security features already in place in the CRM.

For our lead routing example, you’ll need a UI for the administrator to manage the routing rules— which you can implement as a Google Sheet like this example:

Or as a Salesforce custom object like this example:

To summarize, this hybrid lead routing app consists of:

A data layer by Openprise, CRM, or any other data source
A logic layer by Openprise
A UI layer by CRM, spreadsheet, browser extension, Openprise, or any app capable of calling an AP

Let’s look at one more example.

Hybrid App Example: A New Account Request App

Once Openprise helps a company clean up its account data, the company often wants to keep it clean by no longer allowing salespeople to create accounts directly in the CRM. Instead, they often implement a request and approval process where salespeople submit a request to create a new account, and require that the operations team then vet each request. Many companies resort to using the general IT ticketing system to handle this process. This has two challenges: first it’s a horrible user experience for the sales team, and second it’s a manual process. A better solution is to create a new account request app.

The following shows what a hybrid new account request app would look like at each layer.