Tuesday, July 14, 2015

Agree on Guidelines Before Adding Code

Remember how your high school and college research papers were graded partly on niggling formatting concerns?  The point was to make sure we all used ibid, idem, op. cit. and loc. cit. correctly.  By getting us all following the same style, the teacher had an easier job understanding our work and we learned to better understand the work of others.  These are the same reason you should define code guidelines for your Salesforce org.
A good style guide provides grounding
without weighing you down.

Whether you are a Salesforce Administrator who works with vendors for your development needs or an in-house developer yourself, documenting basic code style and guidelines for your org should be considered a must.  Code guidelines help ensure that the code can be maintained for years to come and that the org is well documented down to the code level so that admins and developers alike have a thorough understanding of what takes place in the org.

A lot of Apex programmers start with the Google Java Style Guide, which is a great starting point, but you may want to create something brief to share among everyone writing code for your org.  Here are some suggestions for a brief Apex Style Guide:


  1. Avoid unnecessary whitespace.  Whitespace is helpful for indicated blocks of code, using indentations at the beginnings of lines or blank lines before methods, for example.  But whitespace inside of lines of code adds to maintenance time.
  2. Use tab rather than spaces for indenting lines of code to ensure they line up properly and reduce character count.  Indent lines of code within a method by one level from the method.  Indent the code contained by a loop by one level from the line that sets up the loop, for example.
  3. Limit code to 100 columns wide, even in comments so that it can be read without scrolling.
  4. Break SOQL statements into multiple lines with new lines for each clause: From, Where, Order By, etc.  Selected fields should be listed in ascending alphabetical order.

  5.   Map<id,account> aMap = new Map<id,account>([SELECT Id,Name 
                                                  FROM Account 
                                                  LIMIT 50000]);

  6. Comments should appear at the beginning of every class and at the beginning of every method in block format (/* */).  
  7. At the beginning of each class, comments should
    • describe purpose and list related files (classes, triggers, components, VF pages, etc either called by or that will be calling this file) as well as HTTP services called, if any
    • list author name(s) and creation date
    • include modification dates and authors and purpose of modifications
    • list business processes in order they are addressed in the code as a brief summary of methods.
  8. At the beginning of each method, comments should
    • Describe purpose and detail parameters and returned values.
  9. Trigger logic should be contained in at least two files: the Trigger and the Handler(s) containing the business logic.
  10. All code should be ‘bulkified’ to avoid exceeding governor limits when multiple records are processed, at the very least, SOQL and DML statements should only appear outside of loops.

Naming Conventions

  1. File names should begin with a Primary sObject name, followed by a description of the action the code performs, followed by the type of class (eg. Controller, Extension, Helper, Utility, Test, Trigger).  For example, you might have the AccountAddressUpdate Visualforce page and the AccountAddressUpdateExtension controller extension.
  2. Avoid spaces and underscores in file, class, method and variable names.  Also avoid abbreviations when possible.  
  3. Method names begin with a lowercase verb.
  4. Classes should use camel case (eg. CamelCase) while Methods and Variables should use nerd case (eg. modifiedCamelCase).  You could have a controller extension class called AccountAddressUpdateExtension with method updateAddress and variable newStreet, as an example.
  5. Use all caps for constants such as MAXIMUM and MINIMUM.  Constants should be placed after the class header comments and before the first method and method header comments so they can be easily located and updated.
  6. Append “Test” to the class name for all test classes.  For example, the class AccountAddressUpdateExtension would have a corresponding AccountAddressUpdateExtensionTest. 
  7. Collection variables should be plural or otherwise represent the fact that they represent a collection (eg. recordMap, newAccountMap).


  1. Remove System.debug statements before pushing code to production.
  2. Require positive and negative scenarios in unit tests using assertions that are clear. 
  3. Salesforce defines minimum code coverage as 75% but we prefer minimum code coverage of 90%.


  1. For integrations, employ a 'single source of truth' model where possible—data should be stored in one location and referenced by other systems or pulled on an as needed basis only. A redundant system should be created for backup purposes, but should not be used as a data source except in the event of failure recovery. 
  2. Follow the rule of 3 and the abstraction principle. If the same code is used 3 or more times, it needs to be implemented as a reusable class, method or loop. Programmers sometimes refer to this as DRY v WET : "Don’t Repeat Yourself" vs "We Enjoy Typing"). Create abstract code for reusable procedures.

Friday, December 5, 2014

Get Ready Glossary for Administrators Learning to Code

