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:

Continue Reading »

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!

Cheers,

John

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: http://appexchange.salesforce.com/listingDetail?listingId=a0N300000016cVIEAY

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

B. Object Metadata Snapshot Tool: http://appexchange.salesforce.com/listingDetail?listingId=a0N30000003Ih3aEAC

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: http://appexchange.salesforce.com/listingDetail?listingId=a0N300000018leZEAQ

3. Snapshot for Org Documentation and Change Management

More info: http://www.dreamfactory.com/solutions/snapshot/

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!

Download: http://appexchange.salesforce.com/listingDetail?listingId=a0N300000016ct3EAA

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

Download: http://appexchange.salesforce.com/listingDetail?listingId=a0N300000016c6UEAQ

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

6. Force.com 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.

http://wiki.developerforce.com/index.php/Using_Force.com_with_Subversion_for_Team_Development

http://www.romascanu.net/Blog/salesforce/version-control-and-force-projects/

7. View Setup Audit Trail

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

When all else fails, read the log

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

Cheers,

John

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:
    Home
    Cases
    Solutions
    Web tabs
    Documents
    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!).

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!

Cheers,

John