How your Anchor Experience Can Help with First Impressions

While trying to gain footing in the Salesforce ecosystem, it may be difficult to see how the exercises in The Salesforce Anchor actually help on the job. A lot of the program benefits are for those still searching for their first job but there are also transferable skills that can be applied in the first thirty days of that job to really make a splash.

First, create a developer sandbox for yourself. This will be your playground. There are three different types of sandboxes, and it's really important to make sure you choose the right one. Otherwise, your attempts to start off with a splash may backfire, because some types have costs involved. There's also a limit on how frequently you can refresh a sandbox so you'll need to make sure that you understand that, as well.

 The most robust version is the full copy sandbox. It is not only a copy of all the metadata from Production (fields, layouts, automation, record types, etc.) but also the data. So it's essentially a full backup of Production that can be refreshed no more often than every 29 days. Depending on the licensing contract with Salesforce, the number of full copy sandboxes varies from org to org, if there's one at all. It's not uncommon, especially for smaller, less robust orgs to not have a full copy sandbox at all.

Instead, what those companies may opt for is a partial copy sandbox. Still a complete copy of all the metadata, but only a subset of the data, up to the data limit of 5 GB. Other than that, partial copy sandboxes can be refreshed as often as every five days.

Both full copy and partial copy sandboxes have costs associated with them. For that reason, make sure you create a developer sandbox. There's also a Developer Pro that's available but the only difference, again, is storage limit. Developer sandboxes have a capacity of 200MB while Developer Pro sandboxes can have 1GB. The cool thing about developer sandboxes, though, is that every org comes with the ability to spin off several up for free. The main drawback with these sandboxes is that you won't have any data copied over from Production. So, usually, you'll have to create some dummy data before you can really make use of the system, but even that’s not considered a downside in this case.

Once you have your Developer sandbox created, start creating some dummy data. While it might seem like a tedious task at first, when it's your first week on a new job, this is a great way to familiarize yourself with what the system does. Even further, and possibly most importantly, it gives you a chance to see the system from the end user's perspective first. By walking through the system and creating all of the necessary underlying data, you'll start to understand more about how it's being used currently, and eventually how you can improve it in the future. Keep a notebook along the way of your findings, that will come in handy.

Next, review your notes and identify what your low-hanging fruit is. Can you improve any page layouts? Would some new, better filtered list views be helpful? Can you add help text on confusing or ambiguous fields? You'll know the low-hanging fruit because it's something that you can update in 10-15 minutes.

Then decide what might require a little more time. These tasks are things that might require between an hour and a day to update. Things like updating and testing automation logic, overhauling reports and dashboards, or giving an entire app a facelift.

Finally, highlight what may require a longer term, more strategic approach. These tasks often require several meetings and coordination from multiple business stakeholders, who you may not even know yet since you're new.

Once you've got a list of things categorized this way, start with the low-hanging fruit and make those updates in your Developer sandbox. Once you finish those, move up to the next ones. If you think you can, keep going and tackle the difficult stuff. But the point of this entire exercise is to be able to show what you can do with low risk.

Once you've made changes to a page layout, or you've overhauled an app, setup some time with your boss to show them your ideas and get their feedback. The point of this exercise isn't even necessarily to show what you can configure, although that will be a byproduct. The real intention is to show your boss that you know how to identify improvement areas and can take the initiative to improve them without risking the integrity of the system. You can also use this time to bring the long-term fixes or solutions to the table and show your willingness to not only be  immediate, but also strategic.

This is one of the main goals of the pedagogy behind The Salesforce Anchor: to see problem-solving through a Salesforce lens. Each course is rooted in a different scenario but, regardless, students just have to put on their Salesforce glasses and then they can see where they can have an impact in the system.

Especially as a Salesforce consultant, but also as an in-house admin, being able to put those glasses on, identify weaknesses in the technology, and be apart of the ideation process to resolve that problem is what will keep you employed.

