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).
As a Salesforce developer, I find myself feeling like I'm on a different planet compared to other developers. I can't:
- develop locally.
- easily backup using source control.
- contribute to or create open source projects easily. There are a lot more barriers to do so compared to JavaScript or Golang communities.
In addition, I'm always working with sugar-coated Salesforce tech. Apex (kinda like Java), Aura Components (crappy js framework that doesn't even come close to react).
I'm happy that Salesforce is going in the right direction with their web components, but it still feels like they are 10-15 years behind.
DX works great if you have a new project in a new org. But as a contractor, there are many times I have to work in orgs that are 4-5 years old that have been through tons of admins and devs. I can't exactly convert an old org instantly to a dx project. Plus, as a contractor I'm not generally paid to convert their meta data. They want new features or bug fixes. They don't give a flying duck if their org is dx or how their code is organized.
>But as a contractor, there are many times I have to work in orgs that are 4-5 years old
I'm a contractor as well. You know, there's a ton of legacy shite out there that isn't greenfield and you just need to get in there and guddle (Scottish word) about to earn the bucks. Sure I'd love to work all day long with .NET Core (or even .NET 4.7), but I also need to maintain a bunch of crap that dates back to 2006 and written in .NET 2.0. But as a contractor I kinda get on with it. It pays for my hobbies (model railways and building analogue synths, growing chillis and other stuff), so I kinda just suck it up because the rates are pretty ok.
And you know, there's no shame in being a maintenance dev, some of the best devs I've met are looking after ancient crap long after the overpaid, unsupervised "superheros" that dug those holes moved on to their next 1000% glory roles, and we have to mop up afterwards (for a tidy hourly rate).
They made it to generally available to everyone, but still had a (*beta) tied to it for a while. Maybe that’s gone now, but it’s still missing a lot of essential features and they know it.
There is a high demand. Like exceptionally high. As a contractor I have endless work and never have a hard time negotiating my rate. There is such high demand because Salesforce is not as sexy as being a front-end dev that uses react or a back-end dev that uses go.
It's limiting and can be frustrating, yes.
Apex and aura components are not transferable directly, but what is is learning how to work with enterprise software. Plus, my bred and butter with Salesforce work is integrations, which has given me plenty of opportunities to learn other languages as needed to get the work done.
Sure, I've done that in the past. The problem with using a third-party framework is the longevity of the org. As a developer, I want to leave an org in better shape than when I started.
If I created an angular app here, a react app there, and elm lang app over there, you are dramatically increasing the overhead to maintain the org. IMO, it's better to play it safe by using Salesforce's tech stack so your client has an easier time maintaining their org in the future. Future Salesforce devs will thank you too :D
Plus, there is a very high chance that future interviews for Salesforce dev gigs, they are NOT going to ask if you know React/Angular. Nice to have skills for sure, but they want to know how quickly you can get started working in their org. And chances are their apps are built with apex, Visualforce, or aura components. I'd rather spend a year building with aura components to make my new project transition easy, than spend a year building with react and have to pick up aura components all over again.
Get a couple certifications. Once I got 3-4 and a few years of experience, recruiters approach me on regular basis. FYI I have no college degree. Companies don't care. Certs and experience are worth more than any degree in the Salesforce space.
I've done some Salesforce work n the past, on a booking system that needed to read/write with their Salesforce instance. Their Salesforce dev spent a lot of times in our office during the build, and after a few drinks we were chatting about prospects as a Salesforce dev.
He pretty much echoed what you said - it's a different world to standard dev, and you can go quite deep into their ecosystem, but the work is always there, and a good Salesforce dev is worth his weight in gold so companies will bend over backwards to accommodate you - including paying your named price. It's depressing to write, but he probably earned 3-4x my salary for doing work that seemed pretty easy to him, and a quick glance on LinkedIn shows that he's still doing Salesforce work now.
When our company switched to Salesforce to convert a custom admin tool to use Salesforce, they forced us to buy consulting time with consultants to help us learn the system. It was written in to our contract as an extra cost. Maybe our business was pure trash at negotiating, but I think it's pretty common.
From a cynical and maybe overly negative point of view, it felt like Salesforce developers are kind of like contracted mafia enforcers. As long as the devs play by Salesforce's rules and do a decent job (i.e. make Salesforce salesmen money), they throw them free, lucrative, repetitive, braindead, unfulfilling business. In our case, they literally couldn't screw up - we had to use them, and no amount of complaining to our Sales guy or trying to understand why the main engineer was such a kook was going to change our situation.
Seems like a really lucrative hustle to get into, as long as you don't mind dealing with absolute mediocrity.
Because you get to work as a tech consultant fixing sf issues and extending SF for the many many corporate customers that use it. There are whole agencies built around doing SF implementations and other SF work and there is plenty of money to be made in this space. I know people at Deloitte that went from SF consultant to director and even one to partner.
Plenty of devs work with specific products as these products are used by many companies. I know lots of ERP developers that make very good money scripting customisations into ERP systems, it's a pain of a system but you're right at the heart of the business working on very high value contracts.
Can you suggest any resources for getting into salesforce development? I am aware of trailhead and its seems to be a great place to start. Any other resources?
There is a TON of money in Salesforce. I'm rolling it out at our company right now and it's mind-boggling how many associated costs there are when you want the Salesforce connector for your existing tools:
* Data enrichment service plugging into Salesforce? Extra $10-20K/annually
* NPS service piping responses in? Upgrade for an extra $8K
* Preloading account data? There are like 5-10 sources you can have, each one with a different purpose, each one a potential $25K/annually
* How about a note-taking app that lets you modify Salesforce fields in the app? Another $40/user/month
* Hiring a consultant? $150-200/hr, and it'll take 100 hours to get it done
All that's on top of the $150/user/month Salesforce Enterprise list price
yeah and good luck deciphering their licensing. I'm a SF consultant and SF called the CEO of my company and told him to tell me to stop "socializing pricing" with one of my clients.
It really pissed me off since I have a long and trusted relationship with this client, if i can't give her a ballpark on licensing costs for some feature portfolio then what good am i as a consultant? God, it still pisses me off to even think about.
You are not playing this in a right way. It's not your job to know the prices.Tell them they need to contact Salesforce for tbis, however you could give some tips on how to negotiate a good deal.This way you'll keep both Salesforce and your client happy.
It's first and foremost a sales company, and that shows in the way they nickel and dime you for EVERYTHING. And by nickels and dimes, I mean thousands of dollars per month.
I'm just imagining a powerpoint slide that says "Yes we'll screw you over; after all you're the customer!" and a bunch of salesbros around the conference table muttering "well they have a point there..."
Want a sandbox that's big enough to use as an actual integration/staging environment rather than just a little toy "Developer Hub"? 15% of your annual contract.
And it is still quite expensive, though. I mean... having 25 little sandboxes, and a partial copy environment is just silly. I'd rather have one or two dev. environments and a full copy instead.
Hey yeah, I worked for a SaaS company (about 100 people) about 15 years ago that was paying salesforce around $500k/yr. That said, it was probably worth it.
I've no experience with this area, but the $150 per user and month seem pretty high to me. How many people would typically need that kind of access? Only Sales, or even more parts of the company?
This is list price, though to be fair they throw discounts around pretty easily (we got 35% off for a 50-user purchase). All customer-facing teams and people needing to understand customers (marketing, for example) would have access.
For us: sales, account management, support, marketing, even some engineering need licenses.
The Oracle heritage is certainly showing in the pricing.
I don't have experience with many systems, but I'd assume the accounting departments need access, as well as customer success/tech support departments.
I don't fully understand it but my company stores important customer support data (including issues and software changes) in Salesforce, and I as an engineer have no access to that information because the per user cost is too high.
It is the highest you'll get for an Enterprise Edition license as far as I know. You do get great discounts on large volumes, like some said. To give you an example: if you get, say, 500 licenses, you can probably upgrade them to Unlimited Edition (list price of USD300/user/mo) for almost no additional cost.
This is nearly a universal law in the sales world: products/services pitched to salespeople always 1) are expensive and 2) come with their own sales team who are slick and/or aggressive.
I've seen it from sales training, to software and everything in-between.
TBF sales tools probably come under the most scrutiny at just about every company for price/value. Companies that sell tools to sales can get high margins but can't price themselves above their value.
What a weird sentence to write but at least in my experience with IT/engineering so much stuff ends up being bought that, although it's is usually nice, would never stand up to scrutiny if we had to justify business value.
I work at a large company (one listed on their homepage in my country) and IIRC we pay millions per year to Salesforce. It's an incredibly expensive product.
And people said the same about SAP years ago. The challenges are no different...which basically boils down to integration and data (with the biggest exception being that there is no longer a whole "we need a whole project just to build the infrastructure that hosts the service").
I work in the sales and marketing world, and the best way describe Salesforce is it's the infrastructure sales is built on. Especially in the B2B world, it's just as big and heavy hitting as any of the other FAANG companies, if not more.
And I want to stress how big and clunky SFDC is even for people familiar with it. I am sure everyone and their mother can build a faster, more elegant CRM. But that misses the point. It's infrastructure. The fact that it's legacy is the feature! I'm sure we can design more elegant roads and pick smarter rail gauges today, but having consistent and interchangeable standards is important to build on. It's enough for a company to constantly track their changing market, they don't need to risk losing customers because they upgrade the CRM every couple of years.
My 2 cents is that its kind of like Microsoft Word or Excel but for Sales and Marketing teams. Nobody uses all the features of Microsoft Word or Excel which makes them super complicated and feeling clunky but take any one feature out and you'll have an angry subset of vocal customers who absolutely depend on that feature.
I kind of built my career on it.
While reading some forums, including some threads on HN, I see a lot of misconceptions about Salesforce. When it started,it used to be purely software for sales and how to manage leads,deals and contacts. However it's been around for 20 years and now it covers much more. For instance,I work for a company that delivers training to thousands of people every year.The entire business runs on Salesforce.The sales manage their leads(tens of thousands) and interactions with them(calls,emails,sms), while operations book the courses, customer service manage complaints, finance team tracks products, invoicing,and vendor manager tracks their performance, contracts and etc. At any given time I can go on Salesforce and see how much money the company made,what are the issues, how's marketing doing and etc. Alternatively to this kind of unified system is a mish mash of number of applications, endless Excel spreadsheets and bottomless email server. Since I joined, the company tripled revenues,yet we have same number of people managing training and customer service...The sales reps pulling in twice as much of revenue. I know there are a lot of developers here on HN: even if you don't want to use Salesforce platform,you can leverage free developer edition for rapid prototyping.You could literally mock up things within hours,including interface,database and sometimes even automations. For those who are planning to hire sales people: the absolute majority of decent ones( especially in the US and to some degree in the UK) most likely used it in their previous jobs and it is very likely they will expect it in your company as well. What companies use it? All of them,including Google,Amazon,Coke, Shell, Barclay's and etc..
+1 to developers on HN: if your dream is to have a company with a sales team, it's great practice to get to know CRM softwares early and in-depth. Every seasoned salesperson will need a functioning CRM to do good work...and the best salespeople will get held back by a malfunctioning/nonexistent CRM.
As mentioned there are dozens, and Wikipedia will show you[0]. Since CRMs can be bolted onto just about every business, use cases vary extremely. If I'm being honest, every sales manager starts with an internet search to find the latest rundown [1].
My recommendation is to set aside time to play with a lightweight (pipedrive) + heavyweight (Salesforce) options to see how you might use them one day. I would treat CRMs like a regular piece of software. Many offer totally free trials for 1-3 users. So I would bet they agree with this approach :)
There are zillions of all sorts of vendors, however it will most likely boil down into these: Oracle,Salesforce,Adobe,Microsoft,Zoho,Hubspot,etc. Some interesting resource on CRM in general:
https://beagleresearch.com
As for specific products,I'm mainly familiar with Salesforce,so:
https://trailhead.salesforce.com/en/home
Punctuation was never my strongest trait,nor was English,as a foreign language. The fact that I typed it all while watching a film didn't help either to the quality of the punctuation.I'm happy to advocate for a product I believe in, however I doubt that could pass as marketing.
I have extended family (two brothers, two nieces, one niece's husband, one nephew) all into Salesforce.com/SFDC development.
Four of them successfully ran a SFDC consulting business for several years with many good clients and lots of junior and senior developers and architects (I joined briefly after leaving SF Bay Area but decided I should go back to building products). The business ran into family-business-squabble problems between two of the principals and dissolved ... however they all stayed in the SFDC game and have done very well, making significantly more (even considering they're contracting) on long-term stable contracts than their software experience would net them at established SF Bay Area companies ... and they all live in much lower cost-of-living areas. I don't think the SFDC game will go away any time soon, either.
There are probably some interesting SFDC development niches, but I would have struggled to maintain interest.
Salesforce is awful to develop in. The worst designed language, terrible tools, poor feedback, inscrutable gotchas. An abhorrent mix of the worst parts of Java with the worst parts of SQL. Everything is utterly rubbish, there is absolutely nothing positive about it.
But it's great to put your sales process on for a slightly techy person. Sort of the modern equivalent of access.
Needless to say, that means no developer wants to touch it with a bargepole.
So if you're prepared to put up with all that, you can make a lot of money doing ridiculously simple things.
Salesforce is essentially a database as a service with some fancy admin panels and prebuilt web interfaces.
The tech is proprietary, and not that fun to work with. [0]
As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.[1][2][3]
But, I still 100% recommend Salesforce to companies when they ask about it. Why? Data liability. Yes Salesforce is expensive - but you are outsourcing the responsibility of dealing with sensitive data to Salesforce. This is something that they should market more heavily in imo. (at least to sw engineers and CTOs) Realistically many companies are not properly equipped to deal with data, let alone sensitive data. Salesforce may have started out as a CRM, but now it is a solution to that problem. CTO's now have someone to point the finger at if shit hits the fan on an Equifax level. This alone is worth big $$$.
What’s really bizarre is that Salesforce is happy to fly ten of their internal consultants to a meeting, spend all day talking about your business requirements, then end up telling you to hire a 3rd party consultant. I don’t understand what the consultants who work for Salesforce actually do!
They're paid to add value to the customers and be people the customers can trust. This is valuable because when the customer needs something, they ask this person for their 2 cents. When the problem is something a Salesforce tool can solve, the customer is more likely to choose it and either give Salesforce money, or save a bunch of money not having to buy an extra thing (saved money means more budget left over for Salesforce).
Salesforce is built on mutually beneficial relationships. If you go under, they lose your business. If you grow, they make more money selling you more seats.
Except whenever I ask them for the 2 cents, the answer is “well, there are three different ways you could accomplish that, and we aren’t going to tell you which to use — we recommend you hire an implementation consultant”. Which is a total waste of time.
And I don’t have time or room to get into how awful Salesforce documentation and support are if you try to implement anything yourself. As far as I can tell, the reason they tell you to hire a consultant is that only the consultants have the experience to know the literally unwritten rules.
When I really tried to pin them down on some of these implementation questions, the Salesforce folks actually said “well, we don’t recommend self-implementation”. So when you read all that stuff about it being a development platform, be aware that means for consultants, not you!
So if they’re being paid to develop trust...well, that’s the opposite of what they did.
> The tech is proprietary, and not that fun to work with.
> As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.
True. But Salesforce allows fairly non-technical people to build fairly robust applications with very limited CS training. If I were interested in getting a technical job but had no experience, I'd consider becoming a Salesforce administrator as a way to get paid to learn to code on the job. [1]
You can build something that is complex and scalable without any programming experience. And what you build will be supported for the next ten years. It's not a terrible proposition for most businesses - especially outside of the Silicon Valley bubble.
I've worked with engineers implementing Salesforce at two different companies.
While SF may or may not be the right solution for a problem, I disagree with your assertion that developing for Salesforce will in any way prepare you for a "real" programming job.
You would mostly learn how to configure a lot of UI, maybe write some custom widgets (with Lightning), and write a a little bit of integration code here and there - in an arcane Java-like language.
All you really learn is the Salesforce ecosystem.
You can make very decent money if you can sell yourself. As others have mentioned, Salesforce could be seen as a sophisticated employment scheme for consultants.
But I would advice anyone to steer clear of it as a career path. At least until you have some proper experience in other technologies.
>allows fairly non-technical people to build fairly robust applications with very limited CS training
Ok. BUT... when those limited CS training people want it done right, they hire any one of the huge middlemen do make SalesForce integrations and modules.
ATG is one I know of first hand. Hiring tons of people to make SalesForce suck less. Mostly sales people themselves, then some programmers to do the real work.
This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.
Think of the other tech companies over the years that have seemed like behemoths to be utterly knocked out by someone that came in and sucked less. What do you think happened to the industry of Certified IBM Professionals that relied on IBM being market leader in PCs?
> This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.
It's worked for hundreds of thousands of people who make a living from turning raw Access/Excel/Wordpress/Microsoft CRM/Dozens of other products/etc into custom applications that solve the needs of particular business processes.
Every business has its own warts, that no one-size solution is going to solve well, and that will require someone to write a plugin for an off-the-shelf business product.
Outside of the Silicon Valley bubble, most software engineers make a living doing just that.
My first job was writing simple glue scripts that talk to a database for a small biology lab, to help them keep track of their samples and orders. It was ancient. I was so grateful to have the job. Man, I was happy.
This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".
The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.
What makes you think the hypothetical rewrite on a new technology is going to have any less technical debt?
By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.
1. The people who built the system didn't know how to do things right the first time.
Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.
Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.
2. The problem is actually incredibly complicated, and has no clean solution.
Solution: Don't do anything.
Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.
3. Most of the system is actually fine, there's just a few bad parts.
Solution: Refactor the bad parts.
Non-solution: Rewrite the whole thing, even the parts that are maintainable.
--
I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.
Technical debt is always a problem. But generally I prefer refactoring existing code rather then rewriting to address technical debt, because I think the old system is well understood, and the deficiencies are known. When you blow it away, you are also creating more technical debt, but you just haven't discovered it yet.
This isn't to say "never rewrite". I am saying we rewrite way too much now.
>> fairly robust applications with very limited CS training
Historically, this hasn't gone well. I'm sure many Software Engineers here can attest personal anecdotes to that.
> peak hn
I believe that are saying that this this is the epitome of what HN has become. ( what they believe to be non-software engineers discussing things. )
While I don't encourage gatekeeping, I think anyone can become a software engineer if they read the right books and spend enough time. I had a similar sentiment about seeing the line:
>> fairly robust applications with very limited CS training
This is an oxymoron. Non-technical people simply cannot build 'fairly robust applications' for reasons they quite simply don't understand. Building robust applications is way more than making it work. You also have to make it maintainable and scalable. Salesforce code I've seen written by people with 'very limited CS training' is neither of these.
I agree with you here, their tech generally lags behind the industry. It's inevitable for such a large company with so many customers relying on backwards compatibility though (the Lightning Experience switch is a counter point to that).
What I have noticed in recent years is that they have been trying to be more open when it comes to their development process, and empowering to open source developers building stuff for their platform. I built a Prettier plugin [0] for their proprietary language Apex and received a lot of support from them. Hopefully that means their ecosystem will get less "enterprisey" in the future.
Bret Taylor is a modern tech product guy. He led Google Maps, was CTO of Facebook, etc. He's completely altered the DNA of Salesforce and made it a modern tech company.
I've seen this plugin trend on Salesforce Twitter. Can you summarise what does it do that beautify with simple config or Illuminated Cloud 2 formatter cannot do?
- It is opinionated so teams no longer have to debate about coding styles. It is a refreshing change once you get used to that mindset. IC2 formatter has many configurations that developers can tweak, but that means you as a team need to debate within yourself which one(s) to configure.
- It is a CLI tool. That means you can do things like: run it as a linting tool on every commit to enforce coding styles, run it as a pre-commit hook, auto format files when you save in your IDE, etc. IC2 is closed source, and as far as I know there's no easy way to run it in a headless way.
- It is free.
- It is open source and has been tested on millions of lines of code. If you're using an open source Apex library, chances are it's part of the integration test suite, see [0]
- It is written specifically for Apex/SOQL/SOSL. That means it knows the context of your code and can format based on that. Tools like Uncrustify technically do work on Apex code, but it is being parsed as a generic C-like syntax so a lot of things do not work right (especially when Apex moves farther away from being Java-like).
- It is blessed by Salesforce, and their official IDE (VSCode) will soon adopt Prettier as the formatting tool of choice.
Those are just a few reasons. Prettier has a dedicated page [1] for everything else that also applies to this project.
> But, I still 100% recommend Salesforce to companies when they ask about it. Why? Data liability. Yes Salesforce is expensive - but you are outsourcing the responsibility of dealing with sensitive data to Salesforce.
This is precisely the reason why my organization, a large Canadian FI on the commercial banking side, decided NOT to go with Salesforce. They couldn’t rationalize giving up the data and went instead with a MS Dynamics implantation. This was 10 years ago.
Salesforce deserve credit for being continuously online as a cloud service since about 1999, and since then regularly rolling out updates and new features to the original codebase without knocking anyone offline. And obviously it has expanded massively since '99 to become the paas behemoth it is today. Think about how brittle code gets after just a few years of incremental updates. Salesforce must have the foundations pretty solidly nailed down to be able to keep expanding the codebase for 20 years without a 'sod it lets just stop and rewrite everything' moment.
> Salesforce is essentially a database as a service with some fancy admin panels and prebuilt web interfaces.
In the sense that my car is just a hunk of metal with four rubber tubes attached.
Seriously, can we please stop these lame attempts to distill extremely complex systems into overly simplistic models using "this is just an X with some fancy Y" type analogies? They don't really contribute anything to the conversation.
It's also better than a lot of the other commercial offerings. At a previous place we had to move from Salesforce to Sage CRM when we were acquired because that's what everyone in the bigger company used ... and it was absolutely awful in comparison.
I don't buy that argument about data liability. I would assume the Salesforce contract indemnifies them from any liability beyond what existing case-law requires. It would be down right negligent by our capitalistic standards for their legal department not to include as much responsibility shirking as they can possibly manage.
They may offer tools related to it but any flaw or issue that exposes your data is still your problem. Remember the trouble Amazon got into for all those data leaks over publicly visible S3 buckets? No? Why would they? Exactly.
It doesn't necessarily have to be about legally enforceable liability. Companies have insurance for that.
Even just from a data management standpoint, they have a business template that is much better than what could be implemented internally.
But after reading "Bullshit Jobs" [0] I think it's more than that - It's more about culpability and plausible deniability of decision makers in companies. Many companies have a CYA (cover your ass) culture. The higher up you go, the worse it gets.
When faced with a challenge that needs to be solved by tech, people in these companies have two choices: 1. Build it out internally, 2. Use Salesforce.
Salesforce is an incredibly safe choice for these type of decision makers. Because if shit hits the fan on an internally led project approved by them, they are associated with that failure. It effects their career trajectory. If something goes wrong with Salesforce - overbudget, data leak, etc. It doesn't matter, someone besides them is first in line to take the blame.
Ever hear the phrase "Nobody ever got fired for choosing IBM"? [1] Salesforce has grown to the point where they are recognized as a standard across industries by non-tech people. I've heard people from small local non-profits all the way up to publicly traded fortune 500 mention Salesforce. Name recognition on this level is quite literally worth $billions in the B2B world.
The "cult-like fanbase" is mostly around declarative configuration, and a community of System Administrators that can implement complex rules and page layouts without any code.
I use it as part of my job periodically. It is not intrinsically shitty.
When used properly, salesforce provides valuable information and organizes and facilitates coordination around customer-related issues and initiatives far better than anything else that's generally available at the kind of scale it's used for.
The problems start when people who create tickets don't understand how things are supposed to work (because no one gets fucking training), and just end up jamming multiple problems into one ticket.
It should be called "everythingforce" instead of Salesforce. The features have grown so wide and deep that even CRM is just a small sliver of what Salesforce is. It has its own server side language ( APEX ), a front end framework (Lightning), a community builder/site hosting thingy ( Community Cloud ), and "custom objects" and relationships (think a user defined schema ). If you wanted to you could use Salesforce as a hosting platform for any web application.
Yep, and the problem with that in my experience is it's enough rope for companies to hang themselves with. I've seen multiple cases of using Salesforce for things/applications for things that belong outside of it. I'm only a little sour about it :D
I am in the process of dealing with that myself. In my case, the leadership of our company was convinced by a consulting firm that Salesforce is capable of anything, including acting as IaaS for a huge SaaS application we are building. The result being that we have to make very expensive work arounds for API call limits.
The hard part about this is that it might function eventually, so "there is no reason to switch until we KNOW for sure". Salesforce can do a lot, but it can NOT do IaaS. Use AWS, GCP, or literally anything else if you want a 100% customizable autoscaling application with in depth monitoring.
EDIT: Pardon my cry for help, but if anyone has any business targeted material to present these ideas to company presidents who don't have a clue in the world, I implore you to point me to it.
I work for a small consulting company specializing in SF custom development. About 1/3 of our projects are coming in and fixing something other consultants screwed up. It's very expensive and I really feel for the position our clients are in. The governor limits are particularly nasty, you have to be constantly aware because they won't bite you in development since you're usually working on a limited set of data. It's only after a production deployment do they begin to show up and there's nothing you can do.
funny you mention Salesforce as IaaS, a buddy of mine works at one of the big firms and was telling me the other day he's on a project where the client is layering a multi-tenant architecture on top of Salesforce's Community Cloud product and basically reselling communities.
I'd kick such a consultancy out of the door on the first instance of such an advice. For this kind of stuff some tech strategy consultancies are required,not the ones that implement it. I'd stay away from the big ones(i.e. Accenture), irrespectively of the company size. Salesforce is great but it is definitely not for everything.
Its more of a development platform and data ecosystem than ERP. Salesforce has yet to acquire an Accounting system to perform general ledger functions.
Sounds like I'm a Salesforce shill here, but...for some context I presently work as a developer in the charitable/volunteer sector at the moment. I'm 52, with around 30 years in the biz building all sorts of stuff in COBOL, Clipper, Java, CORBA, VB, C#....and worked with all sorts of databases.
Here's my take in my current situ:
Salesforce do some mighty decent things for voluntary/charitable orgs. One of them being that if you're a charitable/volunteer sector operator you get Salesforce Enterprise edition for free. Now, despite being aware of Salesforce, until about six months ago I'd never used it, and thought "oh-oh" when a project went down this route.
But you know something I kinda like it.
I sense some "dislike" here about Salesforce here on HN, and sure it has some road humps and other things, but it's become a developer platform, and with many developer platforms you need to spend some time learning to make it work for you. But it's not that hard. I think their docs and training material are pretty decent. We also use their SFDX bits so basically we can check in an entire org to source control and run deployments into sandboxes for testing before deploying into production. Their Visual Code tooling is pretty decent as well.
Lightning, Apex, Callouts, Creating inbound REST API's...what's not to like if you can bish-bash-bosh something for a client quickly and build an working MVP?
We can build a bunch of apps for these voluntary/charitable folks fairly quickly and much faster than we could with .NET/SQL (or something else) which would otherwise cost them a lot more money.
I realise it's not for everyone, sometimes it feels a bit "Scientology"'ish once you're into the eco-system, but it's a tool.
Salesforce is fine if you use it for its intended purpose like e-commerce. Just don't try to use it as an AWS replacement for an application platform just because "all your data will be in the same place". Everything is a tool, just pick the right one for the job.
We use Salesforce for some stuff because we don't need the overhead of AWS/Azure etc. It's quick (and some might say "dirty") but it suits certain types of work we do. And customers are happy. It's all about paying the bills.
I've implemented Salesforce twice for non-profits doing fundraising. It's probably a great B2B sales platform, but it's not that customizable for purposes outside what was intended. And it's not clear why some bits are customizable and others aren't. I don't consider myself a Salesforce expert, so maybe I'm just showing off my ignorance here, but this is a conversation I've had to have:
Fundraiser: "Can we have a custom database of Thing X that interfaces with everything else?"
Me: "Sure, no problem."
Fundraiser: "And can we rename this default field from 'Widget' to 'Doodad'?"
Me: "Nope. Impossible. Whenever you see 'Widget', just imagine it said 'Doodad'."
I still recommend Salesforce to non-profits, for the same reason Churchill recommends democracy: it may be the worst CRM, but it's better than all the others that have been tried.
To add to it a bit: Your experience is not uncommon. I think Salesforce GREATLY oversells the "clicks not code" stuff. They're good at selling to a certain segment within organizations that thinks of themselves as savvy but don't really know anything about what it takes to launch a CRM for an organization (not saying this is you, just in general from what I've seen).
I've seen projects blow $1M+ in grant money on adopting Salesforce that have virtually nothing to show for it because the projects were badly managed and poorly resourced. It's unfortunately more common in the non-profit space, too.
Thank you! I've been wondering about what the heck Salesforce is for ages :)
Seems like a lot of enterprise software boils down to integrating enterprise data for a some domain, mapping it to an ontology, and then building a plugin framework, dashboards, alerts and workflow management on top of that. (I don't mean to imply it's easy, just that it's a successful general template if you happen to have domaine expertise in a domain without a dominant existing SaaS player.)
In my experience, Salesforce is replacing emailed excel files and “excel as a database” en masse. It’s kind of interesting to watch these migration of business processes from manual excel to manual salesforce. And it’s not just sales people.
It has its uses in enterprise environments but it takes a special kind of business-y person to setup, configure and maintain.
I worked at a small startup with at its peak 30 people (of which 10 in sales/marketing) and we implemented Netsuite which is a similar ERP suite bought by Oracle.
It took 2 expensive consultants a couple months to setup and I believe it did CRM, invoicing, accounting, taxes, prospecting, email signups and newsletters, customer support, inventory tracking and probably a few more things. Every time we wanted to change some process we had to bring the consultants back in. In my eyes it was too expensive and too early in the startup process to be implementing something like that.
My own experience in e-commerce was that Salesforce came in to a couple of companies I worked at and it wasn't a fit. Which was weird.
I recently looked for a platform for CRM, invoicing, project management and communication, and Salesforce didn't really have anything out of the box (or within a reasonable distance of a read-to-go-box) for that either. There was little off-the-shelf available... not even starter packs, which I found a bit curious.
Ended up going with Accelo, which I think of as one level up from a bare Salesforce install.
My conclusion.. albeit not entirely informed, is that I probably am happiest never working in a company, or with a client, that's oriented around Salesforce processes.
I was tricked into doing SFDC development for a while, about eight years ago. I had a background in more “traditional” application development: Java on the back end and Javascript on the front end. Working in Salesforce was honestly a pretty miserable experience. Everything you do in it is metered; you have a limit on the number of DB calls you can make in an hour, a limit on how many bytes you can access in an hour, a limit on how many rows you can save… it’s almost as bad as AWS, but nowhere near as manageable because you can’t tell if you’re going to hit a limit until you hit it in production. At least back then, there was no interactive debugger for Apex, and no test client for SOQL (their “almost SQL but not SQL” query language), so any debugging you wanted to do was done using print statements. And of course, you couldn’t run anything locally - everything had to be copied up to their servers in order to something as trivial as test a form validation. I slogged through it for about 3 years before I finally gave up on it - although it does a good job of making simple things like creating input forms for database object easy, it makes harder things like an actual business workflow impossible (it’s noteworthy that even the CRM functionality wasn’t implemented in “pure” Apex/VisualForce because it was too limiting even for the thing that Salesforce was designed for).
From the impression I got reading OP's article, Salesforce is intended mostly for companies that can hire a dedicated Salesforce admin (or two) who can really set everything up exactly to your company's specifications, which means that smaller companies that don't have the resources to do that would be better off with one of the less-flexible CRMs/ERPs out there.
In the Mule ecosystem, you use a drag-and-drop flow builder of canned components to build flows that typically ingest events, do something to them, and possibly write someplace. Almost anywhere, you can also inject your custom code.
You deploy these flows in their engine, where they're kept alive. You can self-host the engine, but they also offer it in their cloud.
Then you can choose to frontend it with a HTTP API that you build in their builder, and choose to put it in your organization's private store, or the public store for others to use. There's management dashboards too.
There's hundreds of other products or product combinations that could be described in the same sort of vague language, but MuleSoft ships and supports a particular environment and a particular collection of tools that does it pretty well.
Ultimately, the goal of all of these is the reduction of the effort around every other piece besides the parts that are custom to your unique circumstances.
I believe they are in EAI - Enterprise Application Integration space. Broadly speaking this is a "swiss army knife", if you want to take a CSV file from an FTP site and load it into a relational database, then do queries off a table and POST JSON to a webhook, It can do any of those things.
Depends on what part of Mulesoft your talking about.
Traditionally it offered an Enterprise Service Bus solution but has been moving to an interesting collaborative API Management/Development solution over the past couple years. They really sell the idea of using an API network to hook up your integrations and then use Mulesoft's product to manage it.
Good article. Thanks for disentangling the jargon around Salesforce. I've always wondered why the idea of "CRM" never extends to more than the "Sales" process. What about more lightweight, easy-to-use system that someone who just opened a flower shop, or a yoga studio, could use to manage not just customers but also their employees and contractors? Why don't people use "Personal CRM" tools to keep track of conversations around the work-place, or interacting with employees? There is a lot of potential for a "contact interaction system", with many many use-cases, but I'm curious if the idea just doesn't have legs, or if it's waiting for something to popularize the concept.
Personal angle: I work on such a 'contact interaction system' with an app I have in the App Store, and though I market it as "CRM", my goal is to build something that's very easy-to-use so that "anyone" can use it, for the people who are looking for a good system to manage their contact and customer interactions. I would love to figure out how to drive more traction around the idea, since it's something that's beyond the regular idea of "CRM app for sales". Any thoughts?
Salesforce has begun retroactively restricting the products you can sell if you're using their platform, which makes moving to Salesforce a very risky proposition.
I appreciate it's a hot potato in the US, however in my opinion these kind of thigs should only be sold to military,in which case no CRM is required,as there are only a handful of countries as potential clients.I used guns for many years and can't see a single reason why anyone would need it for personal use.
That is not at all how the defense industry works.
The military invented modern procurement, of which sales is an important part.
There might only be a handful of countries any one country will sell to (50-75) but each country will have multiple armed forces, potentially hundreds of police departments, government agencies etc. etc.
Then there are private companies that may be allowed defence related tech, such as non lethal area denial equipment for shipping or oil in hostile areas.
>I appreciate it's a hot potato in the US, however in my opinion these kind of [things] should only be sold to military
You "used guns for many years" - OK, I suppose that makes you an expert on self defense choices in the US.
The DoD released a report that found the AR pattern rifle to be the absolutely most appropriate personal defense weapon that exists today - why do you or SalesForce get to decide what is appropriate for my personal protection?
The only real question here is why would I ever want my CRM company to make decisions like that for me or anyone else? Should I want my CRM company to care at all what I'm selling? Why would you ever assume it stops at things you personally don't like?
There are many reasons why they might not want gun manufacturers using them and one of them being that it doesn't fit their marketing agenda. The image they are painting is that it's a nice,inclusive, supporting and charitable company where the sky is is the limit for anyone.And suddenly its like: oh that nice and soft helps to sell guns? And that's what they keep communicating to the world.I understand it's BS but they seem to be willing to drop some account to make sure the bs becomes more believable.
As for self defense part-no,I'm not an expert on the choices in the US but I'm pretty sure there's plenty.
DoD may be right, however what are the circumstances? If I'm in highly populates area,the use of AR rifle can result in lots of collateral damage if not handled well. It is also very impractical to carry, especially if your job is not in military or security. Does AR rifle stops a potential threat well? I have no doubts of it, however it's practicality remains a huge question mark...
I didn't say I don't like guns,I just think it just doesn't make sense to have such rifles for self defense. I appreciate the US may not be the safest place on the planet,but just realistically what kind of potential attackers one would expect to stop with it?
I’m going to leave the rifle stuff alone because you seem to have very little in the way of actual knowledge vs myth and misunderstanding. The very minimum you could do would be to learn about destabilization and over penetration of ball 9mm compared to 556.
I’ll ask simply, again, why would you ever assume it stops at things you personally don't like?
It doesn't stop and it's not that I don't like,I don't understand it. You just ignored all my questions and went on about penetration..It would be interesting to hear your opinion,maybe I'm missing something.
"If I'm in highly populates area,the use of AR rifle can result in lots of collateral damage if not handled well."
Use hollow-point rounds instead of full metal jacket rounds to decrease penetration. But the problem is usually overstated anyway. See [1][2] below.
"It is also very impractical to carry, especially if your job is not in military or security."
Get an AR-15 "pistol". [3] You should be able to fit one in a decent-sized backpack. Some of them have barrels as short as 7 inches. If that's still too big, separate the upper and lower receivers. You'll just have to spend a good 30 seconds reassembling the weapon before loading a magazine.
"but just realistically what kind of potential attackers one would expect to stop with it?"
Looters attempting to destroy your business and livelihood, for example [4]. And that's not a problem restricted to the US; violent looters are a worldwide problem. Rural farmers being lynched for ethnic or economic reasons in Africa would probably love to have a semi-automatic weapon to even their odds against numerous attackers armed with (presumably) edged weapons or pistols. [5][6]
The perpetual problem we see with gun control advocates is that they extrapolate from their experience living in metropolitan areas with far higher law-enforcement densities, push for laws that affect EVERYONE, and then end up depriving people in rural areas from the tools they actually NEED to be responsible for their own safety and security.
The problem isn't the guns (I'm all for banning them), it's that they're becoming the morality police and moral crusaders are always looking at what's next. This is unelected, unrepresentative corporations taking over the role of governments and effectively deciding what's legal and what isn't.
I worked 2 months for a IT company that uses 100% salesforce. It was the worst experience of my life. The tool can be great for the sales team and others, but keep things separated, salesforce shouldn't be used by programmers.
Also, they use SF for Dreamforce planning end to end. I've seen it, it's pretty freaking amazing. I was convinced they were going to release a "Conference Cloud" product after I saw what they had done for organizing Dreamforce.
Real Estate, Investor Relations, HR, Anything with an Approval Process... If you ever have a chance to attend a “Salesforce on Salesforce” session, take it. Or better yet, just ask for one if you’re a customer and want to see how they do a thing.
Was reading about it quite recently and tbh was a little bit surprised, especially knowing that behind the scenes is one massive JAVA superjob with millions of lines of code...It must take some effort to maintain the whole thing..
How long does implementing Salesforce takes usually, lets say in a company with 10 users(salespeople?)?
I have implemented 10-13 SAP Saas ERP systems in last couple of years and the projects are around 2-4 months with 1-2 consultants working on the project for a company of ~50 users. But ERP is much wider then just CRM, it includes all business processes.
Can Salesforce be self implemented by the company or is consulting needed? ERP cannot be self implemented, definitly needs consulting both on configurating the system and also changing companies business processes.
Its still amazing how Saas EPR can be implemented in this short time given it used to take atleast 1 year due to the need of setting up infrastructure and all over more complexity.
I've done 20+ implementations over the last 6 years for small (8 person non-profit) to large ($2B revenue, 5000+ users) organizations.
I still find it hard to estimate implementation times, and I think most people greatly underestimate the time and resources required.
In your hypothetical sales organization with 10 users, I would estimate 2-4 months depending on how completely you want to migrate your business to the platform. You need time to work with leadership to outline broad strategic goals for the new CRM and to sit with end users to actually translate their existing processes onto the platform. This might take 1 or 2 consultants working 20-30 hours/week.
I understand my bias here, but I cannot recommend finding an implementation partner (consultant) enough. Half of my work is fixing terrible half-implementations done internally by the "tech guy" that no one wants to use.
If it covers just sales and there's no complex requirements,you'd be up and going in a couple of weeks,maybe in 3 if there's lots of back and forth. However,if there are plans to implement CPQ or some integrations,then it'd be much longer. CRM can be self implemented, however if the company doesn't have a dedicated resource I would not recommend it, especially if there's any potential for growth,as it's very yeasy to make a spaghetti crm as well..
I do a lot of SF community implementations in the range of 10-20k users. My projects are typically 4-6 weeks with a team of maybe 5 on average. Granted, we're a small company with very very good talent. There's no way an Accenture or PWC could do what we do in the same timeframe.
Well for starters the product is smaller and not that extendable. So it means when typically with on-prem you start developing and customizing the software to fit it into company procedures then with Saas ERP company needs to fit into ERP processes.
The UI is based on HTML and therefore users like it more and are not that hesitant to start using it and less training is needed.
Public API-s that you can just take and make integrations, no need for allowing access through firewall etc.
There are many more but these are just some that I can think of right now.
has salesforce figured out how to do an arbitrary number of objects yet? For example a customer with as many addresses they want? I was told by very expensive salesforce "experts" that wasn't possible a few years ago. You actually needed to hardcode address_1_zip, address_2_zip, address_3_zip and so on.
This is the correct way to do it, but this also means you are going to add another custom object to "objects needs to be documented and maintained by your team" list.
more importantly, it means one less custom object available based on your license. For example, there's nothing stopping you from making 100 custom object available to Customer Community licensed users. However, with the license you get 10 and when they randomly audit your instance find you at +90 the bill will be shocking to say the least. Pay up or get your instance turned off and lose everything.
"with the license you get 10"
Questioner didn't stipulate the license they were on. The SF folks I deal with have enterprise licenses (200 custom objects) because SF supports a core part of the enterprise (the revenue side of things). With that there's a certain set of norms that happen and my suggestion is a simple approach to the problem.
"Pay appropriately and do it the right way"
If you're looking for the cheapest solution or the "just getting by" solution don't use Salesforce or you'll get some nasty surprises.
Yeah .. only real downsides are above:
* You have a certain number of Custom Objects you can use which cost $X
* There's a maximum total you can have (not to be exceeded)
* It's another thing to watch / maintain / document
* The land of custom objects and fields can get polluted so .. hopefully you have decent governance in place.
I've been doing some Salesforce dev for a company for about 6 months and as far as I know, this is really still the case. There are ways to do a type of reference that mimics foreign keys and sql joins, but it is terribly convoluted and therefore confusing.
SF has what must be the most valuable database in the world. It must be worth far, far more than their market cap.
That I have not heard of anybody mining it must mean they have a really good handle on how to keep such activity secret. Because from a business standpoint it would be irresponsible not to monetize something so valuable. Anybody using it must realize that has to be going on, at some level.
Maybe they only license out access to spooks -- NSA, Mossad, GRU. (What is the Chinese one called?) Those have access to unlimited cash, and know how to use spooking to get more.
An entire economy is built around Salesforce. For every dollar that Salesforce makes, its ecosystem generates $4. Millions of developers build apps for Salesforce’s platform, and Salesforce development is itself a lucrative niche within software engineering.
So Salesforce has turned themselves into an ecosystem. No wonder they're doing well. What's the secret to turning yourself into an ecosystem? It must involve low barriers to entry and the ability to make money within the ecosystem.
"Single source of truth" = loaded statement. Maybe single source of truth for a certain subset of things, but in my experience, Salesforce is absolutely not the single source of truth for an organization. I do not like that marketing pitch.
> In 2008, these were consolidated into Force.com — a platform for developers to build and run apps without worrying about infrastructure. It was the first platform-as-a-service (PaaS).
Heroku launched before Force.com - by a few months, if I'm not mistaken.
The way this article described Salesforce makes it sound like generic database frontend software, like a more powerful, complex, and customizable Airtable. I'd love to read a comparison of the two if anyone has used both.
From a business side of things, the advantage of Salesforce is that it can very easily be managed by non-devs. It has straightforward sales functions baked in: reporting, forecasting contact management.
For sure, Airtable can be used as a lightweight CRM. Depending on your business, it might be all you need -- it might even be preferred if you're bootstrapping and constantly iterating early on! But Airtable falls down when your sales/marketing needs grow -- those hires probably won't have the patience to develop tools that tie into Airtable.
To reference the old Jim Barksdale line, Salesforce is the "bundle" option, and Airtable is the "unbundle" one.
The main thing with Salesforce, or SAP, or other software of the sort, is the ecosystem and knowledge that´s tied up with it.
You can do most things you can do on Salesforce with generic software, but the know-how is explicit on Salesforce (think Open Source vs Microsoft). There´s also the backing, support, etc., and them being the original SAAS which I guess is the BIG part (that must have been some pretty huge savings back then).
There´s a team of Salesforce devs working next to where I do, and it does look very much like any other database frontend software, but with the sales vertical. Instead of choosing Java or .NET or whatever, they go Salesforce.
wow, great article! i work for a university and our admin group needs a "killer app" for tracking students, researchers, faculty, industry partners, events, and a bunch of other little things... i've been doing my best to try and explain to them what SF is capable of but it's been tricky as i don't have any first-hand experience w/it.
i've forwarded the article off to them and the entire group had a collective "ah-ha!" moment. thanks for putting this together. :)
When I was applying to grad schools in 2016, the online applications all sat on top of a Salesforce build. It's clunky to build on for sure, but there has to be trade-offs when you're using a pre-designed "lego blocks" type system to build an app.
You can sign up for a free SF developer account, which gives you access to a dummy account that can support 2 users. Go to Salesforce Trailhead, their training site and look at the modules to figure out which one might help you create a prototype you can use as a proof of concept for your team.
We came second pitching Salesforce to a uni in the UK,which was supposed to cover all these aspects you mentioned.If you interested,drop me a message,I can guide you towards the right direction.The company we lost against did about 400 implementations for universities and schools.
I was a sceptic, but it’s actually great. The amount of powerful stuff you can do with it, with process builder, platform events and flows, e.g. is incredible. Still super annoying in a lot of ways, but it doesn’t really make any sense to manually build out that stuff, to me anyway
I see what you did there - Nice puff piece to get the Salesforce corpdev drones to start buzzing around you guys to lay the seeds to an eventual acquisition ;)
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.)
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.
> 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".
Pretty much anything that Salesforce does, Dynamics 365 does too, so perhaps not the best screenshot of a bread and butter CRM system.
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.
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!"
D365 is used to provide a large variety of apps hardly any of which are CRM, so the name change actually makes sense for once.
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!
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.
You weren't wrong!
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.
(Microsoft employee here, but I don't actively use or work on the PowerApps product myself)
As someone working with CRM software (although not Salesforce), I’ll just say you’re welcome.
I don't want to ban you, so would you mind reviewing https://news.ycombinator.com/newsguidelines.html and using the site as intended?
- develop locally. - easily backup using source control. - contribute to or create open source projects easily. There are a lot more barriers to do so compared to JavaScript or Golang communities.
In addition, I'm always working with sugar-coated Salesforce tech. Apex (kinda like Java), Aura Components (crappy js framework that doesn't even come close to react).
I'm happy that Salesforce is going in the right direction with their web components, but it still feels like they are 10-15 years behind.
>- develop locally. - easily backup using source control. - contribute to or create open source projects easily.
It addresses all of these concerns nicely.
I'm also a full-time SF developer and am finding the transition to DX a bit rough, to be honest.
I'm a contractor as well. You know, there's a ton of legacy shite out there that isn't greenfield and you just need to get in there and guddle (Scottish word) about to earn the bucks. Sure I'd love to work all day long with .NET Core (or even .NET 4.7), but I also need to maintain a bunch of crap that dates back to 2006 and written in .NET 2.0. But as a contractor I kinda get on with it. It pays for my hobbies (model railways and building analogue synths, growing chillis and other stuff), so I kinda just suck it up because the rates are pretty ok.
And you know, there's no shame in being a maintenance dev, some of the best devs I've met are looking after ancient crap long after the overpaid, unsupervised "superheros" that dug those holes moved on to their next 1000% glory roles, and we have to mop up afterwards (for a tidy hourly rate).
I understand this 100%. I often end up using ForceCode (https://github.com/celador/ForceCode) for the get-in-get-out projects.
It sounds super limiting and frustrating ?
It also sounds like very non transferable skills you’re learning which might be difficult to use in other roles ?
It's limiting and can be frustrating, yes.
Apex and aura components are not transferable directly, but what is is learning how to work with enterprise software. Plus, my bred and butter with Salesforce work is integrations, which has given me plenty of opportunities to learn other languages as needed to get the work done.
https://www.linkedin.com/pulse/stabilizing-salesforce-lightn...
If I created an angular app here, a react app there, and elm lang app over there, you are dramatically increasing the overhead to maintain the org. IMO, it's better to play it safe by using Salesforce's tech stack so your client has an easier time maintaining their org in the future. Future Salesforce devs will thank you too :D
Plus, there is a very high chance that future interviews for Salesforce dev gigs, they are NOT going to ask if you know React/Angular. Nice to have skills for sure, but they want to know how quickly you can get started working in their org. And chances are their apps are built with apex, Visualforce, or aura components. I'd rather spend a year building with aura components to make my new project transition easy, than spend a year building with react and have to pick up aura components all over again.
Get a couple certifications. Once I got 3-4 and a few years of experience, recruiters approach me on regular basis. FYI I have no college degree. Companies don't care. Certs and experience are worth more than any degree in the Salesforce space.
I've done some Salesforce work n the past, on a booking system that needed to read/write with their Salesforce instance. Their Salesforce dev spent a lot of times in our office during the build, and after a few drinks we were chatting about prospects as a Salesforce dev.
He pretty much echoed what you said - it's a different world to standard dev, and you can go quite deep into their ecosystem, but the work is always there, and a good Salesforce dev is worth his weight in gold so companies will bend over backwards to accommodate you - including paying your named price. It's depressing to write, but he probably earned 3-4x my salary for doing work that seemed pretty easy to him, and a quick glance on LinkedIn shows that he's still doing Salesforce work now.
From a cynical and maybe overly negative point of view, it felt like Salesforce developers are kind of like contracted mafia enforcers. As long as the devs play by Salesforce's rules and do a decent job (i.e. make Salesforce salesmen money), they throw them free, lucrative, repetitive, braindead, unfulfilling business. In our case, they literally couldn't screw up - we had to use them, and no amount of complaining to our Sales guy or trying to understand why the main engineer was such a kook was going to change our situation.
Seems like a really lucrative hustle to get into, as long as you don't mind dealing with absolute mediocrity.
Plenty of devs work with specific products as these products are used by many companies. I know lots of ERP developers that make very good money scripting customisations into ERP systems, it's a pain of a system but you're right at the heart of the business working on very high value contracts.
focusonforce.com is nice.
Best book I've read on learning the how to build with Salesforce using clicks over code is: https://www.amazon.com/Practical-Salesforce-Development-With...
There are efforts for all those things, but it's still painful.
develop locally: they're bringing at least front end development here.
source control: easily done if you are using the DX project format.
apex: still shitty
aura: deprecated and replaced with LWC.
It really pissed me off since I have a long and trusted relationship with this client, if i can't give her a ballpark on licensing costs for some feature portfolio then what good am i as a consultant? God, it still pisses me off to even think about.
hide details and nickle and dime (if 20/k/year is a dime) is another.
The main issue with garbage companies like Oracle and Salesforce isn't that they charge... or that they charge a lot...
It's that the REAL cost of using their garbage is hidden and obfuscated and difficult to pin down.
https://www.contactmonkey.com/blog/salesforce-pricing-hidden...
Someone has to pay for that thing sticking out of San Francisco
For us: sales, account management, support, marketing, even some engineering need licenses.
I don't have experience with many systems, but I'd assume the accounting departments need access, as well as customer success/tech support departments.
What a weird sentence to write but at least in my experience with IT/engineering so much stuff ends up being bought that, although it's is usually nice, would never stand up to scrutiny if we had to justify business value.
And I want to stress how big and clunky SFDC is even for people familiar with it. I am sure everyone and their mother can build a faster, more elegant CRM. But that misses the point. It's infrastructure. The fact that it's legacy is the feature! I'm sure we can design more elegant roads and pick smarter rail gauges today, but having consistent and interchangeable standards is important to build on. It's enough for a company to constantly track their changing market, they don't need to risk losing customers because they upgrade the CRM every couple of years.
FAANG is just about de facto monopolies too big to compete with, so I don know what parallel you draw on.
Also, you can expect sales hires to know salesforce.
My recommendation is to set aside time to play with a lightweight (pipedrive) + heavyweight (Salesforce) options to see how you might use them one day. I would treat CRMs like a regular piece of software. Many offer totally free trials for 1-3 users. So I would bet they agree with this approach :)
[0]:https://en.wikipedia.org/wiki/Comparison_of_CRM_systems [1]:https://www.pcmag.com/roundup/253275/the-best-crm-software
Four of them successfully ran a SFDC consulting business for several years with many good clients and lots of junior and senior developers and architects (I joined briefly after leaving SF Bay Area but decided I should go back to building products). The business ran into family-business-squabble problems between two of the principals and dissolved ... however they all stayed in the SFDC game and have done very well, making significantly more (even considering they're contracting) on long-term stable contracts than their software experience would net them at established SF Bay Area companies ... and they all live in much lower cost-of-living areas. I don't think the SFDC game will go away any time soon, either.
There are probably some interesting SFDC development niches, but I would have struggled to maintain interest.
But it's great to put your sales process on for a slightly techy person. Sort of the modern equivalent of access.
Needless to say, that means no developer wants to touch it with a bargepole.
So if you're prepared to put up with all that, you can make a lot of money doing ridiculously simple things.
The tech is proprietary, and not that fun to work with. [0]
As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.[1][2][3]
But, I still 100% recommend Salesforce to companies when they ask about it. Why? Data liability. Yes Salesforce is expensive - but you are outsourcing the responsibility of dealing with sensitive data to Salesforce. This is something that they should market more heavily in imo. (at least to sw engineers and CTOs) Realistically many companies are not properly equipped to deal with data, let alone sensitive data. Salesforce may have started out as a CRM, but now it is a solution to that problem. CTO's now have someone to point the finger at if shit hits the fan on an Equifax level. This alone is worth big $$$.
[0] - https://insights.stackoverflow.com/survey/2018#most-loved-dr...
[1] - https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...
[2] - https://developer.salesforce.com/blogs/2018/05/summer18-reth...
[3] - https://developer.salesforce.com/page/Multi_Tenant_Architect...
[4] - https://trust.salesforce.com/en/
That's a very kind way to say: everything in it appears deliberately engineered to ensure continued employment of consultants. :)
Salesforce is built on mutually beneficial relationships. If you go under, they lose your business. If you grow, they make more money selling you more seats.
It's exactly what business should be.
And I don’t have time or room to get into how awful Salesforce documentation and support are if you try to implement anything yourself. As far as I can tell, the reason they tell you to hire a consultant is that only the consultants have the experience to know the literally unwritten rules.
When I really tried to pin them down on some of these implementation questions, the Salesforce folks actually said “well, we don’t recommend self-implementation”. So when you read all that stuff about it being a development platform, be aware that means for consultants, not you!
So if they’re being paid to develop trust...well, that’s the opposite of what they did.
https://i.imgur.com/wlKkBmP.jpg
> As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.
True. But Salesforce allows fairly non-technical people to build fairly robust applications with very limited CS training. If I were interested in getting a technical job but had no experience, I'd consider becoming a Salesforce administrator as a way to get paid to learn to code on the job. [1]
You can build something that is complex and scalable without any programming experience. And what you build will be supported for the next ten years. It's not a terrible proposition for most businesses - especially outside of the Silicon Valley bubble.
[1] https://bluecanvas.io/blog/2017-07-25-getting-paid-95k-to-le...
While SF may or may not be the right solution for a problem, I disagree with your assertion that developing for Salesforce will in any way prepare you for a "real" programming job.
You would mostly learn how to configure a lot of UI, maybe write some custom widgets (with Lightning), and write a a little bit of integration code here and there - in an arcane Java-like language.
All you really learn is the Salesforce ecosystem.
You can make very decent money if you can sell yourself. As others have mentioned, Salesforce could be seen as a sophisticated employment scheme for consultants.
But I would advice anyone to steer clear of it as a career path. At least until you have some proper experience in other technologies.
Lightning was what I was referring to with "custom widgets".
Ok. BUT... when those limited CS training people want it done right, they hire any one of the huge middlemen do make SalesForce integrations and modules.
ATG is one I know of first hand. Hiring tons of people to make SalesForce suck less. Mostly sales people themselves, then some programmers to do the real work.
This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.
Think of the other tech companies over the years that have seemed like behemoths to be utterly knocked out by someone that came in and sucked less. What do you think happened to the industry of Certified IBM Professionals that relied on IBM being market leader in PCs?
It's worked for hundreds of thousands of people who make a living from turning raw Access/Excel/Wordpress/Microsoft CRM/Dozens of other products/etc into custom applications that solve the needs of particular business processes.
Every business has its own warts, that no one-size solution is going to solve well, and that will require someone to write a plugin for an off-the-shelf business product.
Outside of the Silicon Valley bubble, most software engineers make a living doing just that.
This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".
The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.
The result of these rewrites is generally something with fewer features, an unfamiliar interface, and more bugs than what preceded it. Joel Spolsky has a nice article about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.
1. The people who built the system didn't know how to do things right the first time.
Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.
Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.
2. The problem is actually incredibly complicated, and has no clean solution.
Solution: Don't do anything.
Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.
3. Most of the system is actually fine, there's just a few bad parts.
Solution: Refactor the bad parts.
Non-solution: Rewrite the whole thing, even the parts that are maintainable.
--
I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.
This isn't to say "never rewrite". I am saying we rewrite way too much now.
peak hn
Historically, this hasn't gone well. I'm sure many Software Engineers here can attest personal anecdotes to that.
> peak hn
I believe that are saying that this this is the epitome of what HN has become. ( what they believe to be non-software engineers discussing things. )
While I don't encourage gatekeeping, I think anyone can become a software engineer if they read the right books and spend enough time. I had a similar sentiment about seeing the line:
>> fairly robust applications with very limited CS training
This is an oxymoron. Non-technical people simply cannot build 'fairly robust applications' for reasons they quite simply don't understand. Building robust applications is way more than making it work. You also have to make it maintainable and scalable. Salesforce code I've seen written by people with 'very limited CS training' is neither of these.
What I have noticed in recent years is that they have been trying to be more open when it comes to their development process, and empowering to open source developers building stuff for their platform. I built a Prettier plugin [0] for their proprietary language Apex and received a lot of support from them. Hopefully that means their ecosystem will get less "enterprisey" in the future.
[0] - https://github.com/dangmai/prettier-plugin-apex
Bret Taylor is a modern tech product guy. He led Google Maps, was CTO of Facebook, etc. He's completely altered the DNA of Salesforce and made it a modern tech company.
- It is opinionated so teams no longer have to debate about coding styles. It is a refreshing change once you get used to that mindset. IC2 formatter has many configurations that developers can tweak, but that means you as a team need to debate within yourself which one(s) to configure.
- It is a CLI tool. That means you can do things like: run it as a linting tool on every commit to enforce coding styles, run it as a pre-commit hook, auto format files when you save in your IDE, etc. IC2 is closed source, and as far as I know there's no easy way to run it in a headless way.
- It is free.
- It is open source and has been tested on millions of lines of code. If you're using an open source Apex library, chances are it's part of the integration test suite, see [0]
- It is written specifically for Apex/SOQL/SOSL. That means it knows the context of your code and can format based on that. Tools like Uncrustify technically do work on Apex code, but it is being parsed as a generic C-like syntax so a lot of things do not work right (especially when Apex moves farther away from being Java-like).
- It is blessed by Salesforce, and their official IDE (VSCode) will soon adopt Prettier as the formatting tool of choice.
Those are just a few reasons. Prettier has a dedicated page [1] for everything else that also applies to this project.
[0] - https://github.com/dangmai/prettier-plugin-apex/blob/master/...
[1] - https://prettier.io/docs/en/why-prettier.html
This is precisely the reason why my organization, a large Canadian FI on the commercial banking side, decided NOT to go with Salesforce. They couldn’t rationalize giving up the data and went instead with a MS Dynamics implantation. This was 10 years ago.
In the sense that my car is just a hunk of metal with four rubber tubes attached.
Seriously, can we please stop these lame attempts to distill extremely complex systems into overly simplistic models using "this is just an X with some fancy Y" type analogies? They don't really contribute anything to the conversation.
They may offer tools related to it but any flaw or issue that exposes your data is still your problem. Remember the trouble Amazon got into for all those data leaks over publicly visible S3 buckets? No? Why would they? Exactly.
Even just from a data management standpoint, they have a business template that is much better than what could be implemented internally.
But after reading "Bullshit Jobs" [0] I think it's more than that - It's more about culpability and plausible deniability of decision makers in companies. Many companies have a CYA (cover your ass) culture. The higher up you go, the worse it gets.
When faced with a challenge that needs to be solved by tech, people in these companies have two choices: 1. Build it out internally, 2. Use Salesforce.
Salesforce is an incredibly safe choice for these type of decision makers. Because if shit hits the fan on an internally led project approved by them, they are associated with that failure. It effects their career trajectory. If something goes wrong with Salesforce - overbudget, data leak, etc. It doesn't matter, someone besides them is first in line to take the blame.
Ever hear the phrase "Nobody ever got fired for choosing IBM"? [1] Salesforce has grown to the point where they are recognized as a standard across industries by non-tech people. I've heard people from small local non-profits all the way up to publicly traded fortune 500 mention Salesforce. Name recognition on this level is quite literally worth $billions in the B2B world.
[0] https://www.goodreads.com/book/show/34466958-bullshit-jobs
[1] https://www.quora.com/What-does-the-phrase-Nobody-ever-got-f...
I've seen this in action, so I know people are willing to pay for it, but it seems really shitty.
When used properly, salesforce provides valuable information and organizes and facilitates coordination around customer-related issues and initiatives far better than anything else that's generally available at the kind of scale it's used for.
The problems start when people who create tickets don't understand how things are supposed to work (because no one gets fucking training), and just end up jamming multiple problems into one ticket.
The hard part about this is that it might function eventually, so "there is no reason to switch until we KNOW for sure". Salesforce can do a lot, but it can NOT do IaaS. Use AWS, GCP, or literally anything else if you want a 100% customizable autoscaling application with in depth monitoring.
EDIT: Pardon my cry for help, but if anyone has any business targeted material to present these ideas to company presidents who don't have a clue in the world, I implore you to point me to it.
funny you mention Salesforce as IaaS, a buddy of mine works at one of the big firms and was telling me the other day he's on a project where the client is layering a multi-tenant architecture on top of Salesforce's Community Cloud product and basically reselling communities.
[0] https://en.m.wikipedia.org/wiki/Wardley_map
Oh the painful memories that phrase evokes.. VB6
Basically, it does for all of your business assets what a CRM does for your customer relations.
Here's my take in my current situ:
Salesforce do some mighty decent things for voluntary/charitable orgs. One of them being that if you're a charitable/volunteer sector operator you get Salesforce Enterprise edition for free. Now, despite being aware of Salesforce, until about six months ago I'd never used it, and thought "oh-oh" when a project went down this route.
But you know something I kinda like it.
I sense some "dislike" here about Salesforce here on HN, and sure it has some road humps and other things, but it's become a developer platform, and with many developer platforms you need to spend some time learning to make it work for you. But it's not that hard. I think their docs and training material are pretty decent. We also use their SFDX bits so basically we can check in an entire org to source control and run deployments into sandboxes for testing before deploying into production. Their Visual Code tooling is pretty decent as well.
Lightning, Apex, Callouts, Creating inbound REST API's...what's not to like if you can bish-bash-bosh something for a client quickly and build an working MVP?
We can build a bunch of apps for these voluntary/charitable folks fairly quickly and much faster than we could with .NET/SQL (or something else) which would otherwise cost them a lot more money.
I realise it's not for everyone, sometimes it feels a bit "Scientology"'ish once you're into the eco-system, but it's a tool.
Use it, don't use it, it's up to you.
We use Salesforce for some stuff because we don't need the overhead of AWS/Azure etc. It's quick (and some might say "dirty") but it suits certain types of work we do. And customers are happy. It's all about paying the bills.
Fundraiser: "Can we have a custom database of Thing X that interfaces with everything else?"
Me: "Sure, no problem."
Fundraiser: "And can we rename this default field from 'Widget' to 'Doodad'?"
Me: "Nope. Impossible. Whenever you see 'Widget', just imagine it said 'Doodad'."
I still recommend Salesforce to non-profits, for the same reason Churchill recommends democracy: it may be the worst CRM, but it's better than all the others that have been tried.
To add to it a bit: Your experience is not uncommon. I think Salesforce GREATLY oversells the "clicks not code" stuff. They're good at selling to a certain segment within organizations that thinks of themselves as savvy but don't really know anything about what it takes to launch a CRM for an organization (not saying this is you, just in general from what I've seen).
I've seen projects blow $1M+ in grant money on adopting Salesforce that have virtually nothing to show for it because the projects were badly managed and poorly resourced. It's unfortunately more common in the non-profit space, too.
Seems like a lot of enterprise software boils down to integrating enterprise data for a some domain, mapping it to an ontology, and then building a plugin framework, dashboards, alerts and workflow management on top of that. (I don't mean to imply it's easy, just that it's a successful general template if you happen to have domaine expertise in a domain without a dominant existing SaaS player.)
I worked at a small startup with at its peak 30 people (of which 10 in sales/marketing) and we implemented Netsuite which is a similar ERP suite bought by Oracle.
It took 2 expensive consultants a couple months to setup and I believe it did CRM, invoicing, accounting, taxes, prospecting, email signups and newsletters, customer support, inventory tracking and probably a few more things. Every time we wanted to change some process we had to bring the consultants back in. In my eyes it was too expensive and too early in the startup process to be implementing something like that.
I recently looked for a platform for CRM, invoicing, project management and communication, and Salesforce didn't really have anything out of the box (or within a reasonable distance of a read-to-go-box) for that either. There was little off-the-shelf available... not even starter packs, which I found a bit curious.
Ended up going with Accelo, which I think of as one level up from a bare Salesforce install.
My conclusion.. albeit not entirely informed, is that I probably am happiest never working in a company, or with a client, that's oriented around Salesforce processes.
You deploy these flows in their engine, where they're kept alive. You can self-host the engine, but they also offer it in their cloud.
Then you can choose to frontend it with a HTTP API that you build in their builder, and choose to put it in your organization's private store, or the public store for others to use. There's management dashboards too.
There's hundreds of other products or product combinations that could be described in the same sort of vague language, but MuleSoft ships and supports a particular environment and a particular collection of tools that does it pretty well.
Ultimately, the goal of all of these is the reduction of the effort around every other piece besides the parts that are custom to your unique circumstances.
Traditionally it offered an Enterprise Service Bus solution but has been moving to an interesting collaborative API Management/Development solution over the past couple years. They really sell the idea of using an API network to hook up your integrations and then use Mulesoft's product to manage it.
Personal angle: I work on such a 'contact interaction system' with an app I have in the App Store, and though I market it as "CRM", my goal is to build something that's very easy-to-use so that "anyone" can use it, for the people who are looking for a good system to manage their contact and customer interactions. I would love to figure out how to drive more traction around the idea, since it's something that's beyond the regular idea of "CRM app for sales". Any thoughts?
[0] https://www.monicahq.com/
https://www.theverge.com/2019/5/30/18645722/salesforce-ban-r...
The military invented modern procurement, of which sales is an important part.
There might only be a handful of countries any one country will sell to (50-75) but each country will have multiple armed forces, potentially hundreds of police departments, government agencies etc. etc.
Then there are private companies that may be allowed defence related tech, such as non lethal area denial equipment for shipping or oil in hostile areas.
You "used guns for many years" - OK, I suppose that makes you an expert on self defense choices in the US.
The DoD released a report that found the AR pattern rifle to be the absolutely most appropriate personal defense weapon that exists today - why do you or SalesForce get to decide what is appropriate for my personal protection?
The only real question here is why would I ever want my CRM company to make decisions like that for me or anyone else? Should I want my CRM company to care at all what I'm selling? Why would you ever assume it stops at things you personally don't like?
I’ll ask simply, again, why would you ever assume it stops at things you personally don't like?
You’d have to be very naïve to think that.
Use hollow-point rounds instead of full metal jacket rounds to decrease penetration. But the problem is usually overstated anyway. See [1][2] below.
"It is also very impractical to carry, especially if your job is not in military or security."
Get an AR-15 "pistol". [3] You should be able to fit one in a decent-sized backpack. Some of them have barrels as short as 7 inches. If that's still too big, separate the upper and lower receivers. You'll just have to spend a good 30 seconds reassembling the weapon before loading a magazine.
"but just realistically what kind of potential attackers one would expect to stop with it?"
Looters attempting to destroy your business and livelihood, for example [4]. And that's not a problem restricted to the US; violent looters are a worldwide problem. Rural farmers being lynched for ethnic or economic reasons in Africa would probably love to have a semi-automatic weapon to even their odds against numerous attackers armed with (presumably) edged weapons or pistols. [5][6] The perpetual problem we see with gun control advocates is that they extrapolate from their experience living in metropolitan areas with far higher law-enforcement densities, push for laws that affect EVERYONE, and then end up depriving people in rural areas from the tools they actually NEED to be responsible for their own safety and security.
[1]https://www.outdoorhub.com/stories/2013/11/04/ar-15-appropri... [2]http://preparedgunowners.com/2016/07/14/why-high-powered-5-5... [3]https://www.pewpewtactical.com/best-ar-15-pistols/ [4]https://www.thetruthaboutguns.com/koreatown-twenty-six-years... [5]https://en.wikipedia.org/wiki/South_African_farm_attacks [6]https://www.newsweek.com/zimbabwe-land-robert-mugabe-white-f...
Oh jebus....."Guns"
As a European, I kinda see that as a good thing. The harder it is to facilitate the transfer of guns into the hands of idiots the better we are off.
They use an app built on the force.com platform for managing all development work on their CRM product.
The app, free to install in your own instance and use: https://appexchange.salesforce.com/appxListingDetail?listing...
The largest built a 20bn+ market cap co out of it, in 12 years.
SFDC is far more capable than people think.
I have implemented 10-13 SAP Saas ERP systems in last couple of years and the projects are around 2-4 months with 1-2 consultants working on the project for a company of ~50 users. But ERP is much wider then just CRM, it includes all business processes.
Can Salesforce be self implemented by the company or is consulting needed? ERP cannot be self implemented, definitly needs consulting both on configurating the system and also changing companies business processes.
Its still amazing how Saas EPR can be implemented in this short time given it used to take atleast 1 year due to the need of setting up infrastructure and all over more complexity.
I still find it hard to estimate implementation times, and I think most people greatly underestimate the time and resources required.
In your hypothetical sales organization with 10 users, I would estimate 2-4 months depending on how completely you want to migrate your business to the platform. You need time to work with leadership to outline broad strategic goals for the new CRM and to sit with end users to actually translate their existing processes onto the platform. This might take 1 or 2 consultants working 20-30 hours/week.
I understand my bias here, but I cannot recommend finding an implementation partner (consultant) enough. Half of my work is fixing terrible half-implementations done internally by the "tech guy" that no one wants to use.
The UI is based on HTML and therefore users like it more and are not that hesitant to start using it and less training is needed.
Public API-s that you can just take and make integrations, no need for allowing access through firewall etc.
There are many more but these are just some that I can think of right now.
So ... if a contact should have N Addresses... create an SObject called "ContactAddress" .. and have a relatedlist from contact to N ContactAddress.
"Pay appropriately and do it the right way"
If you're looking for the cheapest solution or the "just getting by" solution don't use Salesforce or you'll get some nasty surprises.
That I have not heard of anybody mining it must mean they have a really good handle on how to keep such activity secret. Because from a business standpoint it would be irresponsible not to monetize something so valuable. Anybody using it must realize that has to be going on, at some level.
Maybe they only license out access to spooks -- NSA, Mossad, GRU. (What is the Chinese one called?) Those have access to unlimited cash, and know how to use spooking to get more.
So Salesforce has turned themselves into an ecosystem. No wonder they're doing well. What's the secret to turning yourself into an ecosystem? It must involve low barriers to entry and the ability to make money within the ecosystem.
Heroku launched before Force.com - by a few months, if I'm not mistaken.
You can do most things you can do on Salesforce with generic software, but the know-how is explicit on Salesforce (think Open Source vs Microsoft). There´s also the backing, support, etc., and them being the original SAAS which I guess is the BIG part (that must have been some pretty huge savings back then).
There´s a team of Salesforce devs working next to where I do, and it does look very much like any other database frontend software, but with the sales vertical. Instead of choosing Java or .NET or whatever, they go Salesforce.
i've forwarded the article off to them and the entire group had a collective "ah-ha!" moment. thanks for putting this together. :)
You can sign up for a free SF developer account, which gives you access to a dummy account that can support 2 users. Go to Salesforce Trailhead, their training site and look at the modules to figure out which one might help you create a prototype you can use as a proof of concept for your team.
I just want to say that I'm very grateful that I don't have to have anything to do with it.
http://whois.domaintools.com/failsource.com
http://whois.domaintools.com/salesforce.com