The Unselfish Admin, Part 3: Release Communications

Three times a year, I spend at least a full afternoon reading the notes for the upcoming Salesforce release. I have to be honest – it’s tedious and nap-inspiring. Nobody wants to read that many pages, I don’t care how much you love your job. (If I’m wrong… then you win the Ultimate Geek award, whoever you are!) But we need to read those release notes, so that we can be prepared for whatever is coming our way, be it new features or just a different look and feel.

To make new features even easier on admins, Salesforce gives us a preview of the upcoming release in our sandboxes. But have you ever thought about how useful this info could be to your users? If you have a large user base of non-admins, imagine the confusion they must go through when something looks completely different, or is moved around, or is renamed… so why not give them a preview, in the form of an easy-to-swallow release communication? If you are already going to read the release notes – and you really should – then this is not much more work!

1. Check the release schedule on the trust site so that you know exactly when your Salesforce instance will be updated.

2. Go through the release notes. List the features that you want to share with your users. If something noticeable will happen automatically, make sure it is on your list. Also list any features that you will be activating. Do not list things that will only be visible to an admin or developer – it’s unnecessary and will cause confusion.

3. Test new features in your sandbox. Take lots of screen shots, they will make your release communication easier to read (translation: less boring!).

4. Don’t forget to think about your audience! If your users have completely different profiles and will not be seeing the same things after the release, you may want more than one version of your communication.

Examples? Here are a few things that I mentioned in my Summer ‘13 release communication:

New design of the login page – you might think this is insignificant. But more than one person thanked me for mentioning that, because it was such a big change!

The new “My Settings” page – another significant change in appearance. I made sure they knew how to get to it, and what it would look like. (In case you are wondering why I crossed out the Change Password link, we use single sign-on.)

Chatter had some great enhancements as well, Topics being the most popular.

We emailed the release communication out to all staff, just before the weekend that we were getting updated. Depending on your organization, you may need a different plan – maybe you do not assign a Salesforce account to every employee. Or you may choose to save it as a document that your users can access on an internal wiki or a shared drive. Try to be as clear and concise as possible – don’t just copy the release notes, craft them into an explanation that will make sense to the average user. (Remember this blog post…?)

If you plan to activate some features at a later date, you can split your communication into more than one piece, alleviating the pressure of tracking too many changes or fielding too many questions all at once. But whatever you do, your users will be grateful for the heads-up, feel included in the process, and use new features with more confidence.

Putting your Regions on Lockdown

I recently received a question from a fellow admin, and I want to share it because this is such a common need, and there is more than one way to handle it.

“I am going to be adding regions to the Accounts in our SFDC instance. I want to be able to make it so that the assignment is done based on the country and so there is no manual intervention. Do you have any ideas how I might be able to accomplish this?”

Definitely! There are a couple of ways that this can be done.

1. Formula field: If you want your “Region” field to always be based on the account’s state or country, then I recommend a formula field. Here is an example of how you could set up US regions by state:

IF(ISBLANK(BillingState), “None”,
IF(CONTAINS(“AK:AZ:CA:HI:NV:NM:OR:UT:WA”, BillingState), “West”,
IF(CONTAINS(“CO:ID:MT:KS:OK:TX:WY”, BillingState), “Central”,
IF(CONTAINS(“CT:ME:MA:NH:NY:PA:RI:VT”, BillingState), “East”,
IF(CONTAINS(“AL:AR:DC:DE:FL:GA:KY:LA:MD:MS:NC:NJ:SC:TN:VA:WV”, BillingState), “South”,
IF(CONTAINS(“IL:IN:IA:MI:MN:MO:NE:ND:OH:SD:WI”, BillingState), “North”, “Other”))))))

You could also do this by country:

