I don’t know about you but I would love to go back to high school and change a few things!

On a recent client discovery interview, a successful Financial Advisor made the following statement about her frustration with the Salesforce Classic Interface: “There are just way too many clicks!”

I chuckled and said, “In many ways Salesforce is a lot like High School. Sadly, most Salesforce users only use Salesforce at an Elementary School level at no fault of their own.”

Most users of Salesforce must adopt what someone else has created because they were never part of the development and rollout strategy of the solution. Today, more often than not, an IT department within a company designs, configures and deploys a Salesforce solution to a Sales Group, Marketing Team, or Support Center and expects those users to adopt the platform. In many cases, users revolt and adoption comes to a very fast stand still.

If that happens, don’t give up, launch a more inclusive effort by bringing in those subject matter experts and focus on building a more friendly User Experience or User Interface known as UX/UI. And then, with all these new lessons learned, do a “re-launch” of the platform. Hopefully to a much more successful adoption outcome.

Get User Adoption Right the First Time!

Technology solutions are primarily built to support users in performing their day-to-day activities. Yes, there are many more benefits to what users log and track in the Salesforce Org but that’s all a bonus to serious adoption of the solution. Keep things simple and easy to understand for the users and never, ever, think that the technology is more important than the person. The technology-tail, should never wag the user-dog.

Talk Less, Listen More!

As an IT professional, if you’re involved in the design and rollout of the platform, interview end users and document the key things they do to be successful at their jobs. You may have grand vision for what Salesforce can do for the entire company, but don’t fall in to the trap of thinking your vision is their true need.

• Your first goal should focus on driving an adoption.
• Use the crawl, walk, run mindset.
• Don’t give them or show them more than they need!

After you’ve got them head over heals in love with how well they can do their day-to-day activities, then you can start rolling out deeper capabilities, dashboards, and comprehensive reporting.

Fewer Cliques/Clicks is Better!

Remember where they’ve come from. Most users have learned to live in email, Powerpoint and Excel spreadsheets where most tasks take only a few clicks to update a field or a change in a report. Most new Salesforce users complain about the number of clicks it takes to find, edit and save information in Salesforce, be that an Account, Opportunity, or Contact record.

• Create Views showing the most relevant fields that relate to their daily tasks.
• Teach them to use inline editing. It’s so simple and easy even a 1st grader can do it!
• Just because you may have created two hundred custom fields in an account record doesn’t mean you have to show them all to the end-user in one long, crazy page! It is overwhelming to the user.

Lightning is an amazing interface framework but don’t fall in to the trap of showing more than is really needed in the various components and related lists.

Think, Build, and Deploy with a Mobile Mindset First!

High School is when most teenagers start driving. Whether that be the family minivan, a beater pickup truck or Dad’s second BMW. Not all High School students want to drive the same kind of vehicle. As an IT professional, you may have a sweet desktop set up at work with multiple monitors; don’t think just because you work in a certain way that everyone else does as well.

Most end users, the real movers and shakers and quota achievers are now so mobilized they live and breathe in their iPad or iPhone.

Break these rules and suffer the consequences!

If you do not have clearly understood requirements and logged defects, you will spend countless hours debating over what is in scope, what is not in scope, what defect should be fixed and what defect should be backlogged and pushed to a later sprint.

One defect, discovered recently on a project, was estimated at taking one hour to fix. However, because several of the requirements were loosely worded, we debated on when and how we should fix the defect and if it was required for go-live or not. Spirited debate ensued and we found ourselves stranded in the grey zone of doom. Fortunately, an experienced project manager gave the green light on the fix and we were able to resolve the defect successfully. Applause and cheers!

De-Squish the Defect

I learned a valuable lesson on a recent Salesforce mobile app project I joined two weeks before QA testing was to begin and four weeks before go-live to select retail stores. The mobile team had worked for more than a year to design, develop and deliver the Salesforce Mobile app to in-store sales reps. There were many complex API calls being made to product databases with delivery dates and accuracy in availability was critical. This was not your typical food truck mobile app taking a ten-dollar order of street tacos and guilt-ing the customer into a 20% tip upon checkout. The average order for this client was several thousand dollars with multiple payment types including financing and multiple delivery options of products.