How The Salesforce Anchor Aligns with Pre-Sales Roles

One of the early decisions that a new Salesforce professional has to make is which track is best for them: admin, developer, consultant, architect, business analyst, etc. There’s a version of each of those tracks that I’ve noticed often gets overlooked so I wanted to take some time to dive into that for those who haven’t yet been exposed to it.

In all fairness, it’s more so a forgotten part of the Salesforce outreach process than it is an entirely different track. But it’s called pre-sales, or pursuits. First off, this role is primarily for consulting firms. In-house admins don’t need this particular function, although it would definitely improve their effectiveness.

Consulting firms begin pre-sales activities when they’ve identified a potential customer and they want to put together a compelling proposal. Or sometimes they will respond to a request for proposals (RFP). A team of people with skills ranging from account manager or accountable executive, all the way down to the developers or business analysts work diligently together to build a presentation deck and whatever other necessary assets are either specifically listed in the RFP or that they believe will improve their chances of winning. Their goal is to configure a Salesforce org that, once demoed, contributes positively to convincing that company to work with them.

Sometimes these orgs are combinations of prior projects. So the effort is spent tinkering with a new set of features and making sure they work together enough to demo. Sometimes it’s determined that building a custom demo is worth it, so teams build out custom components and experiences to hopefully win the business. At times, there’s a combination of both, going as far as setting up custom integrations.

The reason not all firms do this is because it’s an investment. Small teams are often required to work solely on the pre-sales effort for weeks at a time. Or sometimes people juggle working on existing client work and also pre-sales efforts. Those can make for long days. Even worse, those are wasted labor hours if the deal doesn’t close, and more deals don’t close than do, on average. So there’s a risk in putting all your eggs into one basket. Or, rather, putting any eggs into a basket too soon. You wouldn’t want to have an egg in the basket too long or else you end up with a rotten egg and a stinky basket.

Nonetheless, there are still some of us who just enjoy building new Salesforce solutions that solve different problems. I certainly fall into that camp. Most of the Salesforce systems I build, don’t get used. Either because they’re dev orgs that I created for fun, or because of pre-sales efforts that didn’t pan out, or even pre-sales efforts that did pan out but used my org as a muse more than anything. It happens, doesn’t bother me one bit because, while I may not be able to add that to my resume, I can still count that as experience added to my toolkit. I can still speak to the key processes, milestones, and design decisions required to make that system work, all of which make me a more informed Salesforce professional.

If you’ve taken part in any of my Anchor courses, how you feel tackling challenges like those can help dictate whether or not you may be a good fit for pursuit roles. What we’re essentially doing is rooting ourselves in a particular business or scenario and then building a Salesforce system to address the obvious. Then we can address the next layer of slightly-less obvious problems and/or questions. And eventually, we end up with a comprehensive system built on few requirements that still addresses the more predictable needs of the company. That’s probably 80% of pre-sales roles. Having prior experience or industry knowledge helps too, because it means that you can bubble up the less-obvious problems or questions, making your proposal that much more relevant.

All of this to say, while you’re searching for and applying to job roles, consider adding, or avoiding, these keywords to better refine your search and hopefully increase your chances of landing that perfect next job.

Quick Actions and Related Records

TL;DR

When designing lightning record pages for scenarios where users have to refer back to parent records often, consider using quick actions, displaying them through the “Related Record” lightning component and updating the lookup filter to a record “upstream.”

---

As Salesforce professionals, there will come a time when an end-user says something like “but I have to click through too many screens” as an excuse to not use Salesforce. The following is one way with Lightning design to address these types of hurdles.

Quick Actions

At the core of this design are quick actions. Quick actions are a lightning feature that allows admins to create something like a sub-layout on a Salesforce object (this will focus on object-level quick actions, not global quick actions). Rather than those fields simply being arranged a certain way, however, the quick action allows for them to be launched by a button.

The Scenario