If you are and administrator learning to code, you already know more than you may realize.  I've started preparing a glossary to help you with programming terms by giving you similar examples from your daily tasks as a Salesforce Administrator.

Database customization and coding, it's all connected.
  • Data Types:  When you create custom fields, you have to specify a data type: Date, Text, Currency, Number, etc.
  • Polymorphism:  When you use "+" in a formula for two text fields, it concatenates, when you use it in a formula with two number fields it adds them.  This different behavior in different scenarios is polymorphism at work.
  • Variables:  Fields that let users input values are variables.  They can be changed if needed, just look for the label you gave and edit the data.
  • Constants:  Your org ID is a great example of a constant.  It's a value that will not change in your org.
  • Objects:  Okay, this is confusing.  When you start programming, you will see that Salesforce objects are now referred to as SObjects.  This is because object oriented programming languages use the term Objects to represent data collections.  Oh, hey, that's what objects are in Salesforce too, basically.  Only oop objects can also have actions related to them, things that you can do to them or things that they can do to other objects.  Oh, hey, sObjects are the same if you think about workflows as actions that are related to specific objects and think of triggers as actions that let one sObject act on another sObject.  So maybe this isn't confusing at all.
  • Array:  In the Salesforce database, you have a record ID associated with a bunch of fields -- record name, created date, etc.  This is essentially an array of data. Apex uses the term List rather than Array, but they are the same.  Lists can be multidimensional too.  For example, you can have a list of data from fields for a single contact record, or you can have multiple records in a list and each of those records will have its own list of field values.  List Views are two dimensional lists of data.
  • Cast:  In programming, you can force a variable of a particular data type to be treated like a different data type.  Similarly, in Salesforce, you can use Formulas like Text(PicklistSelection__c) to force a field, in this case a pick list, to be treated like a different type of data, in this case Text.
  • Model-View-Controller:  This is easy for you.  Model is the data model.  When you create custom objects and fields in Salesforce, you are changing the data model, native objects and fields are also part of the data model.  View is the user interface.  When you edit page layouts, you are changing the view.  Controller is any automation.  You might add workflow rules or formulas to effect data based on rules and reasons you define.
  • Boolean data: Think of a checkboxes.  They are true or false, checked or unchecked.
  • Boolean Operators: And, Or.   You may be using these in formulas or in list view filters already.  If you look for this value AND that value, both must be true.  If you look for this value OR that value, only one of them needs to be true, but both true will work as well.
  • SOQL: SObject Query Language lets you express in a few words the kinds of information you already use defining List Views.  For a List View, you sepcify filter criteria for selecting specified fields from the given object.  You might select First and Last Name from Contact with filters looking for records where the phone number is blank, for example.  SOQL lets you express the same sort of thing when programming in Apex, using a few key words.

If you want to write code for Salesforce, Visualforce will handle the View portion, Apex will handle the Controller portion, and Salesforce will continue to handle the Model portion of your program.  You will probably find yourself using data types you are very familiar with from Salesforce fields as you set up variables and constants.  And you will find SOQL easier to understand if you think of them in the context of list views, returning lists or arrays of data you request.

For a more complete introduction to programming for the administrator, please watch this Dreamforce session on coding for non-developers: http://dreamforce.vidyard.com/watch/haqgdyryAtDoQdMsOieTTA

Saturday, November 22, 2014

Learning Coding Skills May Be Easier Than You Think

Last week, I tried to convince you how easy the path can be from Salesforce Administrator to developer.  This week, I'd like to look at a couple of additional resources for the administrator who is beginning to dabble in code.

Don't be afraid to step out of your comfort zone and
try new skills.  You may be better than you think.
As I've mentioned before, Flow, or Visual Workflow, is a lot like a visual programming tool in the ways that it can be used to add complex functionality and alter the Salesforce user interface just by clicking on various programmatic elements.

But you can make Flows even more impactful by employing Visualforce as well.  With Visualforce, you can further customize the user interface and even incorporate HTML, CSS and JavaScript to provide more bells and whistles.

Visualforce also opens the door to more programmatic control over your Flow.  You can create more complex data interactions, such as referencing static resources, by adding an Apex controller to a Visualforce page that calls a Flow.  You can also use a custom Apex controller to specify a variable finish location for the Flow, for example finishing on a newly created record detail page.

I have written about this previously on my blog, here: http://www.snugsfbay.com/2014/04/salesforce-flow-using-record-ids-at.html

