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 affect 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:

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:

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:

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:

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

Wednesday, July 16, 2014

Using Flow Rather than Apex: Performance Tests

Some of the newest Flow features allow for working with collections of records and using a single operation for adding those records to or retrieving them from the Salesforce datatbase.  In the past, Flow could only create or retrieve a single record at a time, but recent features give administrators a visual interface for creating powerful and automated solutions to their business problems using clicks-not-code.

Checking time required and limits for Flow.
As the capabilities of Flow converge with those of Apex programming, administrators will no doubt start handling some of the same tasks with Flow that previously required Apex.  Creating and updating records automatically is a great example of a task that administrators with no programming experience can now manage themselves, for multiple records at a time, with Flow and no Apex code.

But if you have a choice between two tools, it is interesting to see how they compare.  Flow is obviously easier than Apex for anyone not trained to code, while Apex is more flexible.

Benchmarking performance differences reveals the impact of using Flow to replace Apex.  I tested this by coming up with both a Flow and a bit of Apex code to create new records for a custom object and comparing their performance according to feedback from the developer console. 

Performance Comparison

To start, I created a simple bit of Apex code to add 1,000 records to a custom object.  The developer console tracked CPU usage as well as the number of database manipulation language (DML) statements, both of which are performance concerns for anyone watching their governor limits.

I then replicated the code using Flow to add a large number of records to my custom object so that I could compare the performance relative to those same governor limits.  Thanks to the collection variable available with Summer '14, I was able to create a Flow that managed a single DML statement for multiple record insert operations using a Fast Create element.  Previously, this would require a single Record Create element for each new record and so the number of DML statements could become excessive and slow without these new features.

Unfortunately, Flow was more restrictive on the number of records I could manipulate with both the collection variable and the Fast Create element.

For the collection variable, I found that I was only able to hold 499 records with a single variable.  Apex is not so limited with lists and arrays.  This limit meant that I could not create as many records with Flow as I could with Apex.

For the Fast Create element, I was even further limted by Flow.  With Apex, up to 200 records can be insterted with a single DML statement and more records can be submitted with insert operation.  Salesforce automatically divides the operation into multiple statements for blocks of up to 200 records.  For example, 201 records result in 2 DML statements according to the debug console.  My Flow got stuck at 200 records, I could not use the Fast Create when my collection contained more.  Even with 200 records, the debug console reported 2 DML statements being executed for the Flow.

Having to reduce my test size meant that neither the Apex nor the Flow had any measurable use of CPU time.  I look forward to being able to insert more records to better compare performance.

One of the Salesforce critical update messages suggests that enabling governor limits for Flows will have an impact on performance.  You should test your Flows with this update enabled before it goes into effect by default in 2015.

Sunday, July 13, 2014

Leveraging List Views With Salesforce1

The good thing about Salesforce1 is that you have to rethink your user experience and data access for mobile.  Yes, I said good thing because rethinking data access with the mobile user in mind will result in a better user experience for someone on the road than shoehorning everything from the desktop onto a more limited device would.  With Salesforce1, you can provide mobile users with access to data specific to their needs while on the road thanks to Flexipages.

Try something different just for mobile users.
A local nonprofit where I occasionally do volunteer Salesforce development work wanted a mobile app to provide users with quick access to specific groups of records.  These users need to update about 200 or more records a day using a mobile device.  And they want some flexibility regarding the order in which these records might be accessed.

My first thought was to create Visualforce pages that would offer specific groupings of records, but the nonprofit really needed something more flexible.

So I turned to Flexipages to solve the problem.  With Flexipages, you can design a mobile-specific interface that relies on List Views to provide access to specific groups of data.

At their most basic, Flexipages simply define which List Views for a specific object should be incorporated into the mobile experience, including the Recent Items list.  If you can create a List View that prioritizes Accounts Needing Attention, for example, the mobile user can bypass the Accounts Tab and just access that list with a Flexipage.