In this example, I’m tracking dresses as Products. When a bride tries on a dress, it creates a custom record called Dress Tried On. I’ve created a quick action on the Product called “Product Snapshot.” The image below shows the quick action on the Product as a button using dynamic actions on the lightning page layout.

Admins also have the option to configure the action directly on the layout somewhere. Using the Related Record, lightning component, we can add the quick action to the lightning page where ever we want, agnostic from the details section, and with its own visibility settings.

In this case, the fields in the Product Snapshot are pretty much the same as on the layout. So having this button on the layout doesn’t add much value, and neither does displaying the Related Record component as it would be redundant. Luckily, the quick action can be accessed another way, also, and that way adds significant value to the end user.

The Solution

When designing lightning record pages, we have the ability to display quick actions for the lookup fields on the current object. When adding the Related Record component to a lightning record page, just change the “Edit Lookup Field.” This will then display a dialog where admins can choose from all of the lookup fields, and even travel “upstream” through all of the lookup relationships.

Circling back to the original obstacle, this design enables admins to display relevant upstream information on the page layout and therefore prevent end users from having to navigate between the various pages themselves.

Continuing the example from before, my Dresses Tried On record looks up to the Person trying on the dress and their measurements (Contact), the dress itself (Product), and the Wedding (Account). By creating quick actions on the Contact, Product and Account, I can display the information from their quick actions directly on the Dress Tried On (see right panel of image).

But wait, there’s more

Adding to all of those obvious benefits, the quick actions are editable when added via Related Records. So that means that, end users can not only edit the Dress Tried On, but also the Account, Product and Contact, without leaving this screen.

This functionality enables admins and designers to create useful and purposeful pages that cater to the end user. By designing with the end user’s experience in mind, we increase the likelihood of user adoption and create some pretty useful pages in the process.

Abbott Elementary Deck

Here is a link to the PDF of the Abbott Elementary Anchor series.

Introducing: The Salesforce Anchor Program

⚓️ The History

I never studied business in college. I never studied computer science or anything tech in college. I was a creative writing major, writing poems and short stories to earn the grade, which I ultimately did. After my plans to work in the NFL fell through, I was introduced to Salesforce.

The whole thing made zero sense to me. I didn’t have the business or tech context to digest Salesforce and felt like I was swimming. One day, a former co-worker, Alex Cardona, let me listen to one of his phone calls and then watch him white board his ideas afterwards. After a few calls, things started to make more and more sense.

This was back in 2011, well before the days of Trailhead. So, in the old days, learning Salesforce only really happened this way: by knowing someone who was willing to walk you through.

Eventually the concept of Salesforce made sense to me and the creative in me wondered where else Salesforce could be useful. Without much business acumen at the time, there was only one organization that I knew well enough to even ask the question: Dartmouth Athletics.

⚓️ My First Anchor

I played on the Dartmouth football team my freshmen and sophomore years of college before a back injury ended my career. After that, I got involved with the marketing team and other offices in the Athletic Department. So when the Salesforce light finally switched on for me, Dartmouth Athletics was the only situation I could evaluate through my newly-discovered Salesforce lens.

I knew that when Bill in marketing finished writing the copy for the upcoming basketball game, it had to go to Cyndi in sports information. So I built a workflow to make that happen. I knew that softball coaches needed to track certain information about a recruit that the football coaches didn’t, so I setup a record type for each team. Slowly but surely, I applied the new lessons that I learned to the scenarios I knew of in Dartmouth Athletics and shortly after that I passed the admin exam, and the sales cloud exam.

Dartmouth Athletics was my first Salesforce Anchor.

“The Salesforce Anchor program is designed to help others find and use their own anchors to better learn the Salesforce platform. ”

— Kyle Battle

⚓️ The Vision

I believe that every person beginning their Salesforce journey already has an anchor, they just need to find it. Trailblazers just out of college could use any student or fraternal organization, clubs they were apart of, or the admissions process in general. Didn’t go to college? That’s fine. Consider using your local church, or maybe your car mechanic, or your local real estate agent to anchor your Salesforce learning. Switching careers to join the ohana? Use the knowledge you already have from your previous career to anchor what you learn in Salesforce.

