Composite Apps in Salesforce: Data, Actions, and Users
A long time ago in a galaxy very nearby [Ed. Note: this one], telling people “I build apps” would yield blank stares. Only computer geeks could explain what an “application” was, or how it was distinct from the operating system.
The iPhone and modern app stores changed all that. Nowadays, if I tell people I “make apps,” they think of Facebook or Candy Crush: something on their mobile device not made by Apple or Google. Sometimes I try to explain how it runs inside Salesforce, though I check if their eyes already glazed over.
“OK, but what does that mean?”
If anyone actually wants to know more—and they’re not just being polite, bless their hearts—that means they either work in tech or I’m helping them build an app for Salesforce’s AppExchange. The AppExchange is like Apple’s App Store, but for business. (And, it came first, believe it or not. My colleagues and I at Appiphony were there for the launch.)
These apps run “inside” Salesforce much like Candy Crush runs “on” a smartphone. But many modern apps like DocuSign (highlighted above), Stripe, and Mixpanel have their own infrastructure that processes some key transaction outside of Salesforce’s cloud. Salesforce refers to these as composite apps.
Composite apps have some infrastructure outside Salesforce’s cloud but still connect to the Salesforce platform.
Understanding Composite Apps
That’s a nice dictionary-style definition of a composite app, but it’s not always very illuminating. When discussing a given composite app, we look at the data the app contributes to Salesforce and the actions it enables users to take from within the Salesforce UI. All three are interconnected.
It’s useful to start the conversation with the data: what information will the composite app bring into Salesforce to enrich the 360° view of the customer? Here’s some examples:
- What subscriptions and invoices are associated with this customer? (Sales Cloud)
- Which of our training courses have they taken? (Sales and Service Cloud)
- What financial accounts do they have, whether it’s cash accounts, investments, or insurance policies? (Financial Services Cloud)
- What electronic health data have we measured or observed? (Health Cloud)
The Salesforce platform has a very deep, robust array of tools non-coders can use to solve business problems—but almost all of them rely on structured data. Move the right data into Salesforce, and the world is your oyster.
Data and actions are two sides of the same coin: what does the composite app enable people to do within the Salesforce UI? What might people want to do once they see all this insightful data? So, extending the examples above, employees might:
- Charge a customer’s credit card and create a new subscription
- Enroll a customer in product training based on what they’ve bought
- Open a new bank account or insurance policy
- Refer a patient to another facility to recover after surgery
You can see how each noun implies one or more verbs, and a conversation about information doesn’t get far without touching on action (and vice-versa). I like to think about actions in terms of enabling people to do things they couldn’t have imagined before, becoming the hero of their own story. Give them a light saber so they can save the day in their galaxy.
The users are last on our list, but often the first thing we actually discuss. You want to understand what they’re really struggling with, as well as their behavior patterns and goals. There’s also an interesting technical concern with this type of app: if users can take an action inside Salesforce that flows through to another system, does that person need two different sets of credentials? How can we smooth this over?
We’ve developed several solutions to this, but it’s still something to address.
OK, I understand (sorta). But how do these composite apps work?
Since many apps follow this pattern, there’s a “blueprint” of sorts that they all share:
Most apps are built API First nowadays, so the UI is actually interacting with an intermediate layer instead of manipulating the data directly. This provides the perfect foundation for “rich client” in Salesforce to enable those key actions within Sales Cloud, Service Cloud, and more. The API allows different end-user UI apps (e.g. iOS, Android, and Salesforce) to all share the same data access layer.
Our Shortcut: the Strike tool set
The pattern is so common we extracted the reusable parts into a code framework called Strike to build these “rich client” apps quickly.
This way, we don’t reinvent the wheel or waste time on undifferentiated plumbing. So if you’re interested in a composite app like this, or you’re working with someone who is, we’d love to talk to you. We’re proud to say we’re the best in the world at this, and there are others who agree.
If you need to talk about this with others on your team, check out this deck on Slideshare.