You might also be interested in watching a Dreamforce session I co-presented on this topic, which includes all the code you need to customize your Flow from start to finish, including the unit test: http://dreamforce.vidyard.com/watch/7mBX_EQGTTz8pmZeo0724A

Either way, I hope that you'll agree Flow is a great tool for administrators who are interested in expanding their skills and taking on more complex business problems.  And it provides a great stepping stone into learning to code in Visualforce and Apex as well.

Sunday, November 16, 2014

Salesforce Administrators May Be Developers Without Realizing It

The path from Salesforce Administrator to Developer is much easier than the path from developer to administrator, I have come to believe.  It is easier for administrators because it is a natural progression.  Administrators build skills starting with user management and data security and expand on these basics by building out customizations and user interface changes through native Salesforce clicks not code.  Administrators go from making use of solutions provided by Salesforce to making use of native tools to create custom solutions.

Being a Salesforce Administrator can be very enlightening
for anyone who wants to learn to develop code.
Developers take the opposite approach.  They go from developing their own solutions to trying to learn and keep up with solutions already provided by Salesforce.

If you are an administrator who has built custom fields and objects, you are well prepared for understanding programming concepts like data types.  A date time field is different from a number field, you know that already.  You may even know that you can use formulas to force fields of one data type to be evaluated as a different data type; for example, you can convert text to a Date field using the following:


For a developer, understanding the Salesforce data model is more complex.  Not only do they need to understand that fields are of a specific type, they need to understand how those fields relate to the data model as a whole, and that could involve native functionality like roll-up summary fields or complex data sharing rules and existing workflow rules that enforce specific, custom behaviors.

The adventurous administrator has a reasonable and natural path to growing their skills as a developer as well.  From developing custom fields, objects and user interfaces through page layouts, administrators can begin employing more complex tools.

With Flow, or Visual Workflow, an administrator can create complex user interface changes, including combining inputs for multiple objects on a single page (a master and child record, for example).  Flow also lets administrators run complex data consistency rules, enforcing best practices at a system level rather than expecting users to memorize and consistently act on arcane rules themselves.  Flow gives administrators a chance to manipulate the data behind the scenes in ways that previously may have required a trigger as well.

If you are interested in getting an introduction to Visual Flow, here is a Dreamforce session I co-presented that may help: http://dreamforce.vidyard.com/watch/dq8giCcDC8MIPiKYDRgTyg

Flow also provides an opportunity for administrators to expand their logical thinking skills.  Planning out the steps of a Flow and ways to test the Flow before making it available to users are skills that translate directly to planning out a program that you may want to code and finding ways to test it.

Next week, I will share some more tips on making the transition from Salesforce Administrator to developer.

Friday, October 31, 2014

Gamify Your Salesforce Implementations

Gamification has crept into the business world where companies seek to engage and reward their employees, customers and partners.  For the Salesforce administrator, gamification can also be a valuable tool.
Give users a way to power up!

For your next implementation, whether an implementation of a new application in an old org or an implementation of a brand new org, consider how gamifying the process can make things easier for users.

Any new business tool can seem overwhelming at first.  If there are too many options, users might have a difficult time mastering even basic skills initially.  This leads to user frustration and discourages them from using tools available to them.  But what if tools offered only the solution users needed at the point that they needed a new solution?

With gamification, individuals are rewarded for executing specific tasks that indicate their level of engagement.  In the world of video games, this means that players begin with easier tasks and limited resources and then build resources and skills to meet their next level of challenges in the game.  You don't start the game by battling Bowser in his castle with the racoon suit in Mario World, after all.

Salesforce users can benefit from the same approach.  If you limit users by giving them access to the most basic set of features initially, you can build their confidence with using Salesforce and build their interest.  When users gain access to new features, they can take the time to figure out how best to incorporate them into what they already know how to do.  And users will be happier if they can have new features after they begin to recognize a need for the feature in their day-to-day work.

To make the process work for you, the administrator, employ permission sets or create graduating levels of user profiles to add access to new features when you are ready for users to level-up.  It gives you the chance to roll out new training materials and focus support efforts in a staggered fashion as well.

With the gamify approach, as an administrator, you can focus on training users for specific skills over time.  You can train users in basic skills and provide support while building a base of power users for those basic skills.  When users are ready to move on to learning and implementing a new set of features and skills, you can spend your time training and supporting them while relying on your power users to continue to help anyone who is still struggling with earlier skills and features.