IF(ISBLANK(BillingCountry), “None”,
IF(CONTAINS(“US:CA:ME”, BillingCountry), “North America”,
IF(CONTAINS(“AR:BE:BO:BR:CH:CO:EC:GU:HO:PE:UR:VE”, BillingCountry), “South America”,
IF(CONTAINS(“UK:FR:ES:PT:FI:DK:SE:NO:NL:CH:DE:BE:AT:IT:GR”, BillingCountry), “Western Europe”,
IF(CONTAINS(“RU:RO:LV:LI:PO:HU:SI:SV:”, BillingCountry), “Eastern Europe”,
IF(CONTAINS(“CN:JP:KO:TH:VT”, BillingCountry), “Asia”, “Other”))))))

Downside: You have to rely on accurate data in your state or country fields. You may want to create a validation rule limiting those fields to two characters – but they still need to be the right two-letter codes.

Something to consider: A formula field can never be edited – this can be good or bad depending on your data requirements. Only use a formula field if there are no exceptions to your criteria!

2. Field Dependency: Another way to do this is to use picklists for state and country values, and then create field dependencies. As an example, I’ve created a field dependency where the controlling field is my custom picklist “US State” and the dependent field is “US Region.”

When you select a state, you are only allowed to select the region that you have assigned to that state. (This could be done for country just as easily)

Downside: You’d be using custom state and/or country fields instead of the standard fields. If you convert leads and map that data to accounts, you would need to create the same fields on the lead object and map them accordingly.

Upside: If the regions for some states will occasionally vary, then this option allows for that.

Another upside? Salesforce is offering state and country picklists in the Summer ‘13 release – this will be in beta, but could prove very useful.

3. Workflow Rules: Those first two options are the best for data integrity – but they do not have the flexibility to allow for occasional random exceptions to your usual criteria. Workflow rules can be used to populate your regions automatically, but still allow a record’s region to be edited if necessary. Here’s how.

  • Create a picklist field, listing all of your regions – be sure to include “Other” or “Multi-region” if there are exceptions.
  • When you get to security for the field, make it read-only for all profiles except the System Administrator.
  • Next, create a workflow rule for each region, based on your state or country criteria. Select “Evaluate the rule when a record is created” – this will allow future editing without firing the workflow rule.

Now, when a user converts a lead or creates a new account, the region will be auto-populated. The user will not be able to edit it – but a system administrator can change it if there is a random exception.

These ideas do not only apply to regions – there are probably many other fields whose data integrity can be improved by formulas, field dependencies, or workflow rules + field-level security. Using those three options can make consistency a reality in your database, so keep that in mind every time you create a field that needs to be accurate or locked down. For you as an admin, it’s data integrity – and for your users, it’s less work. Everyone wins!

The Unselfish Admin, Part 2: Breaking the Language Barrier

Do you ever have conversations with your users where you don’t understand each other at all? It could be that you receive a simple request, but it is phrased in a way that isn’t “Salesforce-speak.” Or you could be explaining a particular function, and the person’s eyes just glaze over as if you are not even speaking their language anymore.

Now, be honest – did you get frustrated with the user for not understanding your wonderfully elaborate technical response? Or for not knowing the right terminology when they asked for your assistance? We have all been there. And I’m willing to bet that most of us have treated at least one of our users like they were a complete idiot. My opinion – I can hear the Twitter followers dropping like flies as I type this – is that this sort of communication breakdown is the fault of the admin.

Here are some examples of simple words that you and a non-admin Salesforce user may not think of in quite the same way:

Okay, that may be a bit of a stretch – but hopefully you get the point. Terms that make perfect sense to you can be complete gibberish to the average non-admin user. I’ve said the following…

“You can’t save it because of the validation rule”

“Which picklist values are you referring to?”

“You can’t edit it because it is populated by an Apex trigger”

…and I’ve had a lot of “what on earth are you talking about?” reactions.

It’s time we start speaking to our users in a language that they understand. Remember the SNL skit about the condescending IT guy? Salesforce admins have become that guy at an alarming rate over the past half-decade or so. At my current company, we have over 300 Salesforce users – and I can count on one hand the number of people who have asked me to teach them Salesforce terminology. So why are we expecting that from them? A perfect example: I have several friends who are programmers, and they don’t expect me to understand what they are talking about when they get onto that subject – but they don’t disrespect me for it either.