The Anchor Saturdays part of the Salesforce Anchor program is an opportunity for trailblazers to solution live with me while I tackle how to address the problems of a given industry. These sessions are always rooted in something familiar. Rather than teaching with Universal Containers, Cloud Kicks, or Ursa Major Solar, I find common (or well-known) businesses or use cases to teach the same lessons. So far we’ve built:

• An on-demand furniture company

• A tech-forward barber shop

• A youth sports league

• A script submission process for a film company

• A CRM for Abbott Elementary

What’s Next?

The Salesforce Anchor program is expanding. Each day, the ohana makes clear how hard it is to get real-world experience and how valuable opportunities like Anchor Saturdays are. Next up, the program will include a variety of Anchor scenarios to build out, plus advantages for hiring managers and recruiters as well.

Enroll Now

There are now Anchor Saturday sessions from the past available via my new course library on Teachable.

Slack and the End of Chatter

Originally posted on LinkedIn.

When Salesforce announced the purchase of Slack for $27B+ during the summer of 2021, there were many obvious and immediate advantages to the partnership; for both end users and tech nerds alike. Things like sharing deal updates from Salesforce directly to specific channels in Slack. Or configuring which Salesforce data shows up and which records trigger Slack posts. Or even approving or denying approval requests directly from within Slack. The possibilities are endless.

One of the more common concerns amongst Salesforce professionals, however, was where Chatter fell into the equation and whether it had a place at all anymore. Chatter has been a staple of Salesforce since very early on, touting the ability for users to quickly communicate and collaborate on records, also providing a conversation thread of history for others to follow and stay updated about important deals, people, customers, etc.

Well, Slack can do everything that Chatter can, plus much more, and several months after the announcement, the Slalom LA Salesforce team still can't come to a consensus on the future coexistence of the two products.

 The current capabilities allow for Chatter and Slack to work together, and while there are those that believe that the partnership in its current state is sustainable, there are some skeptics that forecast a change in dynamics.

There are essentially two schools of thought. One in which people see hope for Chatter as Salesforce's internal communication tool, Slack is then summarized as the external (to Salesforce) communication tool, and the future success lies in continually tightening up the integration between the two. As long as those lines remain, this argument still has a leg on which to stand. Senior Principal Tiffany (Chen) Yu falls into this camp, "I think there's still a use for Chatter as the in-app commenting tool, versus Slack, which takes users outside of Salesforce."

The other school of thought is that Slack is Chatter's replacement, slowly but surely chipping away at Chatter's functionality until it is, as Consultant Eric Prum put it, "obsolete." The thinking here is that Slack is so much more sophisticated than Chatter that users will eventually want collaborative functionality inside Salesforce, that Chatter simply can't support. Rather than spending the time and money to beef up Chatter, it will almost certainly make more sense at that time to find ways to fold Slack into the Salesforce interface.

It's hard to get a read from Salesforce on which way they're leaning. On one hand, Chatter is a bedrock of Salesforce and there could be longtime supporters lobbying to keep it around. At the same time, though, Chatter is free and Slack isn't. So it's important not to confuse Salesforce's efforts to sell Slack (a vehicle of revenue) as a premonition of where the technology is going. It could just be that they offer Slack as a chance for revenue, and then settle for Chatter, the out-of-the-box, free option as a last resort. We just don't know.

The one thing that the Slalom SoCal Salesforce Team could agree on was that Salesforce admins and strategists should be focusing on two things to prepare for whatever the outcome is.

The first is documentation. A first step that anyone can take, is to document the use cases in which Chatter is used in your org. From there, combine those and review them to see if any of the use cases are underperforming. If they are, consider if a migration to a Slack-based strategy makes sense.