This process requires an administrator to know how features fit together and to
have an understanding of how users will implement Salesforce features.  If you build out your permission sets and profiles ahead of time, you can respond to any users who want to power through all the 'levels' at once and you might even be able to get their help writing up a 'game' guide for others.

Saturday, September 13, 2014

What It Means To Find Success

The San Francisco Bay Area has its share of famous people, and for the most part, San Franciscans could not care less.  So when I saw a familiar looking face near China Town, well, it could have been a famous person, but if it was, he was dressed like a panhandler.  He was entertaining a group of tourists on the corner.  That's not odd either, San Francisco has some entertaining buskers.

At home, I told my kids that I saw someone who was likely this famous person they would recognize.  One of them had time to go downtown with me to see.  'No,' my kid said, 'it's not him.'

But it didn't matter.  The guy had been entertaining tourists and we stopped to be entertained as well.  He told riddles and made us laugh.  He invited my kid to hang out with him any time when I took their picture together.  It was an enjoyable moment with someone we normally wouldn't be talking to, whether it was the famous person or the panhandler didn't matter.

Even though my kid said no, I still believed that it could have been the famous person in a bit of disguise, just hanging out.  Why would a famous person do that?  Why not?  It would be an opportunity to connect with people without particular regard for social status and money.

I went back a few days later for an autograph.  That's right.  I decided I didn't care one way or the other whether this was the famous person or the panhandler.  There are a lot of people who aren't famous at all who deserve to be treated like a star, and everyone feeling a little down-and-out can benefit from a bit of appreciation.  I wrote a note of thanks for entertaining us and spreading joy.  The message applied to either the star or the panhandler.  But I put some money in the card just for the panhandler.

I'm keeping the autographed picture for my kid.  I don't know what kind of success my kids might ultimately find, but I hope the photo reminds them that nothing of much importance separates the star from the panhandler.  And opportunities to connect with other people offer the best success any of us can find.

Now what does any of this have to do with Salesforce?  If you check out the community at success.salesforce.com and the power of us hub, you will see two online communities where people connect on business and technical topics, including offering each other professional and career tips.  It's a very friendly and supportive environment.  Salesforce clearly has invested resources into keeping the community strong and relevant and the opportunities to connect with other people truly offer all of us more chance of finding success.

Sunday, July 20, 2014

Living in a Bubble

I have been happy in my bubble, where women are prevalent in technical positions, leadership and as developers.

The bubble started when I was in college, completing a computer science major.  My graduating class had the most women completing the computer science major of any class the university saw from that point on, with 45 of us graduating that one year.  Just a few years later, the same university would see 0 women graduating with a computer science major.  Though numbers soon climbed again, they have yet to reach the same peak.  Similar universities have had similar number fluctuations.

Do you see this as disruptive technology or a necessity?
After graduation, I eventually wound up working in the world of nonprofits.  Look around there and you will see women running the show from the top down.  According to the 2013 GuideStar Nonprofit Compensation Report, there are more women than men who run mid-sized nonprofits.  The number of women in IT and database design and administration, at least in the Bay Area, appears to be high as well, from my personal experience.

In addition, women are hailed as early adopters in a lot of technical arenas. A social media study reported by BlogHer found that "Women have an appetite for the latest gadgets and apps," particularly ones that are useful or fun.

So I've been a bit surprised by all the talk about tech companies lacking diversity and failing to employ women in technical or leadership positions.

There is a view that strong teams contain like-minded people, and that may be true if all you want is a strong team, strong enough to plow forward with weak ideas.  But if you want strong ideas, you need to challenge your solutions by creating teams of diverse thinkers who are comfortable defending their ideas, listening to other points of view and adapting to come up with even better ideas.

Innovation springs from a diversity of thought and experience and leads to ideas that can disrupt industries or invent new ones. Remember, problems inspire creativity, so don't be afraid to expose your teams to a broader picture of the problems they set out to solve.

When elevators had able-bodied, human operators the controls were placed at about elbow-height.  The placement of the controls remained the same even after operators became obsolete.  But with a more diverse viewpoint, someone finally designed an elevator with controls at foot level as well as elbow level.  If you've ever entered an elevator with a cup of coffee in each hand or a large box of equipment, you might see the use of this feature for an even more diverse selection of elevator passengers including anyone who has trouble using their fingers for such tasks as pressing buttons.

We all need to leave our comfortable bubbles to learn new things, broaden our points of view and expand our knowledge so that we can develop stronger solutions with broader appeal.  That just doesn't happen very well without diversity.