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:
- A user submits their information on our site.
- One of our representatives calls that user to gather additional information, updating the user record as necessary.
- 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:
- Relational Database (e.g. Postgres) with a custom portal (React).
- 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?