What is a Hybrid Application? How to Build a Hybrid App Without Code

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 Data Orchestration 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 Data Orchestration 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 Data Orchestration 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:

Hybrid App Example: A Lead Routing App for CRM

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:

Hybrid App Example: Using Google Sheet to Manage Routing Rules

Or as a Salesforce custom object like this example:

Hybrid App Example: Using Salesforce Custom Object to Manage Routing Rules

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.

The Data Layer

Create a custom object in the CRM called “New Account Request.” This object would contain these types of data fields:

  • Account identifiers that a salesperson needs to provide with each request, like company name, country, DUN Number, and so on.
  • Account data that can be matched or enriched to help with any approval decision
  • Status fields to indicate progress of the request and capture any approval actions
The Logic Layer

The bots in Openprise then take each request and automate the following processes:

  • Cleaning the data
  • Enriching and validating the data
  • Matching against existing CRM accounts
  • Creating or updating the account automatically if there is no uncertainty
  • Flagging the request for human review and action if required
  • Completing the process after human input
  • Updating and marking the request as closed
The UI Layer

The UI can be as basic as the custom object page in the CRM, or more fancy if the CRM offers ways to customize the page with additional features, like analytics. The salesperson can create a new account request and review the status of that request all without leaving the CRM. The sales ops team can perform approval or other manual tasks all within the CRM UI as well.

Parting Thoughts on Building Hybrid Apps

Instead of hacking together different apps to form a fragile solution or write a custom app from scratch, building a hybrid app using Openprise makes it possible to create the solution you need quickly and easily without writing a single line of code. Hybrid apps:

  • Offer a fast time-to-value and easy to update.
  • Require no coding skills
  • Take advantage of native UI to minimize training needs.
  • Use native security, privacy, and audit trail capabilities already in place.
  • Make it easy to deploy and manage multiple apps on a single platform.
  • Leverage the clean and unified data already in place from Openprise.

Leave a comment

This website uses cookies to give you the best experience. Agree by clicking the 'Accept' button.