As an Enterprise Architect at Salesforce, I’m frequently asked to evaluate a customer’s processes and map the best way to execute those processes on the Salesforce platform. My first question to the customer (which often takes them by surprise) usually is, “Are these processes focused on customer engagement or back office?” There response typically is, “What do you mean? Isn’t a process a process?” And that is the genesis for this month’s blog.

I have been working with BPM and BPEL since the 1.0 days of the specification and used BPM engines for many years. BPM engines are great for process definition in a structured way, mapping activity nodes to Micro-services, and generating run-nable applications. These applications can branch, loop, include both human and system level tasks and map well to mid office and back office processes. They are great for service orchestration and often include transaction managers to handle commit scope and rollback. They have a start and end whether they run for milliseconds or days, and they rarely run for months or years. Back end process such as order to cash tend to map well to BPM based processes.

But when you want to map out customer interactions, these left to right processes tend to be cumbersome or not work at all. In fact, I will contend that representing customer engagement is much better suited to an event driven data-centric model.

Customers are usually represented not as a process with swim lanes of interactions, but as a profile representation with attributes. Data from multiple systems are often brought together to represent a 360-degree view of the customer. Then when these rich profiles of data are brought together, processes execute based on data state change. These processes or workflows generally have some defined entrance criteria that defines when the process initiates. They may have extremely limited scope, or may be more complex. A good example of a simple data centric process is a process that sends a customer a congratulation Email on the customer’s birthday. Another example is when a customer has abandoned their shopping cart two times in the last 48 hours, and then send them a push notification discount in regards to that purchase to entice them to complete the purchase. There may be human elements such as submit for approval when the discount applied is greater then 20%. These aren’t processes in the traditional BPM sense that move from left to right, but actions that need to occur based on timers or data state changes. In this model the data isn’t in a particular step in a process, but always in a state ready to be acted on, or on behalf of someone (or some thing) based on their data state.

These type of interactions tend to be

• Both “one and done” as well as multi-step and long running with human approvals
• Ad hoc
• High volume
• Exception processing as likely as happy path
• Nested (one processes changes the state so that others fire)
• Relationship based

These processes need to be highly flexible, easily authored and changed by business users, fast, easily managed, and they don’t necessarily have a start and an end state. Data profiles can often be in more than one state at a time. For instance, in a hospital system, a physician could be a physician and patient at the same time.

Additionally, dealing with rapid change can be easier in an event based architecture. In traditional BPM systems, current inflight processes remain on the template they started on until completion. This is great for auditability and consistency, but when changes happen often across potentially thousands (or hundreds of thousands of inflight processes), all of these processes may need to be dealt with. In a data-centric platform, you may have thousands of processes firing due to a bulk date upload or other event. These processes often update their own data state and thus start additional processes. An example is a sales process where a big deal triggers an approval based on some criteria. Once that approval step is complete, the sales stage is changed thus firing off another set of processes for the updated sales stage. There is no concept and overhead of the process having to save its own state, because the process is driven by the data, not the process driving the data.

The best way to think about a customer engagement platform is the central concept of a customer profile and interaction data, and then a set of services that consume or take action on that data. In Salesforce, those services that consume or act on the data are process services, UI services, collaboration services, reporting services, and security services. Together this rich data and services make a truly unique cloud platform.

When the customer is placed in the center of the universe it changes your perspective. Instead of the process driving customer data, the customer profile drives the processes.

Learn more about why Salesforce is a leader in the Gartner Magic Quadrant Enterprise Application Platform as a Service. Download the report.