I have considered it for my company because it can do some neat things, but I feel a bit overwhelmed by it. Really curious about the feedback.
At its core, it's sort of a dynamic form builder: you design your data model and Salesforce creates input/entry forms for the data objects in the model. If there's a one-to-many relationship between two objects, when you edit one, you see a list of the related objects, and you can do bulk operations on the list in place. You have some customization options but for the most part, Salesforce creates all the UI for you and because it's uniform, it's easy for users to work with.
The two biggest problems were limits and opacity. Salesforce imposes limits on how many operations per second you can perform like reads or writes, and its not usually easy or even possible to predict what limits you're going to bump against, so you end up discovering them through trial and error (in production!). The other problem is the opacity of the platform - it's working a lot of magic under the covers and you have no visibility into what it's doing and definitely no control over it. If you thought Ruby on Rails was hard to reason about, just wait until you meet Salesforce!
All in all, I'd recommend doing as little "in Salesforce" as you can realistically get away with - your users might demand it because they know it, but Salesforce makes you feel like you can run your entire business in there, but those are murkier waters than you would imagine.
Basic entry and view forms are very easy to create; Basic reporting is very easy, as well as basic charting. But the provided charting components can only be customized up to a point. For example, you can set the color of chart segments by value for pick-list fields, but not for calculated fields, and only for certain types of charts.
Salesforce is a big, complicated system and it takes a while to learn. If your needs can be met by their built-in Sales or Service modules then it may be a great choice. If your needs can be met by a 3rd-party add-on, and you're willing to pay extra for that, it may also be a good choice. If you want to recreate your custom business logic in Salesforce then you may want to hire a consultant.
Salesforce also has a lot of pricing and licensing options, so you would need to be careful about making a purchase before you know all of your needs and understand the different license types and pricing tiers.
https://appexchange.salesforce.com/appxListingDetail?listing...
It ain't too pretty, but instead of creating of thousands of workflow rules or spending days clicking, you can simply use spreadsheet to decide how your logic runs.
The marketplace is insanely expensive to add simple features or tools that many other platforms have built in -- or, if not built in, easily developed with a sane API. Look at this sample project for a session timer to get a feel for the insanity: https://github.com/SalesforceLabs/CaseTimer and things like a command line interface and source control for your sites are either nonexistent or poorly supported or documented.
The only reason we use it is because the directive came from above; Salesforce feels like Oracle to me in that it gets sold to the higher level execs who never actually use it, and it gets forced on everyone else.
I know there are some good Salesforce sites around somewhere.. but those seem to be the ones where they've replaced all the Salesforce stuff with their own UI and simply use it as a backend database.
I highly recommend avoiding it like the plague.
We have a handful of clients we build and maintain sites for. Some older, some newer. I don't have exact numbers, but if a vendor isn't pushing $5 million+ annual sales, Commerce Cloud doesn't make sense.
When I started, code was tied together with "pipelines", which were basically flowcharts[0]. (Newer sites use a controller model.) Later on, new sites had a modularized JS and SASS system held together by node.js scripts, along with tightening PCI requirements (TLS 1.1/1.2+, 2 factor auth required for code and asset uploads (client side certs with WebDAV)).
The front ends are tied into Cloudflare automatically, and the back end has always been through a highly restricted ORM. The whole platform is laser focused on e-commerce, and as soon as you step away from the strict add-to-cart/wishlist and checkout model, the platform is horribly suited. It doesn't do newsletter management, reviews, or address deduplication well (better to integrate with external services), and file/image uploads are a pain in the ass. It only has enough CMS features to sell things; you can use it as a corporate blog, but it's not that well suited if you have a marketing department that changes everything and wants something "completely new" on a weekly basis.
I've had a good experience. For the times we've needed it, Salesforce support has been effective.
[0] an article today eerily reminded me of it, though I don't agree with the premise https://news.ycombinator.com/item?id=20037962
For established companies of a certain size, Salesforce is usually just assumed to be present, kind of like IBM in a previous era. This is mostly because everything integrates with Salesforce, and all salespeople know how to use it.
For smaller companies, particularly startups, the ROI isn't as clear. Salesforce is expensive. The CRM that most startups need is marketing-focused, and you probably get one for free with whatever marketing automation tool you use. It's worth it for smaller outfits only if they have a long and involved sales process (say, institutional sales primarily), and perhaps if you are involved in education or a non-profit, since they have programs that reduce the cost in that case.
Salesforce out of the box isn't particularly enjoyable to use, but it's learnable and usable. A lot of companies add on cut-rate customizations that end up making things a mess, but that's more a commentary on change management at large organizations than the platform itself.
Salesforce as an internal sales-team-management tool is a very different beast than Salesforce as a product delivery platform, so I'll try to address both.
As an internal tool to manage a sales team, Salesforce shines. It provides a simple, extensible UI for sales reps of all skill levels to coordinate their activities, and provides lots of hooks for integrations of various other products. For example, our marketing team generated leads using other software, and could easily pipe their lead data into Salesforce, where it was easily acted upon by sales reps. Salesforce quickly became _the_ source of truth for the reporting activities of the sales department as a result of the ease of getting data into it. Additionally, Salesforce's customizability was a huge asset - when the sales team wanted to add fields to their core CRM data tables (Leads, Opportunities, Contacts, etc.) - they could do it themselves without involving the engineering team at all, because Salesforce's configuration-first interface enabled them to do so. Eventually it got complex enough that a full-time Salesforce admin was hired, but for smaller teams that might not ever be necessary. Salesforce can do a lot more advanced things if you add custom code to it, too.
As a platform for delivering products, it has a whole litany of problems that make it difficult to work with, so I wouldn't recommend using it for that purpose unless you have someone around who has adequate experience to avoid the pitfalls. Salesforce "orgs" are essentially primitive containers - they're instances of the Salesforce core product that are isolated from one another on a multitenant cluster infrastructure. A managed package is essentially a custom configuration for the Salesforce core product - including database schemas, permission assignments, custom code, and more. When you sell a managed package, it is installed in your customers' orgs and all custom code is obfuscated from their view. This is a neat solution for preserving IP, but it can cause huge headaches when your customer base grows. Without adequate preventive measures, customers (used to the customizability of Salesforce) might build their own org-specific customizations that rely on functionality in a specific version of your managed package, and then downstream changes to your managed package can break their custom functionality, leading to angry phone calls and support nightmares. Because of this, we had to be extremely judicious with our update pushing, which slowed down development progress substantially. Until very recently with the advent of Salesforce DX, local development was extremely difficult as well - we essentially had to provision many sandbox orgs for our developers, and the always-running nature of those orgs, combined with the limited number of allowed sandbox refreshes, led to lots of problems with unwanted data artifacts hanging around. This made bugs quite hard to reproduce in some cases.
Since Salesforce has evolved as a platform for roughly 20 years, there's a lot to learn. Salesforce's whole ecosystem at this point probably has a similar complexity to AWS (as a whole). As such, if you ever want to do really advanced stuff with Salesforce, I cannot understate how important it is to bring someone on board that has lots of tribal knowledge of the platform before trying to implement it. You're probably fine without such a person if your need is for a simple internal sales CRM, but if you're trying to go beyond that niche, a good Salesforce admin, developer, or architect is worth their weight in gold. There's a reason the big consulting companies make tons of money selling Salesforce implementations - it's hard to do it right the first time, and an improperly managed implementation can spiral out of control really quickly. Fortunately, Salesforce's docs have gotten way better in recent years with the advent of Trailhead, and they've made strides to improve the developer experience as well.
There's one thing that I don't get about Salesforce. They have all the data in world about how their users, developers and admins behave and yet still they don't do much with it.
They should be able to move their entire stack implementation from Oracle DB and x86 to cheap as chips ARM servers, yet they jack up prices for their HDD based systems every year.
They should be able to create this intelligent compiler-linter that should hint at 50% of compile errors, yet they focus on devout "citizen developer" tools that fail miserably at any non-trivial task, create mountains of technical debt, yet get sold to largest companies in the world as cure-all...
And finally, they really shouldn't move hundreds of their New Zealand users from USA datacenter to UK one, just because their account was opened there 10 years ago...