But Flexipages don't merely offer a single List View, they can combine multiple List Views and Global Actions all in the same screen.  So a Flexipage might offer access to Accounts Needing Attention and Currently Discounted Products all with a single navigation graphic, in addition to a Global Action for creating a New Contact.

In crafting a mobile experience for your users, consider creating Flexipages and putting them at the top of the navigation menu, above the standard tab navigation options like Account and Contact Tabs.  This gives  users more immediate access to specific records of interest to users on the go.

For the nonprofit, I created several new List Views to combine different records on the same page.  I also added an image formula to signify which records had been updated on the road to help the user easily determine which records still needed attention.  You can read more about using images with Flexipages in a recent post.  I also created about 10 different Flexipages to provide the most flexible access to all the records they update via mobile.

Flexipages are easy to create as text files outside of Salesforce.  They are XML files, which are simply text files with specific textual "tags" enclosed in triangular brackets.  For example, "<description>" is a beginning tag and "</description>" as an ending tag, while the text between these two tags would be the actual description.

Once you create a Flexipage, the easy option for deploying them, currently, requires placing them in a zip file with a particular directory structure and naming convention, and including a second XML file listing which Flexipages to deploy.  The zip file can be deployed with Salesforce Workbench using Migration>Deploy.

For more information about creating Flexipages, refer to the documentation here:

Once you consider which data is the highest priority for mobile users, simple List Views, combined with Flexipages, provide the view your mobile user needs to the data they most want.

Saturday, July 12, 2014

When Not To Use Triggers

For administrators who don't code, hiring a developer to create a trigger can be a frustrating proposition, but what else can you do when you need to automate a business process with Salesforce?

Movie props may need triggers,
but administrators can get by without them.
In my experience, many of the processes I need to automate are triggered by a user action on a single record, or are required in order to update a list of records because of a specific change to the database model.  I may change the data model from using a multiselect picklist to check boxes, for example, and need to update all existing records to set the new check box fields based on existing picklist selections for each record.

Salesforce offers Custom Buttons, Links and Actions for updating a single record from the record detail page.  Perhaps converting a Lead to a Contact, for example.  And Global Actions can act on lists of records, such as when I want to create a new field and populate it in all existing records based on existing data.

To define, within Salesforce, the process that needs to be automated, administrators can use Flow rather than Apex.  Flow lets you retrieve records and manipulate them before saving those records, or new records, to Salesforce.  By embedding a Flow on a Visualforce page, it can handle the automated processing and logic associated with the Action or button.  Here is an example of a Visualforce page to initiate a Flow, named "FlowName":
   <apex:page sidebar="false" showheader="false">
    <flow:interview name="FlowName"/>
While Flows are easy to use and don't require programming experience, administrators should still learn to think like developers when creating Flows. Beware of using Flows in your production org without thorough testing first!  You can't develop Apex in your production org, which keeps you from damaging your data while you are developing the logic to automate data manipulation.  You should test your Flows in a Sandbox first to protect your data as well.

In the future, Flows will also be able to work with Triggers, but for now, you can have much of the same functionality at the click of a button.

Tuesday, July 1, 2014

Think Like a Developer When You Design Flows

Flows offer a lot of power to clicks-not-code administrators who want to automate processes using record lookup, update and create options offered with this easy-to-use feature.  Of course, Flows do require that administrators learn to think like developers a bit.  They must be able to outline the process the Flow should take, including decision points where the flow might go in one of multiple directions.  They must also think of ways to test and debug their Flows and to create Flows that can be reused or called in multiple ways.
You need to know how to look for bugs in your Flow.

Test Extremes

One rule of testing is to keep in mind the extremes and the improbable.  What happens when users enter data that is out of scope, or when a record that the Flow expected to exist (like a generic, default Account record) has incorrectly been deleted.  Make sure your Flow includes fail-safe procedures and uses error messages, which Flow makes available, to catch these situations.

Break Points and System.Debug

