Salesforce could be used for building anything. Like any tools, just because we could use a tool for anything, it doesn't mean that we should. This document outlines the strategy of how Salesforce should be used in FP.

It's quite difficult to wrangle a strategy on how we should use Salesforce well because it offers a wide variety of different offerings. I, therefore, suggest approaching Salesforce from 3 different lenses:

  1. Salesforce as a CRM
  2. Salesforce as a low-code platform
  3. Salesforce as a cloud provider

Salesforce as a CRM

Salesforce was originally built as a CRM, therefore using Salesforce as a CRM is a good use of the technology. The danger in any CRM tool, though, it will want to get more and more data for it to be effective, which means we're faced with the risk of data-hungry packages. The hunger for data in CRM tools will happen as the person who's managing customer relationships would naturally like to be able to see the aggregated data around a customer, even when the data is not within the original scope of a CRM.

Understanding the original scope of a CRM is the key to mitigating data-hungry packages, and fortunately, the scope of a CRM is matured in the industry. Within a CRM, we'd typically be talking about the sales funnel, deals, interactions, contacts, etc. These concepts are domain agnostic to any businesses. Concepts that are not agnostic therefore is beyond the original scope of CRM. The concepts that are not agnostic in the Founders Pledge are, for example, the Pledge Model, Deployment, DAF, etc. CRM user would still want to see data being aggregated in a CRM, so the question then is, what do we want to do with the data beyond CRM in Salesforce?

To answer that question, first, we need to recognise that we don't need to have a single database for every data that we need, nor we need to have a single database to be the primary data source for every data (we use primary/replica instead of master/slave). Therefore, Salesforce could be both the primary data source of CRM, store the replica for non-CRM data. In Figure 1, you can see how Splash is the primary data for "event management" data, and it's being replicated to Salesforce for a CRM user to see.

https://viewer.diagrams.net/?border=0&highlight=0000ff&edit=_blank&layers=1&nav=1&page-id=-X9SOP_ILD5UzlC1zAN9&title=Salesforce beyond CRM.drawio&open=Uhttps%3A%2F%2Fdrive.google.com%2Fuc%3Fid%3D1_ivcFip8xKHLDCQsTR-7leBhE97uhePo%26export%3Ddownload

Figure 1. Salesforce storing primary and replica data

Having a clear view of where a primary and replica data source is the main rule of thumb of how a data-hungry package should be approached. However, this view is too over-simplistic and it rules out the opportunity to leverage the power of Salesforce as a low-code platform. This topic will be covered in the next section.

Salesforce as a low-code platform

Salesforce advertises itself as a "click not code" tool. Some of us have been calling it as a database or sheet with a nice UI. This offering is attractive as it helps companies who don't have technical capabilities build software quickly. On top of this, Salesforce also offers a certain level of customisability by code and custom objects, therefore Salesforce is a low-code platform.

The suggestion that a skilled development team is no longer needed is attractive, but it ignores the fact that writing code is just a small part of what's needed to create high-quality software. If we need low-code experts to come in and help, that's a good sign that we have moved beyond what has been promised as "click not code".

We, however, shouldn't rule a tool out just because there's a potential danger. We need to find the right balance between what deemed to be an acceptable use for a low-code platform. For example, Salesforce has been a good use for us when we're want to visualise the member journey (low business logic complexity). In the area of deployment or DAF, however, we could start to see how it gets trickier, due to its complexity and the need for change. Based on this, we can produce a quadrant that helps guide us in finding the right balance (Figure 2).

https://viewer.diagrams.net/?border=0&highlight=0000ff&edit=_blank&layers=1&nav=1&title=Salesforce beyond CRM.drawio&open=Uhttps%3A%2F%2Fdrive.google.com%2Fuc%3Fid%3D1_ivcFip8xKHLDCQsTR-7leBhE97uhePo%26export%3Ddownload

Figure 2: Frequency of change vs Business logic complexity quadrant

As much as there's room for customizability, it's important to note that customizability doesn't come without cost. The more we customise a tool, the harder will it be for us to switch to a different solution in the future (vendor lock-in). We need to understand when is it acceptable for us to have a lock-in, and this is down to whether a particular tool is a unique utility or not. My perception of Salesforce at the moment is that it's not a unique utility in the CRM world, therefore anything that increases our switching cost in the future should be reduced before it bites us in the future (Figure 3). A good approach to using a disposable utility tool is to use it as-is and let it control our process as much as possible.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/dfc898f9-9e12-450c-9273-39d4622772bb/Untitled.png

Figure 3. Unique utility vs switching cost as a guidance to approach vendor lock-in.

Salesforce as a cloud provider