The platform is both powerful and pretty clunky. Salesforce development is consistently 20 years behind established best practices. Learning Salesforce means learning the thousands of limitations and broken parts of the ecosystem. And it’s non transferable knowledge.
The downside of that is it means every query, no matter how simple, is a join against multiple internal tables to enforce those rules.
On flip side, meticulous saving of cpu and memory means your solutions are super constrained. You need to do all sort of tricks like 90s game programmer and still can run yourself into corner on larger systems. Back end is supremely unevolved - their serverless functions have been in beta forever and apex is like 20 years old Java.
A calcified org like that can't move fast.
1. Don't allow businesses to customize at all, make them fit to you. That can work with something like ADP, but little else. A lot of the cool B2B startups think they can displace incumbents by just building cool, fast software, and then they are perplexed why they can't gain marketshare when every other customer has some bespoke use case they don't support.
2. Build a general uber-programmable platform that businesses can customize themselves -- now you are in the "slow", "poor user experience" territory but at least it works and is cheaper than option 3
3. Hire consultants to write bespoke products from scratch for each business. That's the old IBM Services model.
So if your baseline is Microsoft Office, then the performance/user experience of your favorite online B2B platform is going to be terrible. But if your baseline is IBM Services, then it's a godsend.
Every time your client slows down, somewhere an executive was promoted.
This is geek poetry.
And I say this out of experience with using it as part of a sales team at a car dealership I worked at years ago. Every sales person in the company was expected to log all the customers they interacted with, track phone numbers & other info, set reminders to makes sales calls, make notes of what you talked about in said sales calls, et cetera, et cetera. And management was adamant that we did these things.
And for good reason. Sales is a very data driven industry, so to your point yes, it’s great for upper management to be able to track & aggregate all of the data company wide.
It’s been too long since I used it for me to really remember or comment on the performance of the software. But if it’s as bad as the OP is saying that’s a real problem. If you have a whole sales team using this, and performance issues are constantly slowing them down and wasting time, that’s something that should seriously be addressed.
I guess you’re saying though that they just don’t care if the sales team experience sucks? As long as management gets their data?
Or wined & dined.
Salesforce's response to the client-side half of the problem is migrating from Aura to Lightning Web Components. LWC is statically analyzable and Aura is not, so they can get some optimizations in that way. On the flip-side, LWC is a piss-poor framework because of how they've stunted it for optimization's sake.
Half of the beauty of Salesforce as a developer is the fact that I can build in a month what would typically take a standard web dev team a year to piece together. That's only true so long as my team works in Aura with all of the scaffolding tools and libraries we've built over the years.
Its clunky, slow and overly complex if you ask me. But their success cannot be denied, thus they must have an amazing salesforce.
... Great observation. But what did you replace it with?
Come in, shake things up by changing a big system to put their stamp on things, (no telling if productivity would’ve gone up if nothing had happened, e.g. company was already growing), then bounce to the next executive gig before the honeymoon wears off.
How many times are we talking about here, like 2 or 20? And why did you end up leaving those roles?
I worked with Real Estate Agency (<20 employees) and they were looking into CRMs. After trying out half a dozen CRMs they ended up commissioning a custom one. There is no single CRM out there that is designed for you.
Oftentimes when people think they need a completely custom solution, it's because they're getting caught up on the default naming conventions and/or default sales processes (which are customizable in basically every mainstream CRM).
I would agree that no CRM is designed specifically for anyone -- that's the whole reason why any of the remotely good ones are built with configurability and customization in mind. The out-of-box-experience with most CRMs is always a traditional "product sales" paradigm, simply because that's the most common. You can definitely customize it to work with other types of models though.
- There is a special place in hell for the person who made the decision to have leads and contacts as separate objects. It creates all kinds of complexity. Some may have a need to work with leads but for clean reporting, you almost have to dump leads. Most B2B companies I know don't use the lead object and autoconvert everything to Contacts. But it has always seemed like a bad decision to have both.
- There is a long line of companies that have tried and are trying to disrupt Salesforce - none have succeed and my take is that this is because of the ecosystem and app exchange. That makes it very challenging to overcome.
- Salesforce has made improvements in their interface (Lightning is, by most counts, an improvement), but an entire industries exists to make up for the shortcomings of Salesforce. Sending emails directly or programmatically is pain, so we have Outreach and Salesloft. Entering data is too slow - so there's Dooly. Their marketing reporting stinks - so there is Fullcircle and Bizible. They own Pardot, yet somehow still can't top Marketo, Hubspot or Eloqua - which is a pretty amazing fail imho. And the Pardot integration really doesn't add a ton of value over other solutions. But as noted above, this weakness is also a strength because you've got a huge ecosystem.
If I'm starting a company right now, I'd probably go with Hubspot because there is just enormous power in the simplicity of having all of the data for both marketing and sales in a single system. Not that Hubspot doesn't have it's own issues, but reporting has always been a huge problem at every company so if I can't avoid this pain even a little, I'd consider it a big win.
They way leads is originally intended to be used, is that you'd dump a bunch of garbage into that table -- b2c data from web forms, incomplete records, mass-imported lists from affiliates/events/etc -- and then it would be the job of sales to sort through it to find the records that are of any value. You wouldn't turn them into a contact until it was determined that there was an opportunity to sell them something.
But, leads as a concept really don't make sense in some industries. In many b2b industries, by the time you interact with anyone at a company, it's already well determined who you are and what product you're interested in. This is properly entered as a contact/opportunity.
There are many reasons to keep leads out of contacts, messy imports and the unstructured nature of what a "lead" can be are big ones, traceability, unauthenticated data capture issues and ease in reporting are a few others.
It's always less of a kludge to have a system that keeps them separate but lets you seamlessly convert or associate a lead object into a contact object, when it makes sense (for lead objects that have sufficient similarity to a contact), and has an option to bypass the lead table and create a contact directly.
In my experience trying to shoe horn into a _contact only_ abstraction creates more problems because the abstraction is too simplistic or even flat incorrect for many businesses.
edit: From a sales agent "user" perspective you do often want to hide these abstractions from the UI depending on the industry and/or lead type, too many systems force their users into unnecessary duplication of effort.
Given that Salesforce is the only CRM I know in my fairly young career, I can definitely see many of its shortcomings and do not envy the engineers/product managers that have to address those.
I think if someone is starting a company, Salesforce is not the right option, both because it is extremely expensive, and its not exactly plug and play if you're looking for customizations.
Not because it’s hard to make a better product, many already exist. But because it’s engrained into the DNA that makes up an enterprise. At some point you just buy Salesforce. Not because you need it, or even because you want it. It just manifests itself. You don’t get fired for buying Salesforce.
- Salesforce is slow, expensive after adding add-ons, costly to customize, and visually unappealing. The older and less tech-friendly workers I've surveyed found it painful to use. The same might be said of many Salesforce competitors, including MSFT Dynamics and Netsuite. SugarCRM also has many of the same failings, but its UI/UX is better IMHO.
- Close.io, Pipedrive, Salesloft, Nethunt, Nutshell, Nimble and few others have a simpler and more engaging take on CRM that seems to be easier for a wider variety of users to adopt.
- A big chunk of CRM's perceived value is better found through sales training that focuses on qualifying customers and good work habits.
- CRM cannot turn most under or non-performing salespeople into performers.
- Many performing workers will resist adding contacts and data to a CRM for several reasons, self-preservation instinct being most prominent.
- Nurture marketing, once a CRM innovation, has become an annoyance for client/customer prospects... particularly over email.
- Predictive CRM requires either a lot of data to train, or hard to obtain signals. The concept underachieves.
The next great thing may very well be inversion of CRM, whereby your customers/clients automate the acquisition, evaluation, negotiation and purchase of products or services. At the enterprise level this exists for commodity products & services, but it's largely non-existent at the SMB/SOHO level. The normalization and quantification problem is significant, but I'm confident ML will address some of these challenges in due time.
Tl;dr ... there's still no substitute for hiring the right people. Charisma, emotional intelligence & motivation always surpasses sales automation.
I'm only half joking.
You can't restore backups! You can export your data, but there's no way to import it, because you can't set the object Id or autonumbered fields (like the case number, which gets communicated to the customer). They used to provide an extremely expensive recovery service, but they stopped doing that. That's just unbelievable for a business product.
I also can't count how many times I looked up an issue and found an "Ideas" post that's over ten years old, with 10k upvotes and no reaction from Salesforce at all. Id doesn't seem like they work on the core product anymore, they just release new things that you need a license for.
Have you tried marking fields for user set IDs as external IDs. This field can then be used while doing upsert. But what do you mean by there is no way to import it? Apart from Dataloader there are a host of companies that offer this feature.
Luckily, we used the weekly export feature and have all our data, we only need to get it back into Salesforce. But how do we do that?
- Dataloader can only restore one object at a time. We have 350 different objects.
- We need to restore the relationships between objects. They are saved by Id, but we can't keep the original Id. So we have to keep track of the original Id and the new Id for each inserted record, and replace them in every other object. That also means we have to insert the objects in topological order. If there are any cycles or self-relationships (like Account.ParentAccount), we have to fill in the Field with NULL first and update it later.
- Even after all this effort, we still can't recreate the values for autonumbered fields. If it's a custom field, we can change the type to text, insert the values and change it back. For standard fields, there is no practical way to do it. No company can help us, because it's just impossible to do using the Salesforce API.
And even those can't change autonumbered standard fields, like the case number. That's problematic, because they don't only live in Salesforce but get referenced from outside.
These types of posts are a refreshing change from what company blogs have become (or maybe always were?): garbage vendor content pushing their agenda.
I understand how Retool could be used to do some really cool stuff on top of Salesforce, but this post is also just an informative expose of an industry giant.
Justin recently did another one about Accenture, whom I worked for a while back, and really appreciate the story that is being told.
Kudos for these fantastic posts. I look forward to reading these every time i see reool.com pop up.
although all credit for this one goes to Taimur!
It’s “SaaS” which was an upgrade on what they replaced initially, but seems like they’re increasingly the ones bound to be “disrupted.”
Resolving merge conflicts in json (which is what defines a retool app) is another area where the benefits of “yes code” become more obvious. “No code” is not something I’m convinced is good. I personally think embracing code (but making it optional) leads to a platform more developers would enjoy
To pick on salesforce a bit, notice how the example of how to define the drop down they are using XML. That’s not “no code”, it’s just a constrained form of coding. Basically any library or framework that embraces code can also offer higher level abstractions just like Retool or Salesforce, without having to have the “no code” part to solve the problem. “No code” is also tangential to being a saas product, these tools could work more like codesandbox than dreamweaver or frontpage, for example.
This reads like I’m a zealot. I’m not. But there is nothing that I’ve seen that can do what it can do and, if you know how it works, you can leverage it for incredible time and efficiency savings for developing and deploying business apps.
Seems analogous to Wordpress for building websites, without actually knowing how to build websites, yes/no?
The value is in the sheer size of the ecosystem and the idea of everything being plug and play, even if the reality often necessitates actual code when you get past the happy demo path to your business's weird edge cases.
Now, I know all tech companies buy other companies. That's not new. But most tech companies also have some capabilities to innovate and building new stuff. That's an important difference. Buying a small tech company to accelerate development of a particular product is different than buying a company like Slack which already dominates the market and can be integrated into the eco system and then transition to mostly maintenance.
Plenty of companies in other industries (e.g. consumer goods) are conglomerates, often a result of acquisitions - it doesn't make them pure "investors."
This thread seems dedicated to picking Salesforce apart from the technical side but you should really look at it from the business value side and as an ecosytem.
Salesforce has certainly defined digital transformation for a lot of companies.
Anyone that wants to beat Salesforce is going to have to be 10x better or come in from a new or niche angle.
No code, slack/chat interfaces and AI assistants seem to be viable paths.
It's incredibly powerful software that when implemented well, can streamline processes, provide easy access to information, and make teams really efficient.
However, it rarely seems to be implemented well.
What other typical company functions have this sort of provider?
Conversely, what other company functions need this sort of provider?
Cruddy apps like Servicenow and Salesforce are goldmines for process management. All you need to do is be marginally better than Oracle/etc.
Cannot wait to see “What’s Adobe?” =)
I mean is google still just a search engine?
JAVA BY AVON
And while sales people tell other sales people they need Salesforce in order to not maintain a software stack of their own. Those same other sales people turn around and tell developers to maintain integration with the Salesforce APIs.
One of them upgraded to lightning required by some feature. The experience nice with lightning (even slower) has been worse than classic. Meanwhile the other instance is till on classic.
We made the mistake of embedding business logic into sales force and integrated with their API only later to find out it can take upwards of a minute to just convert a lead to a contact via API depending on the current load on the system.
Enterprise systems are fun.
Much of Salesforce implementation development also goes unvetted by the client. I have worked and currently work on projects where I constantly ask 'how did this ever make it into production...and how has no one noticed that this is hot garbage for 4 years'. Eventually someone digs deep enough and whoever is managing that project at the time gets the brunt of the blame unfortunately...
Salesforce just has a weird flow. I think I have the gist of it, but man do you have to use it for quite a while before it starts to make sense - all while you wait and wait and wait for anything to happen after you submit something. Ugh.
It’s amazing content in an otherwise opaque category of enterprise software and services, which are so strongly embedded in part because no one knows what they do and how they’re used in practice.
Yeah it’s slow but honestly you’re spending most of your time looking at the data and writing it up, the slowness doesn’t matter that much in the long run imo.
As a user I am firmly in the camp that believes it is garbage to use and overpriced.
As a developer and contractor it paid for my first home.
* A single developer can be incredibly productive at automating a company's business processes. Fresh out of college at my first job I was the only developer supporting hundreds of daily users across our sales, customer support, operations, and finance departments - most of whom were basically working out of Salesforce full-time. Salesforce also proved really adaptable for supporting all of the crazy sales campaigns or operations initiatives that management could dream up - often with quick turnaround times. For me there is no question that the Saleforce licensing costs (or some other low-code alternative) are worthwhile for most businesses vs. trying to build internal systems from scratch.
* Developers are in high demand, and I have received lots of requests from former colleagues looking for a Salesforce developer - even a decade after I moved away from full-time Salesforce development. When I have accepted these offers I've literally been told I can charge however much I want (although I do tend to keep it reasonable).
* You tend to have much more direct contact with your users than in other B2B or B2C development roles. And users are often super-appreciative of even simple changes. It really is a great feeling to see the difference that your work makes firsthand, and I have had some great working relationships with sales and support managers over the years.
* The core Salesforce platform (forms and data modeling, workflow, API integration, etc.) is actually an incredible piece of product design and engineering in my opinion. I know it's getting long in the tooth these days, but the team that built all of that deserves credit for getting so much of it right. All the stuff that Salesforce has built or acquired since then, unfortunately, has been much less impressive.
* Salesforce is expensive for sure, but not as bad as the pricing on their website would suggest. Apparently nobody pays the list price for Salesforce licenses, and a 50% discount from the list prices is not uncommon in my experience.
Ultimately I am glad I decided to get out of Salesforce development if only because the developer experience with almost any other programming language is just so much nicer. But I learned a lot from the experience - and I think those early interactions with users and firsthand experience of how business are run have made me a more well-rounded developer. I was also able to use the skills that I learned while doing Salesforce development to transition into a role building web applications, and pursue a more traditional development career.
And now as I am eyeing retirement, I am contemplating getting back into Salesforce consulting on a part-time basis.
Have I wasted my time in learning Salesforce?
I know that there is what is effectively a cult following of Salesforce evangelists but I was hoping this would be valuable in the long term.
Us devs often try to invent groundbreaking software, while all they needed was to automate a rollodex...
I shared it with a friend that recently joined them.
