Hi, I'm one of the authors of the post. As an engineer, I've always wondered what Salesforce was. It seemed like a clunky, expensive piece of legacy software that the "business people" always used.
Since starting a SaaS company myself (Retool; https://tryretool.com), I now understand a lot more, hah. Salesforce, basically, is the source of truth for your customer, for the business-side of things (sales, marketing, operations, etc.). So the stuff we would typically store in our databases (company name, users, how much they pay us, etc.) is stored inside of Salesforce. And Salesforce gives you a bunch of views that a typical company would need — views to update the close date of a contract, the value of a contract, to take notes on a call, etc.
The cool thing about Salesforce is how customizable it is — you can change the database models (e.g. "add a column to the `Leads` table"), as well as change the front-ends themselves (e.g. "I want to display this data in this view"). I've previously used a lot of SaaS (e.g. Slack, Intercom, etc.) and it's always frustrating because I can't customize the views (e.g. in Slack, maybe I want to add a button to mute + clear all the notifications for this channel). Salesforce lets you customize all that, which, frankly, is really cool.
To some extent, Salesforce is like a new way of programming. Instead of writing code, you let non-technical people change models and UIs (and to some extent, controllers).
Happy to answer any questions! If you all think the essay could be improved in any way, LMK too :)
(Edit: added blurb about SFDC being a new way of programming, in response to a comment downstream.)
> To some extent, Salesforce is like a new way of programming. Instead of writing code, you let non-technical people change models and UIs (and to some extent, controllers).
That's the theory, in practice companies end up paying through the nose for an army of salesforce consultants, same as with every other "zero code" platform.
You didn't stress the most important part well enough:
> But when you bolt on other apps and 3rd-party APIs, it gets close to programming without code: a new way to build software.
SFDC is worth $100B not because it's a CRM. It's worth that much because it's a CRM platform. The "what it does" is not nearly as important as the ecosystem/platform aspect of it.
"What it does" has no moat. Platforms have a moat. That's the value of SFDC in a nutshell.
You could help highlight this by drawing attention to it earlier, and also by boldfacing the sentence just before my quote where you say "platform".
Just skimmed your article but you showed a screenshot of Dynamics 365 as a CRM system and then went on to talk about Salesforce as much more than just CRM.
Pretty much anything that Salesforce does, Dynamics 365 does too, so perhaps not the best screenshot of a bread and butter CRM system.
I've gotta push back politely here. If you are comparing marketing matrices between D365 and SFDC, then yes, on the surface D365 does "pretty much anything that Salesforce does". But you are missing one big factor: D365 costs half as much and there is a big fat reason for that. The D365 platform is very immature and feels like an afterthought at best.
I had the displeasure of running a D365 setup in a small government agency that took about a year to get off the ground. It was a living nightmare and I would never recommend D365 under any circumstance because of that experience. I'm tempted to say you would be better off using a free or homegrown CRM than choosing Dynamics.
A few lowlights (Disclosure: we were in the government cloud which is notoriously far behind the commercial cloud):
* Had to hire a PFE to set up the Exchange integration. This should be turnkey if you are in the same company's stack, IMO. Instead it took thousands of dollars and days of work by the PFE, our centralized Exchange admins, and myself.
* Little things like hiding the freaking nav bar cards are literally disallowed in Dynamics.
* The Dynamics 365 App for Outlook is a dumpster fire that didn't work at least half the time. Search queries returning no results, no useful error messages, and an overall appalling UX. It single-handedly killed adoption.
* I spent many hours trying to figure out how to send timed emails. That's because you have to use the advanced logic tools which are a nightmare. I was able to spin up the same timed email in SFDC in a matter of minutes. I truly wish this was an exaggeration but it's not.
* D365 documentation is utter garbage when compared to the SFDC Trailhead. The only option for getting off the ground for our technical staff was to pay for training through one of MS's sketchy vendors. It was overpriced (about $3k) and not at all great.
* The only way to programmatically interface with D365 APIs is through using the ancient SOAP API or their REST endpoint with OData syntax only.
* Oh BTW, if you were hoping for a modern development workflow, think again. You are going to be stuck manually uploading files into Dynamics for things like editing the internal interfaces of Dynamics. Oh and you have to register every single function against every single trigger, manually through a GUI.
* Their customer facing website options are a joke. I can create a fully fledged web app with complete control over the HTML/CSS/JS using the SFDC community, this is definitely not the case with Dynamics. You are limited to the point of only being able to choose layout templates with Dynamics. The last time I checked, you couldn't create your own.
* The development workflow with Dynamics is a joke. With SFDC I get a passable command line tool, multiple VS Code extensions, an easy deployment path, local development with Lightning Web Components, and many other developer tools. Good luck finding any of that with Dynamics.
The above probably could have been shortened to say the following: SFDC is dedicated to CRM while Dynamics is another in a long line of MS products and it feels like it.
I know there are problems with the SF platform, I feel them daily, but I don't think comparing the two is fair to D365.
Now why can't we find honest reviews like this for most software. Why do customers have to endure this in this age of Gartner magic quadrant/G2 and similarly fawning and often paid for marketing mumbo jumbo.
It has to do with the challenge of evaluating systems like this. The only people who really can understand it are people who are actually implementing and using it at scale and its the nature of their experience that they can't write a review "... I work at company x and after millions of dollars I can honestly say that this product is piece of junk here's a bunch of complaints which dovetail into the heart of our company's business..."
So we'll just have to live with the lone reviewer working in their home lab. "I created mailboxes for my cats and sent them 50 test messages without any hiccups, so Exchange 2019 looks like another winner!"
This is by far the most accurate,no BS description of what MS Dynamics really is. I think it says it all when even Adobe,yes Adobe, has a larger market share of CRM systems than Microsoft...
Oh my goodness, after so many years of a love/hate relationship with Dynamics, I feel like I have to defend it a little bit, only a little bit though :)
I must admit that I've not looked at Salesforce since 2014 so I can't really provide a comparison
>* Had to hire a PFE to set up the Exchange integration. This should be turnkey if you are in the same company's stack, IMO. Instead it took thousands of dollars and days of work by the PFE, our centralized Exchange admins, and myself.
I've never had any major issues setting integration with Exchange up. I can't say the same thing for other email servers, I'm looking at you postfix
You do get issues with syncing every so often, YMMV
You do say that you were on Government Cloud so maybe that was the source of the issue, the extra limitations.
>* Little things like hiding the freaking nav bar cards are literally disallowed in Dynamics.
Agreed, these things used to irritate the hell out of me as they seem to be so arbitrary. Although you also have limitations on Salesforce.
>* The Dynamics 365 App for Outlook is a dumpster fire that didn't work at least half the time. Search queries returning no results, no useful error messages, and an overall appalling UX. It single-handedly killed adoption.
Agreed, the old app was a nightmare and I've not tried the new. Hopefully you are referring to the latter.
>* I spent many hours trying to figure out how to send timed emails. That's because you have to use the advanced logic tools which are a nightmare. I was able to spin up the same timed email in SFDC in a matter of minutes. I truly wish this was an exaggeration but it's not.
I'm pretty sure that this is a google search away, set DelayedEmailSendTime. I say this as we had a requirement for this and we implemented it but the customer changed their mind and we went with a bulk email process in the end.
>* D365 documentation is utter garbage when compared to the SFDC Trailhead. The only option for getting off the ground for our technical staff was to pay for training through one of MS's sketchy vendors. It was overpriced (about $3k) and not at all great.
This is a fair criticism. I had a friend whose company landed a Dynamics CRM contract and they struggled to get started precisely because of this. The SDK was fine but they ended up doing all manner of apps with Angular inside Dynamics when they could've used the platform, they just struggled to find out what it could do.
>* The only way to programmatically interface with D365 APIs is through using the ancient SOAP API or their REST endpoint with OData syntax only.
There is an SDK with APIs for C# and Typescript(Javascript) that abstracts this away. If you're using something else then it's not great, I do remember having fun times trying to integrate with Java.
>* Oh BTW, if you were hoping for a modern development workflow, think again. You are going to be stuck manually uploading files into Dynamics for things like editing the internal interfaces of Dynamics. Oh and you have to register every single function against every single trigger, manually through a GUI.
There are so many tools/frameworks out there that this seems like very petty criticism. I was using tools to automate this away back in 2014 (custom but there are frameworks now)
>* Their customer facing website options are a joke. I can create a fully fledged web app with complete control over the HTML/CSS/JS using the SFDC community, this is definitely not the case with Dynamics. You are limited to the point of only being able to choose layout templates with Dynamics. The last time I checked, you couldn't create your own.
MS is pushing powerApps so this is unlikely to change
> I've never had any major issues setting integration with Exchange up.
So, this might have been more on our centralized Exchange system. We were integrating D365 with on-prem Exchange. To be fair to us, this was a scenario that was known, documented, and totally within what MS said they could do. To be fair to MS, it's for sure more muddled than configuring online Exchange with D365. Totally open to the possibility that it was our environment that caused the issues as well.
> You do say that you were on Government Cloud so maybe that was the source of the issue, the extra limitations.
Yes, this was a constant headache. To be fair to Dynamics, there were a lot of advantages in the commercial cloud. However, I think my criticisms of the core platform still stand.
> Agreed, these things used to irritate the hell out of me as they seem to be so arbitrary. Although you also have limitations on Salesforce.
Yes, very true. But I can basically mold the admin screens however I want. I can hide/display cards, tabs, and widgets at will.
> Agreed, the old app was a nightmare and I've not tried the new. Hopefully you are referring to the latter.
Very sadly, I'm referring to the newest iteration. Which has significantly less features than the original Outlook app. That app was essentially almost all of Dynamics functionality in Outlook. The new app is significantly more stripped down.
> I'm pretty sure that this is a google search away, set DelayedEmailSendTime.
As a programmatic solution, yes, that would be the appropriate function. To be clear, I was comparing the flow builder in Dynamics to the flow builder in SFDC. My bad for not being as clear as I could.
> This is a fair criticism. I had a friend whose company landed a Dynamics CRM contract and they struggled to get started precisely because of this.
I'm pretty sure if MS improved this alone they would have a better market share!
> There is an SDK with APIs for C# and Typescript (Javascript) that abstracts this away.
Sadly I'm not a great C# programmer. Most of my skill lies in JavaScript. They offer an SDK for JS but it is really not great to use IMO. Anecdotally, most of the people I've talked with who have had success with Dynamics seem to be strong C# devs. Fair enough and not all that unexpected.
> There are so many tools/frameworks out there that this seems like very petty criticism.
Why should I have to use a framework or write a single line of custom code to push code into production for an expensive platform like Dynamics? I really don't think I should have to. I still stand by this criticism because it's unacceptable UX at the price point IMO.
SF provides this out of the box with relatively little setup headache. So in my mind, SF wins this argument hands down.
> MS is pushing powerApps so this is unlikely to change
Yes, their reps were pushing no code/low code hard. The difference with SF is that while they push no code/low code at conferences, they have a real dev tools for people who want more control. I don't feel like this is at all the case with Dynamics. Granted, I did just the one deployment.
Hope you are having success with Dynamics in general!
This could go on but I think the key is that Dynamics 365 is a good platform as long as you have C# developers at the ready to paper over the gaps in the platform. If that's a likely to be deal breaker for you then don't use it, obviously YMMV.
It's only in my last company that we had an actual split between functional consultants and technical consultants, everywhere else it was developers doing ALL the work, so this is never been an issue, but I can see how it could be an issue
MS is pushing citizen developers like crazy, we will see.
Salesforce is more akin to Microsoft, and they each have a CRM product. Not all Salesforce products map to Dynamics, some map closer to Visual Studio, Linkedin, Azure, Office 365, PowerBI, PowerApps etc.
Their motto from the beginning has been "No Software!". So you are spot on about new way of programming part. Business idea is to have less in house software people for business goals. Lots of $$ (all $$)
Yeah, that's a "Why not both?" situation right there.
It does do important stuff for the business folks, and made it way easier for them in a really cool (at the time) way.
They've gotten bigger via tons of acquisitions and of course when you're an early adopter to an area, it also makes it harder to move when the next new thing comes up.
So yeah, it's clunky and legacy, parts of it slowly getting better, but also not going away quickly either because those who invested in it invested too much to pivot this soon. See also things like Hadoop or anything from IBM or Oracle.
When I scroll your site on mobile, it keeps jumping because the height of “Build an app ...” block at the top changes every few seconds (Safari, iPhone SE).
Since starting a SaaS company myself (Retool; https://tryretool.com), I now understand a lot more, hah. Salesforce, basically, is the source of truth for your customer, for the business-side of things (sales, marketing, operations, etc.). So the stuff we would typically store in our databases (company name, users, how much they pay us, etc.) is stored inside of Salesforce. And Salesforce gives you a bunch of views that a typical company would need — views to update the close date of a contract, the value of a contract, to take notes on a call, etc.
The cool thing about Salesforce is how customizable it is — you can change the database models (e.g. "add a column to the `Leads` table"), as well as change the front-ends themselves (e.g. "I want to display this data in this view"). I've previously used a lot of SaaS (e.g. Slack, Intercom, etc.) and it's always frustrating because I can't customize the views (e.g. in Slack, maybe I want to add a button to mute + clear all the notifications for this channel). Salesforce lets you customize all that, which, frankly, is really cool.
To some extent, Salesforce is like a new way of programming. Instead of writing code, you let non-technical people change models and UIs (and to some extent, controllers).
Happy to answer any questions! If you all think the essay could be improved in any way, LMK too :)
(Edit: added blurb about SFDC being a new way of programming, in response to a comment downstream.)