Comments Off on Exceptions to Validation and Workflow Rules [Best Practices]

Exceptions to Validation and Workflow Rules [Best Practices]

Posted February 25th, 2012 in Tips & Tricks by John Coppedge

I find it very helpful to provide a method to turn off/on validation and workflow rules on a per user or per profile basis.  Advantages:

  • Data migrations and manipulation.  I was loading contact data split into two files (1st for name, 2nd for contact details), while a validation rule prevents creating a contact without a phone or email address.
  • Integration.  Often times integration should not be subjected to the same rules as a typical user.  You could hard code the integration user details into each validation rule, but that isn’t very extensible.
  • Flexibility.  You’ve got it.


There are two basic ways to accomplish this:

1. Add exception fields to a custom setting.  There are some complexities with this method but it is my favorite (make sure to set org wide defaults!).

2. Add exception fields to the user record.

Here’s a brief overview of the pros/cons of each:

Custom Settings User Record
Per profile & per user. Per user only.
Must be manually migrated to new sandboxes (except for full sandboxes). Carries over on user record when sandbox created.
Workflow rule conditions must be written as “when formula evaluates to true”. Workflow rule conditions can be constructed as normal.

Continue Reading »

Comments Off on Saving Multiple Phone Numbers & Email Addresses [Contact Details]

Saving Multiple Phone Numbers & Email Addresses [Contact Details]

Posted January 2nd, 2012 in Tips & Tricks by John Coppedge

The goal of this approach was to have an intuitive way to enter multiple phone numbers and email addresses per contact or lead record:


