Tag: Salesforce

All The Things You Should Do Before Adding A Validation Rule

Why Validation Rules Are a Bad User Experience

Validation Rules are the hammer of your mission to maintain data integrity in Salesforce- You can do a lot with them, but they’re not often the best tool for the job, and they’re certainly not the most user-friendly.

The ability to write code to determine if a value is acceptable is extremely powerful, but because the rule can only be executed on-save in Salesforce, it creates this awkward interaction between users and the system:

  1. User enters data which isn’t valid
  2. User tries to save the record
  3. Validation Rule runs and displays an error
  4. User finds the invalid field and corrects it
  5. User saves the record again

That’s not bad, except the user could have multiple errors they need to correct; errors could be displayed at the top of the page instead of on the field, meaning the user has to find the field that is incorrect, and there could be multiple levels of validation rules that get hit as the user updates data and corrects the record, causing them to continue to have to re-save the record repeatedly.

Use Proper Data Types

This one is pretty obvious, but I’ve seen before where people will ask for the ability to have a currency field, but they also want it to be able to display N/A in the field when it’s not relevant or before a user has entered a value… If this is an absolute necessity, consider whether it makes sense to keep a flag on the object to indicate if the value had been changed by a user so you can keep the data clean.

You should also consider when a picklist is a better solution than a text field. Lots of times we need reasons for why decisions were made, like why an Opportunity was closed, why a Lead was closed, why a Case closed, etc. While these reasons can be complicated, being able to categorize them into more general categories, like “Customer Lost Interest”, “Customer purchased product”, “Insufficient Funding”, etc. allow you to not only produce better reports, but they also allow you to use other features like Field Dependencies to prevent awkward situations like a “Closed Won” Opportunity with a loss reason.

Using the right Decimal configuration on currency and number fields also helps prevent situations like nonsensical values, by putting an upper bound on the numbers that can be entered. You certainly wouldn’t want a user moving too quick and marking a 2020 Honda Accord as being a $2000000.00 vehicle because they missed a decimal point!

Validation Rule on Text Field to Accept Blanks and $ values

All of these problems could be resolved via a validation rule, but if you address them by using the right field configuration, it teaches the user how to populate them before they commit to an answer. This means fewer clicks and a more intuitive system.

Currency Field Type w/ Automatic Format Correction

Field Level Security/Page Layouts

Another common use-case for Validation rules is to ensure that only certain users are able to update values in certain fields. This is typically done in-lieu of maintaining multiple page layouts. While the cause for reducing future work is noble, it creates the impression for the user that they have access to update fields they may not have access to change. This can make user access issues difficult to figure out if your validation rule messages are incomplete.

For new users, this also becomes a big problem, as a user may need to update a number of field, and overwrite a value that was set by an authorized user, only to find out that they don’t actually have access. The problem can then become bigger if that field affects other fields that they have to change, as they may need to revert those as well!

Validation Rules to Control Security Interrupt User Flow

This issue tends to compound itself, because if you have a number of these rules, then you can either have a validation rule for each field, which means a LOT of rules to maintain, or you can have one big rule and be forced to place your validation error messages on the top of the page, or on a field which is only relevant to one field validation.

Another possibility is that you need different levels of access to a record depending on the user. Setting different page layouts for these different user roles allows you to go ahead and secure those fields that shouldn’t be modified for users who shouldn’t be able to modify them.

Field Dependencies

Field Dependencies are an easy way to ensure data integrity for picklist values, as they can prevent users from entering values that don’t make sense for a given object state. To use the Closed Reason example from before, you can prevent a user from entering a Closed Reason value of “Customer Lost Interest” when the Opportunity is Closed Won. You can also use this for things like Substages or Statuses to give more granularity to your Sales Lifecycle without making it impossible to read on the Opportunity page.

Another cool thing you can do, is a neat interaction between field dependencies and required fields. When a Picklist is marked as Required, a value has to be selected, right? What if there are no values available for this field?

What happens is that since no values are available, Salesforce makes the field no longer required… until there’s a value available to be entered. You can use this on something like an Opportunity Closed Reason to make it so the Closed Reason is required once an Opportunity is marked as Closed, only present the values that are relevant for Closed Lost/Closed Won, AND not have to make an explicit exception for any particular stage.

To show this off, here’s how we can require a Completed “Delivery/Installation Status” in order to close an Opportunity:

Validation Rule – Require Completed Delivery/Installation Status before Opportunity Close

The gif above shows what this behavior looks like when we use a validation rule. The user could save a little time by updating the stage in the record edit screen, but the validation rule still takes the user out of their groove.

Field Dependency – Require Completed Delivery/Installation Status before Opportunity Close

Here, we show that the Delivery Status field just becomes an additional field to enter if it’s not populated. If the user has already entered that value, they only need to confirm the value.

Record Types