As you are developing your Flow, be liberal with Screens to display the values of variables along the different Flow paths.  One of the things I love most about Flows is the ability to create Screens that I do not tie into the Flow.  This enables me to create break points that halt the Flow before the error occurs and lets me display debug messages for myself between steps, providing the values of variables needed in subsequent steps.  When the Flow is ready to be activated for users, I can first disconnect all of the extra Screens and leave them in the Flow if there is a chance I will need to rework the Flow.

For example, between the record lookup step that assigns data to variables and the decision branch step where the Flow's path will be determined according to variable data, I will create a Screen to display the record ID and all of its variable data.  I won't bother to connect the Screen unless I find that the decision branch does not behave the way I expected.  I can even leave the Screen in place to use as in future versions of the Flow or to use later, when the data model defined with Salesforce objects and fields may have changed (the 'model' part of the Flow).  Otherwise, the Screen stays disconnected from the Flow.

Flow Triggers

For Flows to be used with Workflow rules, they are expected to operate without a user and so trigger-ready Flows cannot have Screens, which require a Flow user to click the 'Next' button to proceed.  This can complicate the debugging process, but don't be discouraged.  When you are first creating a complicated flow, you can still use Screens and simply call the Flow from a link or, to easily pass parameters, a Visualforce page.  See my earlier post for more information about calling a Flow from Visualforce.  Keep in mind that trigger-ready Flows cannot include Screens with error messages and so should be thoroughly tested outside of the workflow rule, to work out ways to avoid errors during the Flow execution.

Deleting the leftmost and rightmost columns
makes this Flow trigger-ready without Screens

Design Patterns

Converting a working Flow that has been created with Screens to one that is trigger-ready and without Screens is easy if you just employ a simple design pattern.  For my Flows, I keep the data and logic elements like decision branches and record manipulation, which you could call the 'controller' or core part of the Flow, in a vertical path down the center of my design.  For the Screens, which you could call the 'view' part of the Flow since that is the part Flow users can see, I push those elements out into columns to the far left and far right of my controller elements.  For example, a simple Flow would have two columns, the leftmost would be Screens only, the rightmost would be logic and record manipulation only.  A more complicated Flow might have Screens on both the rightmost and leftmost columns, like the one illustrated here.

By keeping Screens in their own columns away from the logic, they can be quickly selected within the Flow designer with a single motion and deleted from the design  when you are satisfied with the functionality so that the Flow can be used as part of a workflow without user intervention.

Flows can be executed by Visualforce pages, by other Flows, and by users; with Summer '14 Apex will be able to execute Flows as well.  They can be executed  from record detail pages using buttons, links and Actions; from Tabs, Site pages and from Global Actions.  Keeping the Flows small and function-specific will help make them reusable in these many scenarios so that you don't have to recreate the same functionality in multiple Flows.  For example, a Flow that operates from a workflow rule and also from an Action on a record detail page might have the 'controller' elements in one Flow that can be called by a Flow Trigger as well as by a Visualforce page that would provide some 'view' context for the user executing the record Action.

Even clicks-not-code administrators can be creative developers once they start designing for multiple uses and considering the debugging process and Model-View-Controller implementation patterns.  And as you become more comfortable thinking like a developer, you may eventually decide to learn more about the Debug Logs and Developer Console.  But with Flow, you might even decide you don't need those to create complex business solutions that work well for your users.

Saturday, June 28, 2014

Avoid Flow Trigger Errors Associated With User Records

With Summer '14, more users are finding more to processes to automate with Flow Triggers.  This is just a note to let you know that the User record does not behave like other records when used in a Workflow rule.  It can cause "MIXED DML OPERATION" errors, and simply report that your "trigger failed to execute the flow with version ID 30111000000..." or something very similar.

A time-based trigger can be set to fire behind another trigger.
This happens when a Workflow Rule triggers by creating or editing a User record and also executes a Flow Trigger to manipulate records from other types of sObjects rather than the User record alone.  In particular, it happens when a Workflow tries to update one of these fields on the User record as well as other sObjects like Contact or Case:
  • UserRoleId
  • IsActive
  • ForecastEnabled
  • IsPortalEnabled
  • Username
  • ProfileId
