Building Scalable Solutions on Salesforce

Introduction

As a consultant, I often get into client situations where I’m asked to help with specific business technology problems. Over almost two decades’ worth of technology experience, if there is one thing I have learnt it’s that things change, rapidly, more so now than ever before. But it’s hardly possible to rip and replace technology as things change, although it is tempting to think so with an easily configurable platform such as Salesforce. As a strategic partner, I consider building scale into technology solutions as one of my prime duties to my client. What good is a solution that is designed so narrow as to require re-design when an adjacent use case presents itself?

However, scaling solutions is a team sport – stakeholders, business analysts, architects – all are involved. Let me explain. Over the next few sections, I’ll walk you through a specific situation and use that to illustrate how scale gets baked into solutions over various phases of the solution designing process.

Problem Definition – Defining needs broadly

Deconstructing Needs

As a business analyst, when I get into understanding my client’s requirements, I always make it a point to explore in more depth, needs that may be too narrowly defined but have the potential to spawn adjacent use cases. I encourage business stakeholders – through thought exercises – to visualize the big picture and paint a broader vision. It takes some experience as an analyst to do so, but by carefully de-constructing every aspect of a need, however seemingly simple it is, one can elicit such latent needs thereby setting the scalability wheels in motion.

Time for an example.

On one occasion, my stakeholders asked me to design for a simple need – send email to a person in a specific role when the related opportunity changes stage. Immediately, the scalability wheels started spinning in my head. I began to deconstruct the various aspects of this need in my head as follows:

1. Email – One standard email? Different emails by different situations? Does user need control to iterate on the verbiage? Merge data needed?
2. Person(s) – One person per role or multiple? Who to send to if multiple – first, last, all? Can one person be in multiple roles?
3. Role – What does a role mean in the context of the opportunity? Well defined set of roles or it may change?

You get the gist. Deconstruct, frame questions and help stakeholders visualize beyond the specific need. Take them on a journey through building scale.

Re-defining Needs

Back to the example, through such needs definitions sessions, here is where our seemingly simple need ended up at:

1. To begin with, send email to all people in a certain role(s) on an opportunity based on stage change on opportunity. This is an example, others were possible.
2. Arbitrary set of criteria was possible for a given email triggering event.
3. Any arbitrary number of roles needed to be notified in any given situation. Again no dependency on code changes to alter who gets notified in a given situation.
4. Email content of course needed to be in the business user’s control.

Scalable Solution — Designing Broadly

The Inquisitive Architect

Having defined the needs broadly, it’s time for the next phase of scale. As Business Solutions Architect, I then turn around and use such broadly defined needs towards building a scalable framework-based solution. Again, the idea is to deconstruct the needs and ask questions of the business analyst to clarify how robust of a technical solution will be needed. You will always design for today’s needs. But when designing for scale, the goal is to understand what kind of future changes can be expected and which of those have the potential to break the design. Revolutionary vs evolutionary. So that we can do the most today to account for as much of tomorrow without building too expensive a solution. And crucially, acknowledge the part of tomorrow that we have traded off for now in favor of today’s goals.
So in the example, a few questions in my mind were:

1. Stage change – Is stage change the only event? Is there a finite number of triggering events? Or simply arbitrary? Can objects other than opportunity be involved.
2. Flexibility – Was any flexibility needed in defining and iterating over the criteria?
3. Dependencies – Is there going to be an order to sending emails? Any dependencies on emails related to different situations?
4. Maintenance – From a maintenance standpoint, what additional needs were there?

Broadening the Perspective

This exercise then led to adding a couple more needs to the list:

• The criteria for a given email triggering event itself needed to be flexible and could change. As you know things change, what the main stakeholder thought, wasn’t the ground reality in the trenches so we would learn and iterate. Bottom line no dependency on code change and deployment cycles to change the event triggering criteria.
• Maintenance – From a maintenance standpoint, it would be nice to have these notification rules grouped together to see if there are inconsistencies or one rule stepping on the other. Kind of like what you can do when reading switch statements in code.

Framework-Based Approach

From here, conceiving the solution is a careful balancing act between today’s and tomorrow’s needs. In this phase, having frameworks or design patterns, to rely on is of critical importance. Just like MVC is a popular framework that most developers are well aware of and employ routinely in their work.

OLA (Orchestration-Logic-Action)