I spent the first day with the transitioning LBC, Lead Business Consultant, on the project going through the many logged defects and it was clear to me that while many were very easily understood and could be addressed in the two weeks, there were some defects that were very “squishy.” In other words, they were very subjective and unclear about what needed to be addressed and more importantly how to fix the defect and be done with it. One defect in particular caught my attention and it read as follows:

“There is a noticeable performance issue.”

Imagine your significant other leaving you a note on the counter with those exact words. Ugh!

As a member of the male gender group I would immediately jump to, ‘did I forget to take out the trash, pay the bills, pick up our tween from a goats-and-yoga class, or worse…”

It’s our duty when logging defects to de-squish the defect. However, that might be a challenge if the original requirement was squishy as well. In this performance issue defect there ended up being dozens of chatter posts about the performance issue and trying to clarify and define it. We began timing page loads, API call-out times, shopping cart loads of all sizes from two to forty-two individual line items–all trying to resolve and close the performance issue defect. At the time of this post, that noticeable performance issue defect is still unresolved–Double Ugh!

Defect Logging Examples

Here are examples of good defect logging:

• When I choose a product from the Automobile Catalog such as All Weather Floor Mat and then select the shopping cart of the customer, the Actual Price of the Product displays incorrectly. The product item shows a price of $100 in the catalog but the price in the shopping cart displays as $89.95.
• When viewing the shopping cart of a customer, I select Proceed To Review and select the Accept Terms and Conditions signature field. When I sign my name and touch the Accept button I get an error screen in red that reads “API connect error: Zip Code not Valid”
• When I touch Proceed to Payment in a customer’s shopping cart, I select the Pay By Credit Card radio button. The amount field is grayed out and I cannot enter an amount to process.

Here are Squishy examples of defect logging: Use at your own Risk!

• The UI has issues
• The shopping cart is not right
• I’m getting lots of errors when I try to add a new record

Rules to Live By When Logging Defects

• Be as descriptive as possible
• Share where you were before and what path you took to get there
• Name buttons exactly if you can
• Take screenshots or video captures
• Add date/time of incident

IN CONCLUSION, (that was my HS English teacher shouting in my ear) regardless of when you join a Salesforce project, bring clarity to everything you do as you contribute to the team. Remember, this is not math, things are never perfect, but if you focus on being clear and not being squishy, your colleagues will thank you and management will sing your praises. In the key of C Major, please.

Go Totally Mobile on Salesforce – Well, Almost

It might seem like a dream come true to have a deployed support team in the field, armed with iPad in hand, ready to service all those cases rolling in. But, without the laptop, those truly mobile professionals just might not see what they should be seeing in the Salesforce mobile platform.

“What Happened to the View?”

Recently, on a Salesforce Service Cloud rollout for a major client, we knew those district managers were the boots on the ground, armed with iPad in hand to view cases, resolve them quickly and to close them so certain SLAs (service level agreements) were not violated. Each of the district managers wanted their own view created that only showed cases marked with their email address. Seemed easy enough.

So, I, the Sr. Solution Architect assigned to the project, went to work, quickly creating a nice view and adding a filter to include only their cases. Proud of my work, I notified the client engagement manager that the views were completed and were now accessible to the mobile users. The client engagement manager notified the district managers that their unique view was ready to be seen. And then we waited, the due praise and accolades should come pouring in any moment.

That feeling when you do a great job…

Within the hour we started getting complaints that the views were simply not there. I checked them all, they were completely public, no restrictions. I spent an hour troubleshooting the issue. Then one of the district managers said they could see theirs no problem. I searched Salesforce help, no luck on a solution.

Or so you thought.

Things just didn’t make sense; district managers shared the same profile and I could see all the views as an admin. I logged in as one of the district managers and could see the view perfectly fine. I spent the day trying to figure out why one district manager could see a view and another could not on Salesforce mobile.

It might feel like there is no solution in sight, but we know when to keep going.

Two days later, through trial and error and hints from an obscure post from a random google search and the clouds parted and the sun began to shine down!

