Weirdnesses in Salesforce?

I guess everyone working with Salesforce occasionally runs into some oddity that they just don't understand. Sometimes even the most basic things behave in a non-standard way or just aren't there, it makes you angry. Based on that, he has to come up with a workaround or a solution that will help him resolve the situation. Or... or they just have to sell it as a feature and not a bug. Which isn't easy when you don't really believe it yourself and don't understand why this isn't in Salesforce.

I've made a few notes of these things over the last month, and so I still have anger and frustration with the situation. Let's take a look at a few of these things.

Dynamic form and Opportunity creation

Dynamic form are great, I use them almost everywhere possible. The option that one doesn't have to have x Page Layouts is great. They're faster, clearer, and more importantly, you can even sort the fields better. Mind you, if you combine a Multi-select picklist and there is some other field in the second section, it usually always gets messed up and looks unsightly. But that's not the subject of this section.

Imagine a situation where you have several record types, you added fields to a dynamic form, and you require each type to have a different data model. You saved it and behold on the detail it works. But what about the situation when you are creating Opportunity? That's when the standard layout is displayed. Why? As it sometimes is, there is one little checkbox for now. Specifically called "Prompt users to add products to opportunities", which is in the setup under Opportunity Settings. Simply put, this checkbox, if marked true, will throw up a modal when an opportunity is created, stating that a Pricebook and of course a product must be selected. This mischief prevents even create actions from being built on dynamic form. If we mark it to false, it suddenly starts working. So the user just selects the pricebook and product only in the step when he wants to add products to the created opportunity.

Yeah, it took me a while to figure that out.

Lead Conversion and Description field

The Description field is quite important on Lead. When you convert it, it gets overwritten on the Contact object, great. But that's all. Quite often I get asked why the field was not automatically overwritten on the newly created Opportunity as well, because this is the field where the salesperson kept important information for the future deal. Unfortunately I don't know the answer, it just doesn't work. It's not even possible to set this up in a standard way, so you have to create automation or convince the customer that this information is still in the system, just on a different object that they have access to. For example, in the console this is easily solvable (more open tabs and that's it), but the standard environment just makes it harder. Argh.

Soft validation

I bloody miss that! What do you mean by that? Just a warning that something is probably wrong and it would be good to take another look at it. It sounds like validation, but it outright forbids you from saving the record until you meet the condition. Here the option to save is still there. It's just alerting them to a situation that the user had better try something else.

Fortunately, this one is already pretty much scored as an idea and will hopefully be delivered soon. Ugh!

Oh, and I also set up a PoC with a friend, but more on that another time.

Knowledge article with translations - Mass Update

Knowledge is a wonderful thing. I like it and I enjoy its possibilities. What's a bit worse is importing knowledge articles that have the required category and of course translations into several languages. If you can get all this right you win. But what about when you need to edit several hundred articles with translates and add for example a numeric value to a custom field. This is where the fun begins. The published version cannot be updated. You have to create a draft, edit the value and save it. The problem arises if you have translations, you lose those. Here you have to work with archiving, restoring, submitting translations, exporting data, editing data in excel, importing back and then publishing.

As written, it looks like it's quick. But as I write above, imagine a large number of articles, plus you only want to edit selected types, etc. It's just a matter of a few hours of work (a lot of annoying work).

Anyway, it's faster than deleting it all and starting from scratch.

Log as and permission for support

We know. Sometimes when dealing with SF support, you need to allow access to the org so they can investigate and test the situation. As long as you set it up on your user, it's fine and everything works.

Assuming you need to set up support access for another user, unfortunately you can't. And I actually understand why. Security. It makes sense, but it would be faster. Sometimes it's really challenging to explain to an ordinary user what to do and why.

Number of Subscriber users for report

Did you know that the number of subscriber users that can be set up on reports/dashboards is limited? In lightning it's 7, in classic even less (but who uses classic, right?). In a large implementation this number is considerably insufficient. Ala luckily, it should be solved soon. Idea is here!

It's a live system

There are more things that bother me, like the fact that the report doesn't show all the emails that left SF or the lack of inline editing. However, what I've described here is the experience of the last month, so maybe more problems next time.

What's bothering you? What would you appreciate Salesforce to improve or change?

Let me know! info@salesforcestuff.org