In workflow solutions like these, I have come to employ a homegrown framework I have coined OLA (Orchestration-Logic-Action). Briefly, here is what it means:

1. Orchestration – A mechanism to trigger the workflow. In the example, the triggering criteria.
2. Logic – A mechanism to execute the logic involved in a workflow and prepare for the ensuing action. In the example, the logic to retrieve the set of people to send email to.
3. Action – The set of actions that are the results of executing the logic. In the example, the action to send email.

Solution Options

So I started looking for solutions that fit this framework and leverage Salesforce out of the box functionality as much as possible. Here are the iterations I went through:

1. Option 1 – Workflow Rules on Opportunity
   Workflow rules on opportunity do not allow emailing to contact roles. Read the post at:
   https://success.salesforce.com/ideaview?id=08730000000BrHdAAK
2. Option 2 – Workflow Rules on Contact Roles
   
   Contact Roles is not an object that you can define workflow rules on either. It’s tied at the hip with Opportunity and has no customization ability.
3. Option 3 – Workflow Rules on a “ContactRoles-like” Custom Object – say Party – Related to Opportunity
   1. We could walk up to opportunity from the Party custom object to define workflow rules using opportunity fields. Crawling up like that seemed odd. It was the difference between:
      1. What we desired – “when something happened to me (opportunity) tell my specific children (people in roles) something”
      2. What this gave – “As a child (person in a role), I want to be notified when something happened to my parent (opportunity)”

      Bottom up vs. top down — didn’t like the design choice.

   2. Arbitrary nature of the criteria was hard to pin down and making several complex workflow rules just didn’t sit well as a design choice.
   3. Also, these independent workflow rules couldn’t be looked at in one go. Maintenance would be tough.

4. THE ONE – Process Builder, Visual Flow, Email Action, Email Template

Orchestration – Process Builder

1. Handles the triggering criteria for an event (need to show Jan what to point to).
2. Decides which roles to notify (need to show Jan what to point to).
3. Both aspects configurable and not dependent on code.
4. Add as many branches to the process builder as the arbitrary criteria demand.
5. All branches visible in the process builder for easier maintenance. Switch statement like view.
6. The business logic specific to a branch delegated to a flow

Logic – Flows

1. Fast Lookup parties for an Opportunity.
2. Loop through and figure out parties in role(s) as passed in by Process Builder.
3. For any matching parties, invoke the action (email alert) described below.

Action – Email Alert

1. Email alert Defined on the Party object.
2. Recipient is the related contact on the Party record.
3. Email Content Defined in a good old Email Template, business user in control.

That’s it! The framework helped defined a very scalable solution aligning with defined needs.

Key Take Aways

1. Think more broadly when defining needs. For building scalable solutions always look deeper into business needs to elicit latent/ adjacent needs which drive building frameworks and avoid piecemeal solutions.
2. Be inquisitive when architecting and designing solutions. Ask questions of your analyst to ensure needs have been at least thought of fairly broadly over an appropriate time horizon. Be a sounding board for your analyst.
3. Be resourceful and creative with your solutions. If at first it doesn’t seem like there is an obvious answer look harder. Leverage the success community for clues, your salesforce network, your developers. Collaborate!
4. Think flexible and configurable to the extent possible. Thanks to a strong desire to be configurable on certain aspects of the solution (orchestration and action parts) we pushed hard and achieved that.
5. While configurability is a strong desire, do not be afraid of code. Just know there is a time and place for it. I can very well imagine moving the “Logic” part out into Apex code if the logic gets too complex for flows. Better abilities to debug in code might be a better trade-off in such cases.

This was an example of leveraging multiple tools in the Salesforce arsenal to achieve a scalable framework for a set of related problems. But imagine the possibilities for the toolset assembled in this post. While the specific problem-solution pair may not apply to you, the thought process and the framework based approach to solutions is definitely applicable to any business problem.

The toolset is a framework in and of itself for Orchestration-Logic-Action (OLA). Maybe it doesn’t have a cool ring to it like MVC but imagine the possibilities. Any business process with similar characteristics can leverage OLA. Where will you take it?

Building Your Scalable Solution in Salesforce

Are you hoping to build a scalable solution using the platform but aren’t sure where to start, contact our team. We’re happy to walk you through the process and assist you, if your team needs help.