What's Salesforce?
tryretool.com
tryretool.com
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.
* 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
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...
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.
> 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.
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/...
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.
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?
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.