Here’s the skinny: When you create a new view in Salesforce and make it available for all to see, you have to do one simple thing that Salesforce doesn’t tell you to do in order for a mobile user to see that view.

You must first view that view on the laptop or desktop browser.

And then, there is light.

The Solution: How To Missing Salesforce Views on Mobile

Step 1:

Create a view and make it publicly available for your user from the desktop or laptop browser interface.

Step 2:

Have that user log in to Salesforce on the laptop or desktop and actually view that specific view you created for them from the browser.

Or

As an Administrator, log in as that user profile on the laptop or desktop and actually view that specific view you created for them.

Step 3:

Have that user log in to Salesforce mobile and Eureka! Now that view is available to see under “Recent Views.”

The Lesson Learned about Salesforce Mobile Views

Currently there is no menu option in Salesforce mobile to simply look at all the various views that are available and then select the one you desire.

So, for all you Salesforce mobile road warriors, keep the iPad in the ready position, but don’t forget to view things first on the laptop or desktop browser. That way you can see what others might be missing from the mobile experience.

When in doubt, view it on the browser first so you can be assured you’ll see it when you go mobile.

Salesforce mobile road warriors unite!

To Object or Not Object, That Is The Question

We’ve all been there as Salesforce Consultants or Solution Architects; a client is thrilled about the Service Cloud rollout and the amazing adoption rate by jadded SMEs when suddenly someone on the client side blurts out, “Wow, wouldn’t it be nice if we could do X, that would be a huge win!” One hour later we find ourselves lost inside a tornado of solution-ing, which we’ve all been advised not to get caught up in, but we still do it. Everyone has an opinion and it soon becomes a battle-of-the-bands.

Rap battle! Rap battle!

The junior consultant recommends a new custom object, relationship this, dashboard that–BAM! The client cheers and applauds but has no idea what was really recommended. The project manager counters with resourcing this, change order that, new SOW–BAM! And finally, the Solution Architect parachutes in grabs the mic, sub case to case, out-of-the-box this, best practice that–BAM! Mic drop!  Zen sweeps over the room as someone in change management sprays essential oil aroma therapy as everyone looks to the client.

The Client has that Deer-in-the-Headlight Look

Enter the Proof of Concept or POC. Those familiar with the amazing power of the Force.com platform know they can quickly jump into a dev sandbox and within a couple hours, produce a working model of what the client had asked to see. If you’re still in the wire-frame/mockup mindset, don’t go there! If there is a custom branded look that is absolutely necessary put it off until after you’ve nailed the POC.

Pre-flight Check List

Don’t just jump in the Force.com airplane and start pulling knobs and twisting dials. Make sure you’ve got your flight plan well organized.

1. Document the requirements. Check.
2. Validate the requirements with the customer. Check.
3. Login to the sandbox environment. Double check!
4. Configure like a Salesforce Rock Star! Big bold check!

I added a new record type to cases, a few additional custom fields, a workflow rule, and built what I was certain would be an academy award winning “standard” feature POC within the service cloud org. And there she sat, all configured and working pretty, just like I recommended based on my years of experience. I stopped to considered.  I looked back at the requirements, making sure I didn’t leave something off the table. In my review I found an off the cuff comment made by the key stake holder, “Fewer clicks is better. Don’t confuse them.” I counted the clicks it took to complete the designed process and it took a eleven clicks or touches for you iOS mobile users.

I Wasn’t Satisfied, Things Could Be Better

I had decided to configure a sub case or a related case to a case that already existed. When it came to closing cases related to cases however, the click counts, and potential user confusion grew. I remembered what the junior consultant recommended days earlier about the custom object. I had my own internal rap battle weighing what I knew Salesforce would want me to do and what was potentially a better experience for the end user. I could have debated myself all afternoon but I decided to execute a new flight plan in mid-flight and just go ahead and build it–just like that junior consultant recommended. I created a new custom object, related it to the case, added the fields, recreated workflows and stepped back again. The click counts went drastically down to 4 and the user confusion factor fell to almost zero. I tried both options on the iPad and the winner was so blindingly obvious I had to shake my head.

Show Off with Video