Assuming your org needs updates, the second consensus is the need for change management, or how your company manages cultural, operational or technological changes. Having an effective change management strategy is arguably more important than having good technology because of how directly it influence user adoption. We can build out the best system in the world but if the users don't adopt it or use it as intended, then all that build time is wasted.

The bottom line is that there's nothing you have to worry about immediately. Salesforce will still work for you just as expected. You can take advantage of Slack's new features inside Salesforce, or you can keep using Chatter. Maybe your company doesn't use Slack. That's fine. You don't have to use Slack. But if you're not using Slack, and you are using Salesforce, you'll want to start these conversations within your company. Just to be sure.

If you'd like for a Slalomer to help you through this conversation, inbox me and I'll get the ball rolling.

Managing Salesforce Deployments from Outside of Production

I recently finished a deployment that represented a first for me, which also means I learned some new lessons that I’d like to share.

The scenario

Because of a super restrictive data security setup, I, as the consultant, only had access to a sandbox. Production access was limited to a select group of internal users.

The dilemma

What is the best way to manage deployments and live changes when you don’t have access to the destination org?

My first finding

If you’re a Salesforce admin like me, you probably have gotten into the habit of creating, uploading and deploying your own change sets. You probably also have encountered validation errors which require the change set to be updated.

When you’re managing your own change sets, those changes can usually be made on the fly and re-uploaded. But when there is split access, troubleshooting those errors takes on a whole new meaning.

What I’ve found is helpful to quell this issue, is creating much smaller change sets. Unusually create a change set and throw all changes into it in order to deploy one time. In this scenario, though, it’s been most helpful to have very small and specific change sets, each addressing a particular feature. This way, if something fails validation, I can immediately target the feature of that change set rather than having to find a way to pinpoint the issue.

My Second Finding

The biggest deployment issue we’ve seen involved folder sharing. Since I’m a User in the sandbox only, and a folder is shared with me, upon validation, Salesforce will look for my user in Production. It’s not there, though, and that causes the error.

To resolve this, just make sure that any folders you create (or at least before you upload from the sandbox) are shared with a user, role or public group that exists in Prod. A workaround that we’ve done is to set them all to “All Internal Users = View” in the sandbox, upload and deploy as such, and then reconfigure sharing in PROD to account for the real User base.

As the implementation consultant, you’ll usually have admin access to Production but there are scenarios in which you won’t. This will create an additional challenge in order to manage, but if you follow these tips from the start, there’s no reason your deployment shouldn’t go smoothly.

KB Top 3: How to Keep Salesforce Festive During the Holidays

Inherent within every software implementation is the underlying dependency on user adoption. User adoption is multi-faceted and occurs in phases. The first phase is to get users logged into the system for the first time. First impressions are everything so it’s important that the first login goes well. The next step is to get them to continually log in and update the system.

One of the ways I like to encourage this behavior is by adding some flavor to the system in the form of images, GIFs, videos or emojis.

Especially during the holidays, users tend to log in less and spend less time in the system when they do. Now, I don’t claim for these to be the end-all-be-all solutions but they certainly contribute psychologically to building a healthy, fun, and engaging climate around Salesforce. So here are my top three tips for decreasing the Salesforce drop-off that occurs during the holidays.

Add animations for statuses and paths

Before Salesforce rolled out Paths with Lightning, it wasn’t uncommon for me to configure a formula (text) field that used the IMAGE function to conditionally render a photo when a certain criteria was met.

The most fun example was probably when I created a visual representation of a custom lead scoring field for a client. Based on what a given Lead’s score was, a different image would show up, indicating the urgency with which they should follow up. This is what they saw for Leads with low scores, Leads with moderate scores showed this animation, and high-scoring Leads looked like this.

While this alone adds some personality to the system, admins can expand that even more simply by creating a task for yourself to switch those out for new GIFs or images periodically. Eventually, users will look forward to seeing what GIF shows up for them this week/month/quarter. Even this small, seemingly insignificant feeling, contributes to positive user adoption in your org. As the admin or architect, use this in areas where adoption may be low (Note: If your criteria is driven by a picklist field alone, consider using a Path and pasting these animations in the “Guidance for Success” rich-text section).