The logic is driven by 4 workflow rules:

  1. When ‘Do Not Call’ = TRUE, update Phone to NULL.
  2. When ‘Email Opt Out’ = TRUE, update Email to NULL.
  3. When ‘Do Not Call’ = FALSE, update Phone:
    IF(TEXT(Preferred_Phone__c) == "Home Phone"
    && Home_Phone__c != ” && Home_Phone__c != NULL, Home_Phone__c,
    IF(TEXT(Preferred_Phone__c) == "Mobile Phone"
    && MobilePhone != ” && MobilePhone != NULL, MobilePhone,
    IF(TEXT(Preferred_Phone__c) == "Work Phone"
    && Work_Phone__c != ” && Work_Phone__c != NULL, Work_Phone__c,
    IF(TEXT(Preferred_Phone__c) == "Marketing Phone"
    && Marketing_Phone__c != ” && Marketing_Phone__c != NULL, Marketing_Phone__c,
    IF(TEXT(Preferred_Phone__c) == "Other Phone"
    && Other_Phone__c != ” && Other_Phone__c != NULL, Other_Phone__c,
    IF(TEXT(Preferred_Phone__c) == "Other Phone 2"
    && Other_Phone_2__c != ” && Other_Phone_2__c != NULL, Other_Phone_2__c,
    IF( Home_Phone__c != ” && Home_Phone__c != NULL, Home_Phone__c,
    IF( MobilePhone != ” && MobilePhone != NULL, MobilePhone,
    IF( Work_Phone__c != ” && Work_Phone__c != NULL, Work_Phone__c,
    IF( Marketing_Phone__c != ” && Marketing_Phone__c != NULL, Marketing_Phone__c,
    IF( Other_Phone__c != ” && Other_Phone__c != NULL, Other_Phone__c,
    IF( Other_Phone_2__c != ” && Other_Phone_2__c != NULL, Other_Phone_2__c,
  4. When ‘Email Opt Out’ = FALSE, update Email to:
    IF(TEXT(Preferred_Email__c) == "Personal Email" && NOT(ISBLANK(Personal_Email__c)), Personal_Email__c,
    IF(TEXT(Preferred_Email__c) == "Work Email" && NOT(ISBLANK(Work_Email__c)), Work_Email__c,
    IF(TEXT(Preferred_Email__c) == "Marketing Email" && NOT(ISBLANK(Marketing_Email__c)), Marketing_Email__c,
    IF(TEXT(Preferred_Email__c) == "Other Email" && NOT(ISBLANK(Other_Email__c)), Other_Email__c,
    IF(TEXT(Preferred_Email__c) == "Other Email 2" && NOT(ISBLANK(Other_Email_2__c)), Other_Email_2__c,

    IF(NOT(ISBLANK( Personal_Email__c )), Personal_Email__c ,
    IF(NOT(ISBLANK( Work_Email__c )), Work_Email__c,
    IF(NOT(ISBLANK( Marketing_Email__c )), Marketing_Email__c,
    IF(NOT(ISBLANK( Other_Email__c )), Other_Email__c,
    IF(NOT(ISBLANK( Other_Email_2__c )), Other_Email_2__c,



You could probably combine these into 2 workflow rules per object as well.  This was driven with inspiration from the Non Profit starter kit, which uses a similar contact management strategy (although allows update of standard phone/email fields).


How do you handle multiple phone/email addresses in your org?  Have you found a better way?  I want to hear about it!





Comments Off on Salesforce Release/Change Management and Org Documentation [Tools]

Salesforce Release/Change Management and Org Documentation [Tools]

Posted February 10th, 2011 in Tips & Tricks by John Coppedge

After a very lengthy discussion on Linked In, I’ve gathered a few points managing change and documenting your Salesforce org:


1. Configuration Workbook for Org Documentation

Download Sample: Download Configuration Workbook

Typically a resource for consultants, but can easily be repurposed for ongoing documentation of your Salesforce org.  The challenge is that the document must be updated with each configuration change in a single centralized location (read: Content, Google Docs, Sharepoint).

2. Exact Metadata for Org Field Documentation

This is one of my favorite methods, as you can extract all objects/fields very easily.  Since the tools pull live data, there is no questioning if the documentation is up to date.  These tools are free, but will only describe field and object info; you’ll need to look elsewhere for documenting workflow, triggers, etc.

Also, I searched long and hard for a tool that will extract the description for each field from the metadata, and couldn’t find one.  My understanding is that the metadata API cannot access the description, yet I can see it through the IDE… which uses the metadata API…?  If you can shed some light on this one please leave a comment!

A. Cloud Converter:

Click a button and extract all metadata from your org into a single excel workbook.  Brilliant.

B. Object Metadata Snapshot Tool:

This one is neat, because actually creates records for each field/object.  This means that you can then take an analytic snapshot to create a ‘Point in Time’ view of your Salesforce metadata on a regular interval without any intervention.  Who wouldn’t want a self-documenting org?

C. Etherios EasyDescribe:

3. Snapshot for Org Documentation and Change Management

More info:

Snapshot is a paid (and not inexpensive) tool for org management.  It take a snapshot of an org configuration, roll-back to a snapshot, transfer configuration changes org to org, and perform a variety of sophisticated functions.  I haven’t personally used the tool but have seen a demo, and it appears to be much more feature-rich than the above metadata tools or change sets.

4. Change Management App: ChangeIt!


A free, fairly simple app for managing change requests.  By default is a stand-alone package (not linked to other Salesforce objects).

5. Product Management App


A free, fairly simple app for product release management.  Has been tailored by default to connect to cases and opportunities.

6. IDE

You can use the IDE to extract virtually all information about your Salesforce org.  Note that the IDE is a developer tool and will return information in a programtic fashion (XML), not easily accessible spreadsheets like the above metadata tools.  It can be combined with Subversion for version control.

7. View Setup Audit Trail

From within Salesforce: Administration Setup –> Security Controls –> View Setup Audit Trail

When all else fails, read the log Smile


This is by no means a comprehensive list.  Please leave a comment below if you have a favorite tool not mentioned above!




Comments Off on Customer Portal & Self-Registration [How-to]

Customer Portal & Self-Registration [How-to]

Posted December 14th, 2010 in Certified Advanced Administrator, Certified Consultant, Tips & Tricks by John Coppedge

Configuring customer portal can be somewhat confusing the first time around.  Here are a few basic guidelines to get you going in the right direction:

  • For each object that you expose in a portal, the sharing model must be private (unless you want to expose all records of that object to your portal).
  • Use sharing rules to recreate the sharing model for All Internal Users.
    Example rule creation for accounts:
  • In order to expose an object and/or tab to the customer portal the following must be true:
    • The tab in question must be supported by the customer portal.  From the article “Why can’t I see my tab in the Customer Portal?”:

        Even though all objects are displayed in the Customer Portal setup, only the following can display as tabs in your Customer Portal:
        Web tabs
        Custom objects

    • When exposing a custom object, make sure to check ‘Available for Customer Portal’ on the object properties:
    • Ensure that the customer portal profile(s) have access to the object:
      • Object Tab Setting: Default On

      • Standard Object Permissions: Object Read (minimum)

      • Field-level security on the object

    • Make sure profile(s) are assigned the correct page layout

    • Create the customer portal:

      • Ensure ‘Login Enabled’ is checked

      • Click Customize Portal Tabs (top) and choose tabs to expose (all of the above must be configured before tabs are exposed)

      • Click Edit Profiles button (bottom) and assign profile(s) access to login to the portal

    • Add/verify portal management buttons on the account and contact page layouts


Self-registration will allow existing contacts within your Salesforce org to sign up for portal access.    To enable:

  • Enable self-registration on the portal itself
  • Give contacts ability to self-register
    • The field ‘Allow Customer Portal Self-Registration’ determines if a contact can self-register.  By default, this field is not checked.  First, enable visibility:
      • Grant the Visible permission to ‘Allow Customer Portal Self-Registration’ for portal administration profiles
      • Add the ‘Allow Customer Portal Self-Registration’ field to the appropriate contact page layouts
    • Update all contacts to grant self-registration capability (this can now be accomplished through data loader as well)
  • Contacts should now be able to self-register through the portal login page
    • Note:  The email address provided on the self-registration page must match the email address on the contact record exactly (it IS case sensitive!).
Comments Off on Don’t like identity confirmation? Here’s one way to disable it. [Not a Best Practice]

Don’t like identity confirmation? Here’s one way to disable it. [Not a Best Practice]

Posted November 28th, 2010 in Tips & Tricks by John Coppedge

Just for the record, I am not recommending this as a solution.  This decreases the security of your Salesforce org, and is generally against best practices.  If you don’t fully understand the implications I would definitely not recommend this solution.  That said, I saw a client that did exactly this and thought I would share:


Turn off identity confirmation entirely: trust all IP addresses.  This way the connecting IP address is always trusted, and therefore identity confirmation is always bypassed.  Likewise, you will never need a security token for any connection.


This also means that if someone gets a Salesforce username/password combo from any user with API access, they can login and extract your entire database without a security token or email address verification from anywhere in the world.  Use with caution!