I decided to really wow the client by screen capturing an iPad video interaction of the POC from the perspective of a field rep and it flowed really well. I added some narration and bit of background music, ’cause that’s how I roll. She showed the video to the team at their status meeting and BAM!

“You guys made me look like the hero!” exclaimed the happy client.

Lessons Learned

1. Listen closely to what the client has to say; they are the true measure of success.
2. Just because there’s something pre-built in Salesforce that meets the conceptual ask of the client, don’t think it’s the best solution for the end user.
3. Sometimes the most junior person on the team has the best idea. Ugh, did I just admit that?

Oh, and to all you Salesforce Consultants and Solution Architects, “May the Force.com be with you!”

Decades of Movie Making Tradition

I stumbled into a career as a Solution Architect while working for Walt Disney Pictures & Television as an Assistant to the Executive Vice President of production. Part of my daily routine was to man five fax machines early in the morning receiving call sheets and production reports from movies and television shows being filmed around the world. I would retrieve the faxes, make fifty copies of each, double sided, place them in internal mail manila envelopes and then run/ride a bike deliver to every production executive and creative executive on the back lot. Time is money and so I had to deliver those highly critical documents to every executive by 9 am so they were prepared to discuss their project’s status in the 10 am production meeting. All the while, those fax machines continued spitting out deal memos, first shot reports, lunch reports and hot costs all day long and into the night.

We had an unbreakable rule, nothing got shredded, everything got stored. We had storage containers all over the lot filled with historical records from every movie and television show going back to the 1940’s. The crazy thing about the entire paper heavy process at Disney Studios was that every other studio in Hollywood was doing the exact same thing; Warner Bros, Fox, Paramount, Universal, and Sony. I’m sure a small forest was destroyed supplying the movie and television industry with their precious paper.

There Must be a Better Mouse Trap

One day, after about five months of pushing that giant paper rock up the hill every day, I snapped! I blurted out to the Executive Vice President that this process was ridiculous! We make movies for crying out loud, there has to be a more efficient and effective way to communicate and distribute all this “stuff.” Only I didn’t say, “stuff.” I’m sort of a quiet guy, so my boss was a bit surprised–pleasantly surprised.  He was a doer, so he said, “Okay.” Then  he promptly assigned me to work with his VP of Finance for the next six weeks and come up with a plan.

A Solution Architect is Born

That was my very first Solution Architect role, although the title had never been conceived at that point. I worked directly with the VP of Finance to streamline the financial reporting and tracking of all movies and television shows. I actually worked with five other departments as well because Finance effected every facet of the production process. I worked with subject matter experts, SMEs today, created user stories and requirements, researched technology solutions, created a roadmap to deliver, and then presented our plan to my boss. Good news, we got approval! Not so good news, IT refused to be part of it! So, we were on our own. My boss was a get-it-done kick-ass “Tasmanian Devil” and asked me one question, “Can you do it?” Which really meant, “Can you, Rodney Henson, do this?” I should have been scared to death of that question, but I wasn’t. “Yes, I can.” And so it continued.

Change Management Begins with You

Everything was on me to deliver what we had designed collectively. I cracked open books and began to teach myself what was needed to deliver on that roadmap. I, along with a couple of reluctant recruits, learned how to build databases, code HTML, set up networks, auto scan documents to OCR, output PDFs, and so much more. Six months later we launched our new paperless platform to a hand full of shows to test what we had built.

Training users was challenging and difficult and sometimes absolutely horrible. I would have paid thousands of dollars to have a change management expert but the job or term had not been invented. We were changing decades of process with people who were the best in class at their jobs. We did not win everyone over. It was trial and error. But we did win, slowly, steadily. Fortunately, we had an executive sponsor that supported us no matter how rough things got.

The most satisfying part of that entire experience, besides the confidence it gave me that has helped me throughout my career, were the words I heard many times from the subject matter experts on the front lines.

“Wow, I cannot believe how much easier this is!”
“This is amazing!”
“Can I use this on my next show?”

Even the Phantom Menace said, “Thank You”

Three years later while working for 20^th Century Fox I got a call from George Lucas’s production office in Marin County.

The Producer of the next three Star Wars movies got on the phone and said, “Hey, Rodney, I hear you’ve created something amazing. We’d like to use it on Episode 1. Would that be okay with you?”