Notice that the high-scoring Lead animation is from the movie Polar Express, a Christmas movie. Feel free to find fun assets that represent the holidays of your workforce (that means Hanukkah, Ramadan and Kwanzaa, too). Then, switch them to encouraging images of a new year and new beginnings. Basically, give the system a bit of a personality and use that personality to keep people engaging with the system.

Add festive assets to the homepage

Assuming that you have a home page and that it’s the default landing page for most users, spruce it up by adding some holiday cheer to the aesthetic. Since it’s likely the first page people see when they log in, it’s also the first opportunity to build an experience that contributes positively to user adoption.

1. If you have a festive variation of your company’s logo that you use around the holidays, add it to Apps in the App Manager during the holidays.

2. (In Lightning) Add a rich text component to the home page with messaging in festive-colored fonts.

3. Create a new “Holidays” tab and add your messaging and digital assets there if you don’t want to change the current home page too much.

4. Setup a public Holiday Cheer Chatter group and allow users to join. Encourage users to share things like their favorite holiday movie, their favorite ugly Christmas sweater photo, or pictures of homemade holiday treats.

Don’t Force the Festivities

Also, consider making these assets configurable. Don’t force the holidays on people, but rather make it available via Salesforce to be festive. You may want a checkbox on the User record that allows Users to opt out of the “festivities” if they want. And don’t take this personally if people opt out - if it means they get their jobs done distraction free - that’s also a win.

These are just a few recommendations on how to make Salesforce festive but the possibilities are endless. If you’re unsure of how to work these into your organization, consider running these ideas by your Salesforce, and possibly also HR, team to start brainstorming. If you’d like me to take a look and give some suggestions, just hit me up!

KB Top 3: Avoid These Mistakes with Your Salesforce Hires

As the footprint of Salesforce continues to grow, so too will the need for Salesforce professionals. One trend I noticed during 2020 and the pandemic is that a lot of people that lost their jobs turned to the Trailhead platform to skill up on Salesforce. What this means is that there is more competition amongst Salesforce professionals which bodes well for companies looking to build out their Salesforce team.

The flip side of that is that with more people claiming Salesforce expertise, it’s both more necessary and also more difficult, to find the hire that’s right for your organization. Below are my top three tips for avoiding hiring mistakes when evaluating Salesforce talent.

Understand what you need from your Salesforce person/team and hire for it.

Here is an example of the mistake I see the most often: Susan needs some Salesforce help but is restricted by a budget so she goes out and hires a young Salesforce admin. Two months later, COVID-19 hits and now Susan needs that admin to help strategize how to redesign the system to handle an increase in demand and also a decrease in workforce. The admin spends 50% of their time researching answers, building out Trailhead playgrounds and attending Salesforce webinars. Now you’re paying 50% of their salary for them to learn on the job, further delaying the time before they are useful.

As you build out your team, the most helpful thing you can do for yourself is to understand the differences in the various certifications and where that certification falls on the critical-thinking spectrum. The ADM 201 certification is the bare-minimum and, therefore, requires the least amount of critical-thinking. Tell them what to configure and they’ll do it.

The Advanced Administrator certification taps into a little more critical-thinking but is still largely configuration driven. For both admin exams, questions are phrased more like “is it possible to…”, “what configuration feature does this…”, “how can this desired result be configured?…” etc.

The critical-thinking really comes after that, especially with consultant exams, where the questions are phrased more like “what is the best way to…”, “how can you accomplish this for a client?”, “what would you recommend for someone in this situation…”