This one kind of fits in with page layouts. For some reason there seems to be some opposition to creating record types. Not only does this give you a nice field to use for your field dependencies, but it also gives you a nice breakdown for things like page layouts.

Having multiple record types and likewise, page layouts helps you hide irrelevant fields from users for a given record type, resulting in less bad data, but it also allows you to conditionally automate data in places where it makes sense, and lock fields that users shouldn’t need to modify directly

Automation

Automation is an special because it helps prevent errors, not by validating data, but by using business rules to prevent users from having to enter the data at all. Strong business rules and automation allow you to take the users’ hands off the keyboards and utilize strict data types like numbers, picklists, and checkboxes to drive other field values, which may be subject to unnecessary user interpretation.

Using Validation Rules to Enforce Record Flags

It’s kind of unnecessary to leave this change up to a user, when we could just automate it.

Using Automation to… Well… Automate Data Entry

Help Text

The last tool at your disposal is the Help Text. Help Text serves as your inline documentation. It helps a new user understand what they’re supposed to do with a field before they’ve entered their data. It also allows you to put helpful hits right in front of the user, so they don’t need to review documentation in an external system in order to understand how to commit the record.

Making Users Track Down Their Own Answers

Help Text doesn’t really stop the user from making mistakes, but it gives the user more information to help prevent issues, and to teach them what is expected.

Teaching Users Inline w/ Help Text

The Basics of Using Salesforce Data Loader

Overview

This document walks through the steps of performing updates and exports using the Salesforce Data Loader tool.  While dataloader.io can also be used for this purpose, that tool is subject to additional licensing and has limits to the number of records that can be exported or updated per run or in a given month.  The Salesforce Data Loader tool isn’t subject to these restrictions, and it runs on your local device and connects directly to Salesforce.  It also can utilize the bulk APIs to insert, update, export, upsert, etc.  very large quantities of records at a time.  Salesforce recommends the tool for batches of up to 5 million records at a time.

Data Loader Setup

  1. Follow the instructions in the link below to install Zulu Java OpenJDK/JRE and the Salesforce Data Loader program
    https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/loader_install_general.htm
  2. Run the Salesforce Data Loader program.

Performing an Export

  1. Click Export
  1. You’ll be prompted to log in.  Select either Sandbox or Production, depending on what system you intend to log into.
  2. Enter your credentials to log in.
    • Note that in some orgs you may need to click Login with Custom Domain in order to get OAuth to work!
  3. You’ll be redirected to a page to choose the object you want export.  If you don’t see it in the list, check the box next to “Show All Salesforce Objects”, then select the object you want to export.
  1. At the bottom, click Browse… and choose a file name and location for the exported file.  Click Save
  1. You’ll see that the file name at the bottom has updated with the new file and path.  Click Next >
  2. On the next page, you will define the export.  You can either enter a SOQL query that you’ve tested in the dev console, or you can choose fields to display on the left, and then enter filtering conditions on the right (you may need to expand the window to see all fields).  When done, click Finish.
  1. You’ll be prompted to confirm that you want to export the records.  Click Yes.
  1. You’ll receive a progress indicator as it exports the data.
  1. When complete, you’ll be asked if you want to view the data.  You can just click OK or Close.
  2. You can now open the file to review in Excel or Numbers, or upload and open the file in Google Sheets.

Performing an Update

  1. From the Welcome Page, click the Update button.
  1. You may be prompted to log in. If so, see steps 2-6 in the export section.  For step 7, you’ll be redirected back to the page shown here in step 3
  2. Choose a Salesforce Object.  Note that you may need to click the box next to “Show all Salesforce objects”
  1. Click Browse…
  2. Choose the files that contains the records you want to update.  You’ll need at least an id field to identify the records and a column for the field you want to update.  Click Open
  1. The program will process the file to see how many records it is able to process, as well as scanning for issues like the wrong product selected and let you know how many records can be read properly.  If the number of records looks correct, click OK.
  1. You’ll be presented with a screen that looks like this.  If the File Column Headers do not look familiar, click < Back and upload the correct file.  If not, then click Create or Edit a Map.
  1. From here, you’ll be selecting which field in Salesforce corresponds with the column header in your csv file.  You can try Auto-Match Fields to Columns.  It works reasonably well.  Review its selections in the bottom-half of the window.  If any are incorrect or blank, you may have to update the map by dragging components from the top section.
  1. When happy with the mapping, you can click Save Mapping if this is a manual import you expect to perform frequently, or just click OK.
  2. The field mapping should be update now on the Mapping page.  If correct, click Next >.
  1. On this final page, you’ll be asked where you put the log files.  Click Browse… then create and/or select a directory where you want log files to be added.  There will be a success log and an error log for each run, indicating whether the run was successful for that record or not, and why.  After selecting a folder, click Finish.
  1. The program will increment through with whatever batch size you have configured, and provide an update every second or so of its progress on the update.  When complete, it will prompt you to review the log files.  You can do that for the errors, or just click OK.  You’re done!