- Eric Dreshfield (Salesforce MVP / Advocacy Manager @ Apttus / S. Indiana Salesforce User Group Leader / Midwest Dreamin’ Founder
- Mike Martin (Salesforce MVP / Director, Indianapolis Delivery Center @ Appirio / Indianapolis Salesforce User Group Leader)
- Melissa Davis (CMO @ nimblejack)
- Susan Punnoose (Senior Software Engineer @ Salesforce)
- Scott Sondermann (Solutions Engineer Scout @ Salesforce)
It’s always “refreshing” to find something so innocuous in Salesforce that kind of throws you for a loop. Especially when this “innocuous” item is a little counter-intuitive to the Salesforce mantra of “clicks not code”. Plus, it appears to have impacted people for quite a while. Warning: This post may be (i.e., is) a little pic heavy.
Anyways, I’ve been working with a client on their Salesforce roll-out for a few months. It’s not a big roll-out but one that’s big enough to necessitate some custom integration. Within their org they have a picklist field on Leads, Account, and Opportunities to easily identify and report by corporate division for ownership purposes. The Label Value of the picklist values is a text string with a company number identifier and name concatenated together, e.g. ‘## TEXT OF NAME’. The integration team only wants to use the company number value (‘##’) for incoming and outgoing communication with external systems.
So, to accommodate this we updated the API Values for the picklist values to just be the numerical values at the start of the Label Value (e.g., Label Value ’01 US Division’ and API Value ’01’).
However, this is where a loop is thrown…
This company identifier picklist is an Account field but when we attempt to reference that value on, say, an Opportunity via a formula field (e.g., TEXT(Account.Company_Number__c). Unfortunately, the value returned is NOT the Label Value but is the API Value. That is, I expected to get back ’01 US Division’ but only received ’01’.
I can kind-of, sort-of understand why this would be the case. The API Value is used in Apex and all the front-end configuration is essentially creating Apex without really coding. BUT, from a practical standpoint it doesn’t make sense since I’m referencing a field from the front-end in a formula field and expecting that same front-end display value back but, instead, am given the back-end API Value. Boo, Salesforce. Boo!
There are a few options:
1) Custom Apex – No thanks, Salesforce. “Clicks, not code”, right?!?
2) Update Formula Field with IF Statement and Hard-Code of UI Values – I opted to go this route. I very much dislike it since we’re hard-coding a map of values from the returned picklist API Values to recreated Label Values. In some cases this could be problematic as picklist values have the potential to change causing issues with the formula field. Thankfully, this customer’s values have been very stable and unlikely to change. Still less than ideal in this case and, potentially, a pain in the butt for other clients.
Here’s the updated formula for the field with hard-coded values (YUCK!):
And, here’s the final result on the Opportunity:
In the Success Community We Trust…
The one thing I do love about the Salesforce community is that nearly all issues you run across have been found and reported to Salesforce previously (sometimes years ago). And, this issue is no different. This specific Idea is “under review”. So, there’s still hope!
One of our practice goals for 2018 for the Salesforce team was to donate/volunteer our time to the communities in which we live. We are attempting to follow Salesforce’s 1-1-1 initiative as much as possible. The size of our company and team doesn’t give us much ability to hit the 1% of our time goal but we are attempting to get as close as possible with quarterly volunteering opportunities. Our team partnered with Second Helpings (a local non-profit).
What is Second Helpings?
Second Helpings mission is “Transforming lives through the power of food”. They have two sides to their organization – 1) Chef training for the unemployed and underemployed and 2) Meal preparation for many other local non-profits. Second Helpings take in food from various local donation sources including grocery stores and restaurants. The chefs-in-training then prepare menus based on the availability and in some cases unavailability of certain items. Also, the chefs receive education in other life skills such as mortgages, checking accounts, and credit. So, they leave with a well-rounded set of both work and life skills. As an example of the “unavailability” our volunteer liaison told us about the time that they made pasta sauce with Bloody Mary mix when no tomato sauce was available. So, to say that they are a resource bunch is an understatement.
Additionally, the depth and breadth of their ability to track throughput of donations in and meals out is a testament to ingenuity and logistical prowess. The amount of food that is considered “waste” (which is composted) was less than 10% of their intake. That’s an awesome percentage given the amount of food that they receive and then distribute as meals or re-donate to local food banks.
So, what did the CleanSlate team do?
Well, initially, they let us sample their food! The chefs-in-training take great pride in their work and you can definitely see and taste it. Typically, the chefs prepare food in buffet style. However, when we visited they had prepared a huge menu of options including appetizers, salads, and sandwiches. Our team ordered a few appetizers (fried green beans, onion rings, and cheese sticks) as well as a few entrées including barbecue chicken sandwiches, hamburgers, and salads. The food was very good! They included dessert options but our team was ready to get to work.
The regular volunteer staff gave us an introductory tour and instructions on when to wash hands and to re-glove our hands. We then set off on peeling and cutting onions as well as peeling and cutting brussel sprouts. This may not sound glamorous as a volunteering activity but it was actually pretty fun when you have 6 other friends with you. The onions did make most of us cry a time or two…but I digress. The chefs made us cookies as a “thank you” (I’d like one of those right now, actually). And, at the end of our shift we swept, mopped, cleaned our knives, and prepared the kitchen for the next day.
All-in-all, the team had a good day and we hope that we were able to provide some value to their chefs’ cooking. I think we’re going to like working with Second Helpings and are hoping that we can also donate some time to help them with their Salesforce org.
If you would like to see our other company-wide volunteer activities you can check-out this link.
Are you tired of “hard-coding” owner id’s whether for a queue or a user inside of Process Builder and doing constant screen switching to find the correct id’s and making mistakes putting the id’s into your process? Look no further… New with Winter ’18 you can now lookup directly to users/queues!
When setting the Owner ID, just simply select the specific Type (Queue or User) and use the value to search for an existing value (User or Queue).
This new enhancement will be a HUGE help with making mistakes in setting incorrect id’s! There are a few things to watch out for this new feature.
- You cannot simply update any rows created before Winter ’18 in existing processes. To modify this, delete your current “Owner ID” field, add a new one and complete the steps above. This will allow you to see the new feature.
- When deploying these to a new environment, you will need to go into your process, edit the action lookup and re-save. If you don’t do this, you will get an “Invalid reference id” error when your process executes in the new environment. I have submitted a case to Salesforce to determine what is causing this issue and will provide an update when I get a response.
To see a full list of new features in Winter ’18 see the Winter ’18 Release Notes(//releasenotes.docs.salesforce.com/en-us/winter18/release-notes/salesforce_release_notes.htm)
We’ve previously introduced you to Salesforce’s Trailhead. However…
if you haven’t read that post yet OR if you want a TL;DR then, Trailhead is a free training platform offered by Salesforce. With Trailhead anyone is given the ability to learn, use, and extend the Salesforce platform through development environments of Salesforce Sales and Service Clouds. The various training paths are separated into “Business User”, “Admin”, and “Developer” paths and are then subdivided by level (e.g., Beginner, Intermediate, and Advanced). The Trailhead team has also “gamified” platform in that users earn points and badges based upon the number of trails, modules, projects, and superbadges that they complete. (Humble brag time) My current badge count is 182 accounting for 119,475 points.
Last Fall, Salesforce rolled-out the ability to define custom Trailhead learning paths called “Trailmixes”. With these “Trailmixes”, you can create specific and targeted training paths for your users. You want your users to learn a combination of Sales Cloud basics, Lightning Experience Basics, and Privacy/Data Protection concepts? Easy! Simply create a Trailmix that includes the “Salesforce User Basics” module, the “Learn to Work in Lightning Experience” trail, and the “Learn Privacy and Data Protection Law” trail. Then, all your users would need to do is to log in to Trailhead and start the Trailmix. This is a great way to prioritize the Salesforce learning that your users undertake. As an example, here’s a Trailmix I created for new business users of Salesforce at CleanSlate.
Trailhead remains the best Salesforce training resource available. And, it’s absolutely free!