I hesitated, “I think I can arrange that.”

“Good,” he said, “We’ll fly you up on Friday to stay over the weekend. You’ll be staying in the Lilian Gish Bungalow at the Ranch.”

How to Win the Academy Award

This is no official Salesforce Academy, but perhaps there should be. And my final bit of advice for the exact amount of money you paid to read this blog

1. Discover and catch the vision of what “could be” with every customer you engage with
2. Design with every stake holder in mind, don’t forget the SMEs on the front line
3. Build it and be part of the change management, you’ll learn more than you realize during this process

For all you Salesforce Solution Architects out there, “May the Force.com Be with You!”

We are All Discoverers

In 1492, Christopher Columbus didn’t board his ship, raise his iPhone and smoothly say, “Siri, get directions to the Bahamas,” then sit back and enjoy a peaceful voyage across the Atlantic. Being a discoverer or an explorer was a dangerous job. Did you know one in three sailors during that era never returned? And that doesn’t mean they bought a condo in the Yucatan and now sip fruity drinks on the seashore. I mean they died! From the craziest of things! (Sorry, I digress.)

Often times, a sales account manager will pitch and sell a discovery and road mapping initiative with a formidable client. And normally, the delivery team jumps in, reads the SOW, then sets out to execute and deliver what was initially thought would be the outcome of a discovery and road mapping exercise.

Things are Not Always as They Seem

I was deployed onto such an assignment of discovery with a major global client and on Day One, our team began to hear from the client that certain initiatives of modernizing their cloud technologies were off the table and absolutely not doable in Phase One or Phase Two and that other initiatives were much more important to the company.

Their goal was to modernize their service organization, replace their 20+-year-old legacy systems, and implement the Salesforce Service Cloud to hundreds of call center agents. The initiative that was off the table was to modernize the company’s field service mobile workforce. They said it was too complex and not a priority at this time.

Our team spent several months doing discovery, analyzing the current state, defining the gap between current state and the future state, and presenting justifications for every recommendation. The final SDD (Solution Design Document) was over 200 pages of in-depth commentary, diagrams, screen mockups, and architectural jargon.

It was during extensive client review of the SDD that our team of discoverers floated the idea there was, in fact, a way to deliver the one thing that was “too complicated” to address: the field service component of their company.

Enter the Salesforce Field Service Lightning Platform

We felt it could be done using the Salesforce Field Service Lighting (SFSL) platform. We received a lot of pushback from the client and Salesforce as to why we could make such a bold assessment and recommendation when clearly there were other more pressing needs and easier wins. As a team, we beat up the concept vigorously and at the end of our internal battle, we decided it could absolutely be done, and that we as a team had to present the idea as a viable option. However, what we did realize in our debate was that we did not know the SFSL platform well enough to address all our concerns and the client’s concerns. So, our discovery continued, and we set out working with our Salesforce rep and arranged for them to host a demo of SFSL, focusing directly on our client’s processes. There was a lot at stake — our team’s reputation and our company’s perceived value to the client.

A Demo Day for the Books

On the day of the demo, we had all the stakeholders and subject matter experts from the client, as well as our anxious team. Long story short, the Salesforce rep who led the demo was fantastic. We all learned so much about SFSL and although many had seen a demo previously in years past, we realized how powerful the SFSL platform had become.

During the demo, there was a palpable sense of excitement from our client as management members of the mobile group started asking all sorts of great questions. I came away from that demo with a strong sense of confidence in not only the SFSL platform but that our team had risen to the occasion and turned over every stone of discovery until we landed on a big win for the client.

Sailing into New Territory

In the end, the client decided to move the SFSL rollout to their mobile workforce to Phase One and put everything else on hold. Now that was not something I would have ever guessed would happen four months after we began discovery with a very amazing client.

So, all you explorers and discoverers out there, the next time you begin a discovery initiative, no matter how big or small, don’t get too caught up in the preconceived outcome of your sessions. Be open to discovering some pretty amazing things, magical perhaps, for not only the client but for you, as well.

Oh, and be grateful that as consultants, we don’t have the attrition rate of explorers in the days of Columbus!