Here are some techniquess to avoid encountering the Mixed DML Operation error message:
  1. Try using a different sObject, not the User record, for Workflow Rules and Flow Triggers if you encounter the error regardless of which fields are being updated.  
  2. To update the six standard fields listed above, create two different Workflow Rules, for example:
    • Initiate the first Workflow Rule off a record other than the User record.  Use this other sOject to trigger updates to custom fields on the User record for any of the above six  fields.  You can operate User custom fields safely alongside data from other sObject records in a single workflow.  
    • A second, time-based Workflow Rule can operate on the User record alone and update the above fields based on changes to your custom versions of those fields.  This Workflow Rule only operated as a time-based trigger and only allows for field updates on the User record.  Note: do not check the box on your User-based Workflow Rule that calls for all workflows to be reevaluated.  If that box is checked, you may experience the DML error again.
  3. If you don't want to run two separate Workflow rules and must manipulate one of the User fields based on changes to the User record, don't do it in a Workflow.  Instead, create a Visualforce page to call the Flow and create a custom link on the User detail page to access the page and Flow.  Click here for information about passing record IDs to a Flow with Visualforce.  The Flow will manage each data manipulation request as a separate transaction if it is not called by a Workflow and so the Mixed DML error should not occur.
Using one of these techniques with Flow Triggers can avoid the problem of having a trigger fail to execute a flow due to mixed data manipulation errors.

Wednesday, June 25, 2014

Simplify With Record Types, Field Dependencies and Validation Rules

Salesforce administrators should have the goal of simplifying and error-proofing the data-entry process for Salesforce users.  This makes for happier users, fewer day-to-day problems, and better data.  But User Experience is rarely a class at administrator school.  So here are some pointers to keep in mind:
User don't want too much data or too many options.
  • For two column entry, users tend to want to see the entry progress linearly down one column, then the other, rather than zig-zagging from column to column.
  • Fewer options in picklists are easier to navigate.
  • Consistency is important for design, field naming and data entry.
  • Data entry on keyboards should require few or no mouse clicks.
  • Users don't want unnecessary options cluttering their screens.
One way to put this into practice is by making good use of record types, field dependencies and validation rules.

Record Types

Record types help users by limiting the number of fields available on the screen for any particular data.  If, for example, you have a Salesforce object called Equipment, you might want different record types for Electric Vehicle and Petroleum Vehicle because electric vehicles won't need to track gallons of gas.  Having different record types lets you customize the fields to be only what is needed for any given data set.

But record types are exclusive.  If you have Vehicle record types for Electric and Petroleum vehicles, what will users do when they need to select Hybrid?  You can simply add more record types, but at some point your list can get unwieldy if you aren't careful.

Imagine using a single object, Equipment, to track vehicles, computers and more.  If every vehicle type and every computer or mobile device type, etc., requires its own record type, the list could be endless and difficult to maintain as new equipment types become available in the future.  In this case, broader record types can be used and other database design considerations can be employed to help users view only the options they need for their data.

Field Dependencies  

For a record type of Computers, we might offer a picklist to specify whether a piece of equipment is a desktop/laptop or a mobile device.  A single subsequent picklist can offer options tailored to each device. With any two picklists, you can define a field dependency that limits the options available on the second list depending on the selection made from the first list.

For example, an Equipment object with a picklist offering Desktop/Laptop and Mobile as options, might have a single multi-select picklist with status descriptions.  You don't want Mobile device data showing up with a status of "bad hard drive", but you can remove that option from the picklist for all Mobile data by defining which options to include based on a field dependency.

Validation Rules

As useful as field depencies are, not every data entry option can be expressed as a picklist.  For other fields, validation rules can provide similar limitations.  For example, if you have two Equipment data sources for temperature, one for freezers and one for heaters let's say, the range of valid data will be different for each of them.  With a validation rule, you can provide a single field, but check that the values make sense for different kinds of data being entered.

By designing a data model that makes good use of record types, field dependencies and validation rules, you can protect your database from bad data and give users a better experience as well.  If you can eliminate extraneous options, users will not have to sift through fields and choices to get their work done, nor will they have to go back and check whether they put in a negative or positive value for that freezer temperature because the system will do all that for them and improve not only the data quality, but also the user experience.

Wednesday, May 7, 2014

Salesforce1 and Connected Apps Update

As a follow-up to a previous post about connected apps, I wanted to share information about a change with Salesforce1 as of mid-March 2014.  If you are looking for a list of users who are accessing their data via Salesforce1, the Connected Apps detail page "View OAuth Usage" option is no longer the best place to get that information. 

Looking for Salesforce1 users, look in the login history.
Salesforce1, unlike other Connected Apps (Workbench, AppExchange, etc.) removes users from the OAuth Usage list when their refresh token is revoked.  This token allows users to remain logged in to a Connected App without repeatedly providing their credentials.  Settings allow administrators to set a time for revoking the token if users should not remain logged infinitely.  When the user logs out, the access token is also revoked.

For the Connected Apps detail page, Salesforce1 users who have logged out and have no access token may not appear in the list.  The only users that will appear are those who remain logged in via their mobile devices.

You can still find out which of your users are accessing data via Salesforce1 on their mobile devices, though.  Instead of using the Connected Apps list, export the login history for your users and sort based on Application to find all of the "Salesforce1 for iOS" entries.  (Note that sorting on the Application without exporting may not group the data.)

To revoke access for users, rather than going through the "View OAuth Usage" option, you will need to make changes to the Connected Apps detail page.  In that case, you may want to change settings for user authorization and/or the refresh token. 

Thursday, April 24, 2014

How to Interview for New Skills

Someone recently asked me to recommend interview questions for a company looking to hire a Salesforce Administrator/Developer.  This question is particularly interesting for small nonprofits and companies that are looking to bring in knowledge and skills that don't already exist in the company.  How do you ask questions and judge the answers if you can't already answer the questions yourself and aren't sure what to ask?
What do your questions look like?

Consider what you stand to gain or lose by asking questions you do not understand.  For example, I was asked once if I had any experience with the "Apex Exchange".  While this sounded unfamiliar at first, I figured out that they were asking about the "AppExchange" and simply not pronouncing it correctly.  The fact that the interviewer would ask this question said a lot about what someone might expect while working there.

Here are some questions that anyone should feel comfortable asking:
  • What most helped the job candidate pass certification exams?  (Hopefully this reveals extensive and varied experience with Salesforce in the real world.)
  •  What challenges have been the most interesting in Salesforce and why?  (This may give insight into what they find challenging technically or collaboratively.)
  • And how did they find their way through that challenge?  (Hopefully they can describe a process of discovery and growth.)
  • What do they like the best and the least about the Salesforce release cycle? ( Hopefully this reveals that they re-engineer as needed to work with new features.)
It is important to hire someone who can demonstrate an ability to learn, grow and problem-solve independently as well as communicate well and understand the needs of others.  My blog post about a video, 'The Expert', shows some examples of what businesses want to avoid.

For interviewers without specific skills, the need for someone who has those skills is coupled with a need for someone who can communicate clearly and make you feel confident with their process.  If no one in-house has the technical experience, then you really have to decide if applicants have the ability to find information and solve problems independently while bringing all the stakeholders along.

Friday, April 18, 2014

Salesforce Flow Using Record IDs at the Start or at the Finish

Salesforce Flow can be combined with Visualforce pages to provide greater flexibility and automation to the user interface so that Salesforce users have fewer opportunities for mistakes. 
Racer X doesn't always like to start with the group.



By invoking a Flow through a Visualforce page, you have the option to create a button on the particular object you intend to manipulate.  In this example, a button on the Lead object is configured to access a Visualforce page that invokes a Flow to convert the Lead.

Because the button exists on a specific record detail page, the standard controller makes the record ID accessible for the specific data being displayed when the button is clicked.  This means that the record can be converted without additional Apex code.  The Visualforce page would look something like this:

