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.