Using Salesforce as Single Source of Truth

Question

From a software architecture perspective, are there major issues with using Salesforce as an application's single source of truth?

---

Context: We are building the software architecture for a high touch service. For example, imagine that our service sells very expensive life insurance. Our process looks like this:

1. A user submits their information on our site.
2. One of our representatives calls that user to gather additional information, updating the user record as necessary.
3. Over a series weeks our representatives call out to the client to gather additional information, again updating the user record as necessary.

I'm considering two possible architectures:

1. Relational Database (e.g. Postgres) with a custom portal (React).
2. Salesforce

The advantage of Salesforce is that we would get a user facing UI out of the box. We can customize the data model to the same degree we could with Postgres. And we can write and read from the DB just as we could with Postgres by using Salesforce APIs.

It doesn't seem like this architecture is at all common though, which leads to my question. From a software architecture perspective, are there major issues with using Salesforce as an application's single source of truth?

Answer 1

The elephant in the room when building a long-living system on a non-standard platform of a third party is always the risk of

Vendor lock-in

Even if you are satisfied by the platform today, it fulfills all your requirements and think the cost/benefit relationship looks good now, once you built a lot of applications on top-of it, you cannot easily switch to another platform later. This is especially true for SaaS solutions like Salesforce, as described here, for example. What you build on such a platform cannot easily be ported or migrated to a different platform, not without rewriting most of the components again from scratch.

This can easily lead to a situation where you may run into trouble, if

• the vendor decides to increase its pricing heavily for the next update, or

• vanishes from the market, or

• some of the core components do not provide the quality or features any more your business requires.

On the other hand, it is often not affordable to build everything you need from scratch just to avoid the lock-in effect, and you may have to trust at least a few 3rd-party vendors. This is usually a trade-off, and often living with a certain vendor lock-in can be the right decision for ones situation. But it is always a good idea to invest some thoughts into whom you trust there, and if you can at least mitigate the effects of becoming dependend on a specific vendor.

Answer 2

It doesn't seem like this architecture is at all common though, which leads to my question. From a software architecture perspective, are there major issues with using Salesforce as an application's single source of truth?

It's actually pretty common. Many companies rely on external vendors to plug-and-play systems, getting the benefits you mentioned. Except that over time, you may have additional feature requirements in the future which may not fit into the model.

You will want to evaluate the possibility of additional requirements in the future. If you need flexibility for the future, then explore whether you can design an interface where Salesforce is one of many implementations.

For example, imagine that our service sells very expensive life insurance.

Also if this is indeed the case, you may also want to evaluate the possibility of regulatory requirements that require you to store user / policy data in a certain format / location. Making your vendor the SSOT tends to sacrifice this control.

Answer 3

Before you plan out external applications using Salesforce API's as a database, please check if you will be well within the API usage limits in 24 hour periods as well as for concurrency. If you need more than that, use your own db. https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm