Saturday, August 22, 2015

Nurture Creativity, Passion And Collaboration To Be Innovative

The Salesforce Trailhead online training modules are inspiring a lot of us to learn new features and exercise what we already know to earn points and badges. And to have fun with Salesforce. There are modules, or trails, specifically for admins or for developers and trails for specific activities like learning about Event Logs. There is even a trail for getting ready for Dreamforce.

These are definitely worthwhile exercises for anyone interested in encouragement to practice new skills. Once you get started, they draw you in with virtual rewards that inspire continuing with a just-one-more goal. And the list of trails is growing at great speed to ensure that just-one-more goal offers something new and different.

I wanted to explore how this popular project came to be so that I can encourage that kind of innovative thinking among my teammates. So I interviewed Lauren Grau, Developer Relations at Salesforce and a member of the Trailhead team, and here's what I learned.

According to Lauren, the Developer Marketing group was looking into ways they might improve on the existing training workbooks. While these were popular for learning Salesforce, they didn't always provide a clear path or define a way to progress beyond introductory steps. It was also difficult for the folks at Salesforce to gauge the usefulness of any particular workbook. Were people getting stuck? Were they making mistakes?

Coincidentally, while that group was looking into improving the workbook training experience and exploring new tools like those from Udacity, one of the developers on the Developer Evangelism team, Josh Birk, was working on a side project called "Medals". Josh intended to demonstrate using the Metadata API to verify changes in an org based on steps in training. As a group, Developer Evangelism is all about coming up with cool uses of the platform to inspire people and Medals was another project intended to inspire developers with the power of the Metadata API.

According to Lauren, this kind of creative exploration is not limited to any single team. Salesforce is willing to help "carve a space" for projects that employees are passionate about and the company is filled with people who are passionate about Salesforce products. Salesforce has even encouraged that sort of creativity with project challenges that eventually get released as Salesforce Labs applications on the AppExchange.

While marketing had started creating learning paths based on roles and flow charts of the "known universe" of the Force.com platform, the demo of Medals was catching fire among all who saw it. In some companies, these two efforts would continue on their independent paths, but at Salesforce, collaboration and alignment across departments is a huge part of the culture. They use Chatter to connect people and ideas and have a "great open door policy" according to Lauren.

This combination of technology and policy helps Salesforce overcome barriers to innovation that other companies find insurmountable. As a result, the people who could bring together the two teams, marketing and evangelism, did so, and brought in the documentation team as well.

The people involved in Trailhead are passionate about solving the problem of helping Salesforce admins and developers with the task of keeping up with the cloud. With Trailhead, Salesforce can provide training that offers real-time feedback and does not require switching back and forth between disparate systems like workbook and computer to execute training steps. The gamification elements ensure that training is fun and addictive while well-thought-out projects and paths make the skills taught even more meaningful.

Luckily for all of us who enjoy the training modules, Lauren tells me "there is still a lot we haven't gotten to do with Trailhead that we've got planned". New learning trails and badges are on their way, expanding beyond the platform to other clouds as well. There will also be trails for end-users. Just imagine pointing users to Trailhead for learning and relearning tasks like running reports and using filters to see just the data they need.

If you have ever wished you could create your own learning trails for Trailhead, you will get your chance as Salesforce expects to harness the power of its incredible community for content creation and review. Beyond that, we'll have to wait and see what ideas develop thanks to Salesforce nurturing creativity, passion and collaboration so that fun and innovative projects like Trailhead thrive.

Sunday, August 16, 2015

Rethink Salesforce Projects With Great Administration Techniques

System administrators are getting more tools with even greater power with every new Salesforce release.  Tools like Lightning App Builder, Process Builder and Visual Flow work like visual programming tools.  They offer clicks-not-code solutions that can bring down project costs of time and expertise by eliminating the need for developer involvement in the creation and maintenance of all but the most complex projects.

This year at Dreamforce, I will be helping admins learn skills they can use to better plan and implement projects in their orgs.  Please look for my sessions here:

Getting To Know Visual Workflow (Tuesday session)

and

Getting To Know Visual Workflow (Thursday session)

Choose either of these sessions to learn about this powerful tool.  It requires no coding experience to use, but works like a visual programming tool enabling you to improve user interface and user experience, manage data consistency and integrity, and automate business processes without needing to write any code.

7 Essential Tips Every Admin Should Know About Apex

Whether you are working with in-house developers or hiring contractors, learn what to look for to ensure the code you are getting follows best practices and meets your needs.  This session will introduce you to concepts that will help ensure the overall health of your org and help you to work better with developers.

Trailhead Gladiators

Join us for these fun sessions on Tuesday, Wednesday, and Thursday to discover how Trailhead helps you stretch your skills.  You may be able to win prizes, but best of all, you will see what Trailhead has to offer as a learning tool.  And with more knowledge, everyone's a winner.

Friday, August 7, 2015

Some Projects Deserve to Die

A vendor on one of the Salesforce projects I was designing said to me: "Some projects deserve to die."  He wasn't talking about our project, which deployed on time with great features, but I was still shocked.   Why would a project deserve to die?  And how do you know when you are working on one of those so you can help ease it out of existence?  If you think of your in-house projects in terms of investments, you can categorize them:  cash cow, rising star, mouse trap, and dog.

In-house tech projects can be seen as cows too.
The best categories for a project are cash cow and rising star.  Cash cow provides great user experience at low expense with regard to time, and expertise. They offer high return on investment, or ROI, for that reason.  The cow represents everyone's favorite technology, users love that it does what they need and you love it because it doesn't require a lot of upkeep.

The rising star is in-house tech in-the-works and has high needs for time and expertise with low ROI during early design, configuration, and implementation stages because users aren't getting much benefit yet. Even with low or no ROI during this development cycle, the rising star is expected to become a cash cow when it is closer to completion and once users are trained.

The two project categories that need reconsideration are the dog and the mouse trap.

The Mouse Trap 


Then there are the mouse traps.  These projects have a high ROI, but the maintenance costs are also high -- they are like Rube Goldberg inventions in complexity and while they may have gotten the job done as conceived, users are outgrowing them and finding flaws.  These projects deserve to die.  These in-house projects are integral to users, yet too costly to maintain.  And having a project that lives in the high maintenance, high expense side of the quadrant can't be a good thing.

cash cow, mouse trap, rising star, dogOne company asked me for help with their mouse trap.  They had so many custom objects making up a customer survey that they required custom Visualforce pages for reporting and couldn't leverage the flexibility of Salesforce standard reports.  What they could have accomplished with clicks-not-code if a Salesforce administrator had been involved in designing the original solution got bogged down in complexity and code making it completely inflexible -- not a good trait for business solutions.  Code edits were required for any meaningful changes to the reports.

At some point, the money poured into this project had been made good through ROI because the Visualforce reports are so integral to their business, but user needs have changed and the solution doesn't work as well as it should now.  As complaints and change requests rise, so do maintenance costs in time and expertise.  Rather than spend to maintain, in this case, it makes more sense to spend on a redesign to reduce maintenance costs long term.  These mouse traps seem useful, but these are the projects that deserve to die.  Users wish they could do more with the integral tech, but the complexity of it makes expanding functionality just too costly considering time and effort.

The Dog

Your dog may need updating.


For in-house tech, a dog is a product with low maintenance costs that has low ROI. It's the infrequently accessed tech or is used by a small audience, it might even be a quick fix you created to help a single user.  The dog, with its low maintenance and low ROI seems like it has nothing going for it, but in fact these projects can lead to easy wins.  Do they just need to be promoted in house to make the use and value better understood?  Can they be nurtured to grow into a rising star by interviewing users regarding ways to improve what the tool does without a lot of expense?  Some in-house tech just seems to get stuck in phase I, minimum viable product, and needs a nudge to get going in the right direction again.

