Adding comments and descriptions to configuration changes in Salesforce may take a minute now, but may save you hours in the future. Read on to understand why getting into this habit is a best practice that you want to ensure you are following now!

I was just reading an email post from Jen Lee about Flow and automation and she mentioned that everyone should provide descriptions for their fields and whatever they're doing or building. A good place to start building this habit would be in Trailhead - every module where you build something. A good practice to get into would be to indicate the Trail and module that you’re using that field, flow or process builder for. That way, when you run into it later on, you can figure out why it’s there.

 "A good practice to get into would be to indicate the Trail and module that you’re using that field, flow or process builder for. That way, when you run into it later on, you can figure out why it’s there."

As an admin, you could continue the practice by getting yourself into the habit of stating the underlying reason for a field, object, workflow or process builder. In addition to the help text which helps end users fill the field out, information could include: who asked for it, what initiative it was part of and the key reason for creating it. Most of us tend to forget why things were created after about six weeks. That way, seven weeks later when someone wants to know what a field is for, or whether one of fifty process builders should be kept, there’s a description there to tell people what will potentially break when you’re trying to clean things up. Also, if six months later, the organization changes direction, you can remove those things that weren’t part of the process and won’t fit the new direction.

"In addition to the help text which helps end users fill the field out, information could include: who asked for it, what initiative it was part of and the key reason for creating it. Most of us tend to forget why things were created after about six weeks."

People should get in the habit of adding a description to everything they create in Salesforce as an admin. This would be especially helpful for those of us who inherit orgs that aren't that new.  Sooner or later, that person could be you. Many times I've looked at a field or a custom object or a permission set that was created 2 to 3 admins ago and I have no idea what it's supposed to do or what will break if it’s deleted or changed. While your boss may have been there 12 years, s/he may forget or have no idea, as s/he wasn't involved in the creation of the field, object, process builder or workflow, at all.   And if they are as new as you are, they won’t be able to help. You are left with nothing to do. You’ll be stuck and your boss will be looking at you with that expression that says, “Now what, smart aleck?!?!?!” You’d certainly wish the previous admin was smart enough to put these descriptions in place, to future-proof the system.

Even if as an admin, you’re looking at your job as only a way station to that great developer job down the road, and you want to wind up becoming a developer, it's still a good habit to get into - for one very simple reason: you are supposed to comment out your code, so others know what is going on with that particular piece of code.  Otherwise, it can cause lots of problems. Your co-workers could be stuck with code they don’t know what to do with, and then they have to spend hours, testing, reviewing and guessing what that piece of code is supposed to do when all of this could have been avoided if you’d gotten into the habit of describing things. You will end up creating far more problems than you’ve tried to solve.

"Your co-workers could be stuck with code they don’t know what to do with, and then they have to spend hours, testing, reviewing and guessing what that piece of code is supposed to do when all of this could have been avoided if you’d gotten into the habit of describing things. You will end up creating far more problems than you’ve tried to solve."

Keep in mind that Salesforce indicates who created a field as well as workflows, so your co-workers will know who failed to comment things out. If you run into people who work at one of your old jobs, they might be looking at you and thinking, “Oh...so this is the idiot, who created all those problems for me!”, and that is a big thumbs-down for any professional. So go ahead, blaze the trail, but leave crumbs to help the people who will be following after you. It’s always good to be just a bit more mindful and helpful of others.