So simplify. Remember that to a non-admin user, “it’s automated” makes a lot more sense than “an Apex trigger is rolling up the sum of Field X from This Object.” Be as clear as you can be with as few boring technical details as possible. It’s not the job of the user to learn Salesforce terminology – they’ve got stuff to sell! Let’s help them and train them in a way that makes it easier for them to log in, do their job, and move on. And maybe someday the “Unselfish Admin” will be more common than the “Rock Star Admin.” Better yet… maybe we can be both.

So You Want to be an Admin…

Most experienced Salesforce admins did not set out with that goal in mind. Most of us fell ass-backward into it, enjoyed it so much that we stuck with it, and voila! A career happened. But the massive growth of Salesforce.com has attracted a lot of attention, and as their customer base expands, so does the need for admins and consultants. I’ve been asked, “How do I become a Salesforce admin?” quite a bit lately, and it has made me realize that the next generation of admins will most likely pursue that path, rather than stumble upon it by accident. Future Salesforce admins, this one is for you!

1. Determine what you want Salesforce to do. Do you have a full understanding of CRMs and all that they can do? If you had your own company, what would prompt you to seek out a CRM? If you don’t know business processes and how they can be improved, you can still become a Salesforce admin. However, business analysis is a large part of Salesforce administration, and without that part, you run the risk of making decisions which do not support core processes.

2. Sign up for a developer org. The best way to learn anything is by doing. Start by signing up for your own developer org – don’t be intimidated by all of the “developer” stuff on the page, it’s just a free Salesforce environment of your very own. You can create records, customize it, and try out anything you are curious about. Even if you already work for an organization that uses Salesforce, it’s best to try out your new skills someplace where you won’t affect real data (think flight simulation training for pilots – makes sense, right?). Once you’ve got your developer org, go right to the next step…

3. Read Salesforce.com for Dummies. There’s no need to struggle through Salesforce in the dark like I did, back in the days before admin blogs and certifications. This book will cover the basics and save you a lot of unnecessary searching. Of course it can’t keep up with all of the latest features – however, it contains enough basic information to still be very useful, just be sure to get the latest version.

4. Play! There are some exercises in Salesforce.com for Dummies, start with those. Create some data in your developer org. Create some imaginary users. Create custom fields, change page layouts around, and see what it looks like. Think about step #1 – business processes – and come up with a hypothetical business need that would require Salesforce customizations. While you are experimenting, click the “Help for this Page” link that is in the upper right of each page – this will take you to the help documentation for whatever object you were on, but it also has a complete list of help topics on the left for you to browse.

5. Watch some videos. Every year, there are hundreds of sessions at Dreamforce, many of them targeted at admins of all experience levels. Check out the Dreamforce YouTube page and watch the ones that look interesting to you.

6. Join the community. Salesforce has one of the best user communities I have ever seen. Ask questions, check out ideas that other people have posted (many of which were turned into features), and search for help on anything and everything.

7. Go to Dreamforce. If you or your employer can afford it, I highly recommend going to Dreamforce. It can be overwhelming, but go with a plan and you will come back with some great knowledge. I wrote a blog on Dreamforce preparation last year that you should check out beforehand. Oh, and you’ll want to make your hotel reservations now. The hotels nearest to the convention center are already full!

8. Keep learning! Having been a Salesforce admin for almost six years, I can say with absolute certainty that there will always be more to learn. And I’m sure I will be able to say that in another six years. Keep digging and learning – I find that when I begin to get bored, it means it’s time for me to try something new. Check out the Chatter workbook, the Analytics workbook, the the Security workbook – lots of fun stuff in there! (Where do you think I get some of my blog ideas?) Look into certification – you can take the admin training class, or you can just study like crazy and take the exam. And when you feel like you are really up for a challenge, start reading the Force.com Fundamentals book, and going through the exercises in your developer org. That was one of my favorite learning experiences!

I hope this is useful info for all of you new and soon-to-be admins out there! Please feel free to comment if you have additional advice.

Oh and last but not least… read my blog. Duh.