These dog projects, with low cost and low impact, offer opportunities to explore easy solutions.  I did a creative side project for the Little Bits Olympics recently that didn't make it out of the dog stage.  The project description suggested two hours for the project, so that's what I spent. This time budget limited my choice between using a rare earth magnet attached to a servo to alter its polarity versus an electromagnet that required more effort to hack into my Little Bits electronic circuit.  Because of the time budgeted (like any expense), I chose to test the quick approach and was not completely satisfied with the result.  The ROI was low, the cost was low, it was every bit a dog.  But it did work and gave me great preliminary knowledge for planning phase II which will have an electromagnetic bell type design once I budget the additional time to hack the circuit.

Consider the dogs in your org and look for ways you might be able to teach them new tricks or make them more relevant to users.  And as for the mouse traps, don't get caught by them, a lot of people want to continue to throw resources at outdated solutions to try to convert them to cash cows, but the best approach might to be to let these projects die and start something new to take their place that will offer easy maintenance at low cost relative to time and expertise.

Saturday, August 1, 2015

Mistakes Small Companies Can Avoid When Working With Consultants

If you are considering bringing in help to work with you on your Salesforce implementation, make sure you have executive support for your project as well as a dedicated internal resource to own the project when it is complete and to nurture it along the way.  Make sure that the people (or person) responsible for upkeep and support of the completed project are involved early in the roles of tech lead and business analyst and that they approve the approach that they will ultimately have to support.  
Working with a consultant shouldn't be like
swimming with sharks

Those are the most essential requirements for a successful project, but you can avoid costly errors by considering the following suggestions as well:
  1. Get a signed NDA.  Your data is valuable, your code is valuable.  You are turning complete access over to someone who should be happy to sign an NDA.
  2. Understand your data before giving access to it.  You should know your data and have a written plan for maintaining data quality (such as best practice documents and descriptions of validation rules, workflow and triggers) or at least a plan for improving data quality (can you describe what you think of as duplicate data?). 
  3. Start writing a specification for what the business should be able to accomplish when the consultant is finished and how users will be interacting with whatever the consultant implements.  Even if all you need is to have a few third-party apps installed, you should describe user access and data interactions you expect to see and define the business process you hope to address. 
  4. Get the travel costs and incidentals spelled out, including maximums you are willing to pay.  And agree up front whether meetings need to be in person, or can they be online. 
  5. Document in the contract who owns any code and what they can do with the code going forward.
  6. Question their recommendations, most consultants want you to be an active partner and understand the work they are putting in for you.  Questioning offers a chance for early resolution if you can uncover a mismatch between their understanding and your reality.  At the very least, you stand to gain a better understanding of the solution they are offering.
  7. Trust the consultant once you decide to hire them.  Not trusting your consultant is evident when you hold back information or limit their access to users and decision makers.
  8. Make sure your company understands a project's functional specifications.  What is the minimum you expect the consultant's work to accomplish for you and how will you recognize when it is complete?  Involve end users and management both in this process and document their needs and processes in order to guide them through User Acceptance Testing.  Highlight for users the holes and pain points that are being addressed so they will understand the purpose of the project and what it looks like when complete.
  9. Specify the project goals and how you will measure their success.  What is it that you hope users will accomplish and how will you measure user success.  For example, if you want users to be able to map their accounts and find nearby accounts when they are on the road, you can try to measure how often they use the feature, but you are probably more interested in whether more accounts are being visited on each trip so the latter is a better measurement of success.
  10. Ask your consultant which vendors may be paying your consultant to sell their product into your org.  Ask them to disclose any commission they would be eligible for at the time they recommend those vendors.  There is nothing wrong with commissions, but you may want to independently look into some competitive products for your own understanding of the value of the suggestions your consultant offers.

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:

Style

  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).

Deployment

  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%.

Fundamentals

  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.