<apex:page standardcontroller="Lead" >

    <flow:interview name="LeadConversion">
            <apex:param name="thisLeadID" value="{!Lead.Id}"/>



Finishing the Flow by bringing the user to a specific record detail page is more difficult. The easiest solution by far is to provide the information and actions the user needs as part of the Flow rather than as something they see after the Flow is finished. 

But even the complicated solution, adding Apex code to a custom Apex controller or extension to specify a finishlocation, is not too difficult.  Simple code enables Salesforce Flow to finish on record detail page. Even so, there are some considerations for defining a finishlocation:
  • Visualforce is required to specify a finishlocation and only URLs in your Salesforce instance can be specified within the finishlocation attribute on the Flow according to documentation
  • For variable finishlocations, an Apex controller is also required
  • Rather than referencing variables as part of the finishlocation, use a variable in place of a finshlocation on the Visualforce page
Here is a simple method to add to your Apex controller code to use a specific record ID in the finish location:

        public PageReference getpRefFinishLocation() {      

            String temp = 'home/home.jsp';
            if(myflow!=null) temp = string.valueOf(myflow.RecID);
            PageReference pRef = new PageReference('/' + temp);
            return pRef;


Use code like the example above to access a variable, RecID in this case, from your flow and incorporate that into the URL for the page users see when they finish executing the Flow.

Friday, April 11, 2014

Provide Mobile Users with a Rich Experience Using Flexipages and Salesforce1

How do you make the most useful data available to users on a mobile device?  You may want to limit text and reduce the need for swiping and scrolling.  Think about the types of activities you are most likely to perform using your phone – texting, calling, photographing, listening to and watching or just looking.  We love the multimedia capabilities and the rich data we experience at a glance with mobile devices.  Salesforce1 provides an important new feature to help you create a more engaging and mobile-efficient interface for your Salesforce data.
Red flag understocked merchandise.



Make use of Flexible Pages, or Flexipages, to create a more engaging and mobile-efficient interface for your users by providing useful graphics and text in record lists directly off a tab.  Mobile users should be able to get as much data as possible in a glance and images can help make that possible.  For example, you can use image formulas to display graphical representations of a record’s status.  For an Opportunity, you might add an image formula to represent where in the pipeline each record happens to be.  This way, salespeople who are on the road can glance at a list of records to determine which need the most immediate attention rather than swiping and reading through a list of text.

Unfortunately, early Salesforce1 releases don’t support image formulas in the tab view.  Tab fields are determined through the Search Layout options, these are the fields users see when they select an object tab on desktop Salesforce, and image formulas have historically been useful here.  Yet the first time a user selects an object tab in Salesforce1, it won’t display images.  While this may change with later releases, there is another option available to early adopters as well.

For the most rich data experience, you can bypass the object tab using Flexipages and make data with images available with a single tap on the Flexipage tab.  Flexipage tabs access the first few fields of either a specific list view or recent items, both of which can use image formula fields.  Note that for recent items on a Flexipage, the fields come from your defined compact layout for that object rather than the familiar fields your users see in their desktop experience.

Flexipages also give you the ability to combine multiple data objects in a single list to even further reduce the tapping and swiping required for accessing the most critical data with a mobile device.  If you use the recent items list in the desktop Salesforce sidebar, you are already accustomed to seeing multiple objects in a single list, all highlighted with an informative graphic.  Replicate this type of user experience for mobile users with Flexipages.

For an example of how to create Flexipages, check out the documentation here:

Thursday, April 3, 2014

Don't Let Expertise Stand In The Way Of Creativity

A funny video has been making the social media rounds called "The Expert" by Lauris Beinerts.  While I find the video to be hilarious, I don't sympathize entirely with the character known as the expert, but also with the folks trying to hire him.  They have specific needs and he fails them in a multiple ways because he lets his expertise stand in the way of creativity.

A creative approach can make the impossible become likely.
Mistake #1:  He says "No" to one of their specifications.  Rather than telling them it can't be done, he should take the opportunity to ask more questions, deep dive into their requirements and find out exactly what they would like to achieve.  Maybe he is missing some other key requirements by not asking for a bigger picture of what they need.

Mistake #2:  He fails to educate the customer.  When the customer asks for something he cannot deliver, he fails to educate them about the limitations, although he does make some effort at this.  He should take the time to align their expectations with the limitations of whatever system they may be using.

Mistake #3: He doesn't offer to do more research.  If he took the time to look into their requests and came back to them with a follow up proposal, he might find some creative and interesting approaches to their problems.  Just for fun, lets look at some of their requirements:
  • Red lines from green ink? Perhaps he should try color changing markers or a system of filters and lights.  There are also thermochromatic pigments and color-shifting paints that could offer fun solutions.
  • Red lines from transparent ink?  Perhaps he should put the lines over a red background or try special magic markers.  Will the customer accept red lines cut from construction paper and colored with transparent ink?  
  • Seven perpendicular lines?  Perhaps he should investigate working in 7-dimensional space.
  • Make one of the lines a kitten?  A 1-dimensional kitten might meet their requirement, but the expert did not ask enough questions to find out.  Maybe they would rather have a combination of lines and curves?
The need is two-fold:  experts need to hone their communication skills as well as their creativity.  Experts need to be better communicators and have the patience not only to discover what the end-goal of a project really is but also to help everyone understand the project's limitations.  In addition, creativity will make any expert even better.  Take the time to explore challenges that would otherwise seem like impossibilities rather than just saying "No".  As with improvisational acting, experts in any field should strive to build on the ideas of others rather than negating them.

Monday, February 10, 2014

The Very Beginner's Guide To Your Salesforce Implementation

For smaller organizations just getting started with Salesforce, the possibilities it offers can seem overwhelming.  But it is not as challenging as it seems if you make sure you have a plan.

Prepare to dive in!

7 Considerations for a Salesforce Implementation

1.  Find your data.  Talk to every department and ask them what data they share and where they store it.  Some people find their own solutions and you may discover stores of data you didn't even know existed.  You may be surprised by how many different places the same data is being stored by different departments using different ways to store and work with the same data.  Don't forget to review what's on your website as well.

2.  Get to know your data.  When you are confident that you have located everything, compare what different departments are storing.  Where is the overlap, and where can you suggest more avenues to share information.  This is also your chance to start looking for bad data, duplicates, missing information and inconsistent data values. 

3.  Familiarize yourself with Salesforce features.  Get to know how different data objects, like Contacts and Accounts, interact.  Look at the data sharing, security and permissions options.

4.  Start a dialogue with potential users.  If you can set up a committee to drive implementation success, you should include not only the individuals who might be enthusiastic supporters, but also the ones who may be your biggest detractors because they can both help you create a solution that works best.  You should be talking with decision-makers and super-users who will be spending the most time using Salesforce. 

5.  Create a three part plan.  Part 1:  which business processes need to be addressed first and foremost?  Can you pick a smaller project that can be rolled out quickly to have a big impact and get users active right away?  Part 2: how will you configure your data in Salesforce?  If you are migrating from a different database, this is your chance to reconsider whether the data model works.  Part 3: how will you get users onboard?  Have your training and support processes well thought out and take advantage of Salesforce features that enable users to look for the information and help they need while they are in Salesforce.  Think about what best practice documents you will need to produce for users and start them during the planning process.

6.  Try everything out with a Sandbox.  Once you commit to using Salesforce and they convert your trial org to a production org, you can set up Sandboxes to test out all of your plans.  You can customize Salesforce and load samples of your data in a Sandbox to
determine how well everything works together before rolling changes out to all of your users.  You can even have your committee review and approve the final implementation plan after they've seen it in action in the Sandbox.

7.  Look at third-party applications on the AppExchange.  If you have a particular business process you would like to address with Salesforce, look at its native functionality first and consider how much customization you are able to do yourself, but also take a look at existing solutions.  You can install applications in a Sandbox to test them and make sure you find them easy to use for your particular needs. You can also use the AppExchange to find developers and consultants to assist you along the way.

Regardless of whether you plan to hire a consultant or do all the work in-house, keep in mind these seven considerations to help make your Salesforce implementations go more smoothly. 

Monday, February 3, 2014

5 Ways To Get Help With Your Salesforce Problem

Q:  How many different ways can you find help with your Salesforce implementation, administration and development?  A:  Lots!

If something appears to be off, you can easily find help!
Salesforce is so chock-full of features and the thrice-yearly releases offer so many improvements, it can be challenging to keep up.  For administrators who support smaller implementations, they may be the only person trying to keep up with everything that Salesforce can do for your business.  Salesforce has found a way to help with both of these situations by offering multiple avenues for help and support, including making it easy for the community of Salesforce users and administrators to help one another.

When you find yourself in need of help, here are my top five recommendations for finding the answers you need:

1.  Help and Training -- Salesforce offers standard and Premier Support and training for most users.  Help, without training, is offered for users with developer accounts.  Salesforce Help and Training should be your front-line for finding out how to do things in Salesforce.  All of the product documentation is searchable here, including some Best Practice documents.

Premier Support is what you want your support to be like, really.  Open 24 hours a day, they will track down even the craziest problems and solve them for you.  In addition to fantastic support, the online training available with Premier Support includes several of the classes offered in-person by Salesforce University. If you are working on Salesforce certification, you should definitely take a look at these training options!  And developers should note that Premier Support even offers help with code.

2.  The Community -- Let your peers give you a hand.  Online communities, and, for nonprofits using the nonprofit starter pack or other nonprofit specific applications, the Power of Us Hub, offer multiple channels for helpful discussions.
  • Answers -- Search for questions that others may have posted on topics of interest to you or post your own questions.  Lots of folks are looking for a Salesforce challenge and would love to answer your questions.  Note that the questions are organized by categories listed on the left side of the page.  For nonprofit organizations, you have an additional avenue for answers through the Power of Us Hub Q&A, a resource for applications and concerns specific to nonprofits.
  • Chatter Groups -- Sometimes, what you really want is to be kept abreast of what's happening and hear ideas from other Salesforce users and administrators.  Chatter Groups provide just that sort of information.  With groups like the Success -- Getting Started and Success -- Release Readiness, among others, you can keep up with Salesforce features.
  • User Groups -- Among the most helpful Chatter Groups, you will find the Salesforce User Groups online as well.  If you find a group in your geographic area, consider signing up for your local group and trying to attend meetings in person to get to know your peers.  Meetings give you an opportunity to ask other administrators, users and developers how easy or difficult a task may be before you try to hire a consultant.  User Groups can also keep you informed about Salesforce features and best practices and third-party application availability as well.
  • Developer Groups -- Like User Groups for developers, these provide opportunities for discussing technical issues and topics.

3.  Developer Community -- the developer boards offer a great place for help with all your Apex and Visualforce needs.  If you are trying to go beyond formulas and workflow, you may have questions that have been previously discussed on the developer boards.  You can find code samples to get you started with your projects as well.

4.  Office Hours -- both the Salesforce MVP community and the Salesforce Foundation host office hours as a regular webinar that folks can join to ask questions and get answers. Both provide a forum for conversations about problems and challenges you may be encountering.  The MVPs offer general help with Salesforce and the foundation offers help with issues concerning the Nonprofit Starter Pack and any related topics.

5.  Out in the Wild -- The community is also active outside of the Salesforce environment in places like Twitter (try #askforce when you want to make sure your question gets seen) and StackExchange, which tends to focus on technical challenges and developer concerns.  FindSFinfo is another great resource when you are looking for information to solve your problems, it performs a search of official documentation, discussion boards, blogs, code repositories, AppExchange, and videos for any text you enter.

By cultivating a strong community, Salesforce ensures that you can always find the help you need!