If your organization is prepared to hand off project specs and just needs them configured, you’re probably going to be okay hiring an admin. However, if you’re like most people building out Salesforce teams, you expect the system to evolve along with your company and you need someone who can not only administer the system but can also help build a roadmap of what your system will need to look like in a year, and how to get there. It’s not fair to expect this level of critical-thinking of an admin; a business analyst with architecting experience would be ideal but also be prepared to pay a higher salary. Also, be wary of the impact that overloading your Salesforce admin can have on the culture of turnover for that role.

Don’t overvalue certifications.

Salesforce Trailhead has made it possible for anyone anywhere in the world to learn the technical skills of Salesforce. This means that, in theory, someone could get Salesforce certified without ever having seen Salesforce in action. It’s not likely, but it’s absolutely possible. Being that it’s possible, assign some weight to certifications, but it shouldn’t be the end-all-be all.

What I’ve found is that most Salesforce professionals won’t take an exam until they’re 90% sure they’ll pass It. If there’s even a moderate amount of doubt there, they won’t even take the exam. Now, that doesn’t mean they can’t still help you solve your Salesforce problems. It could just as likely mean that the consultant is more than capable but needs the boost of confidence from someone like you seeing their value pre-certification.

This happened with me. For years, I avoided the Platform App Builder certification because I didn’t think I could pass it without a strong background in coding - which I don’t have. I stumbled onto a practice test and did very well and then passed the exam easily my first time. I was more than capable intellectually, just needed something to give me that confidence boost. You knowing not to overvalue certifications could be that boost.

Appreciate variety.

Let’s say you run a real estate company looking build out your Salesforce team. Naturally, you’d want people with experience in real estate. However I argue that you should find someone with tangental real estate experience, at best. First, because there’s a surprising amount of cross-over between industries or sectors in terms of how they use Salesforce. There are obviously nuances but pulling from a variety of skills and experiences will allow you to leverage lessons from other industries that may not be as intuitive.

For example, I did a project for Lionsgate Motion Pictures where Salesforce managed the pre-production process of making movies. It just so happened that the process of matching a script with a writer, reviewing the writer’s script, and alerting finance that it’s time to pay the writer for that draft is actually a very similar process to how the LA Chamber of Commerce matches fellows with interviewers, reviews their custom interview grading rubric, and generates invoices for finance to track tuition. The labels for the fields are all different but the structure of the data is almost identical.

Do yourself a favor and build up your Salesforce team with people who have worked on all different types of projects (Service Cloud, Sales Cloud, Communities, both native and non-native Integrations, VisualForce heavy environments, Heroku apps, etc.). Try to build a team that can cover as much of Salesforce’s capabilities as possible. Don’t limit your system to the specific portion of Salesforce that you’re aware of at the time of hiring.

As long as you have a clear understanding of what you need, you understand the factor that certifications play in this type of decision-making, and you build a team with experiences that complement each other, you should go into your hiring season confident that you’ll find the next right addition to your team. If you would like for me to take a look at your org and diagnose what level of Salesforce professional you need, please feel free to reach out.

A Lesson From Using Flows

I spent the better part of the last week working on a fairly complicated screen Flow to create three generations of records from the Account object. After diagramming the desired state and getting comfortable with the expected outcomes, it came time to start building.

I got the Flow built and started testing and unknowingly fell victim to something that even I sometimes forget: to keep it simple. While trying to build out the Flow, I couldn’t get a decision node to recognize a picklist value appropriately.

Long story short, if you can’t figure out the right resource to use for a value within your Flow, maybe there isn’t one. It may be more appropriate to just type the text you’re looking for, rather than trying to tie everything out via relationships.

Instead, I just needed to type the word I was looking for into the value and not link to a resource at all.

I’m admittedly still figuring out all that Flows can do. Seemingly with each Salesforce release, Flows have gotten better and better: to the point that they’re incredibly user friendly now, which hasn’t always been the case. If you’re an expert Flow builder, this article may not have been helpful, but if you’re hooked up on getting a picklist value to show up in other components through the Flow, and don’t know every piece that needs to be configured, give this approach a try.