Check out the getting started section to get a feel for the new guide.

Welcoming any and all feedback! Cheers & happy learning,

John

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

Hereâ€s how to create a validation rule using custom settings:

1. Create a new custom setting, type Hierarchy, visibility Protected (Develop –> Custom Settings).
   
2. Create a new field (I prefer checkboxes) for a validation rule or set of rules.
   
3. Notice that Default Organization Level Values are not set by default.  This must be set in order for the validation rule to work.  Click Manage –> New.
   
   
4. Create your validation rule, referencing the custom setting:
   
5. Now the validation rule is active:
   
6. (Optional) Update your list view in your custom setting to include newly created field(s).
7. Add exceptions in custom setting for users/profiles:
   
8. Your validation rule is now inactive for system administrators.

Note that if you want to use custom settings in conjunction with a workflow rule, you will need to set the rule criteria to formula as shown below.  I canâ€t think of any scenario where this would prevent you from doing something that the standard criteria engine allows, but it can make writing the rules a bit more complex.

Like stated above, be aware – custom settings do not carry over when sandboxes are created (with the exception of full sandboxes).  Make sure to build this in to your sandbox refresh strategy.

Another method is to use the user record.  I havenâ€t  written a step by step for that, but the process is very similar.  You need to create the checkboxes for exceptions on the user record, and then build those fields into your validation and workflow rules.

Have you implemented something similar?  Would love to hear about it!  Cheers,

John

Release schedule for Analytics Edition:

Sandboxes: Released 2/7/12

Production: Scheduled 2/12/12

My full sandbox has the new features as of 2/8/12 so letâ€s have a look!

Test 1

Success criteria: Create a joined report between leads and opportunities, and report on lead status/opportunity stage grouped.

I had an immediate business need to solve. I need to report leads and opportunities at the same time. Most opportunities in this org would be converted from leads, except those created during the data migration. This leaves a substantial gap in reporting that requires exporting two separate reports and an ugly mashup in Excel (or another 3rd party solution).

Steps:

1. Create new report Leads
2. Change format to joined report
3. Add report type opportunities

Problem: Lead Status and Opportunity Stage are not listed as common fields.  Nor are system fields such as Last Modified Date  or Record Owner.

Also, discovered that report blocks limit results to 2000 records and cannot be exported.  This doesnâ€t appear to impact summarized data.

Tried a lead with converted opportunity information joined with an opportunity report.  This worked for converted opportunities but left all unconverted leads as status “-“.

Tried adding Status__c (TEXT of Stage/Status) on lead/opportunity.  Joined report does not show them as common fields.

Adding report types User –> Lead and User –> Opportunity and joining those reports will show user fields as common but not status/stage.

In order for the join to find common fields, the joined reports need to share the same parent object.  That unfortunately isnâ€t very helpful in this case.  Lead/opportunity reporting has been long-standing gap in Salesforce reporting, and I was really hoping that analytics edition would solve it.

Iâ€ve created an idea to allow users to select common fields, please vote: https://sites.secure.force.com/success/ideaView?id=08730000000gPVNAA2

Verdict:  Fail

Test 2

Success criteria:  Create an opportunity report, summarizing several stages into groups (bucket report).

In another org, opportunity stage has gotten a bit out of hand.  Instead of using Status (Stage renamed) and Status Detail (dependent picklist of Status), this org has a long list of statuses.

Steps:

1. Create opportunity report
2. Add new bucket, group status (stage)
3. Select values and group into buckets, run report

Very easy and straightforward to accomplish.

Verdict: Pass

Test 3

Success criteria:  Create a lead reporting showing all leads in status ‘Appointment†that do not have a follow-up call scheduled.

When the activity date field cannot be used these reports are tricky (activity date lists the date of the last completed activity so it cannot be used for reporting uncompleted tasks).  With cross-filters, this is a breeze.

Steps:

1. Create lead report
2. Add filter status “Appointment”
3. Add cross-filter Leads without activities, status not equal to “Completed”

Verdict: Pass

The new features in Analytics Edition extend the reporting capabilities significantly and plug several long-standing gaps in the platform.  It wonâ€t solve all of your reporting woes, but it is an impactful step in the right direction.  I hope that future iterations will give even more power to users with enhanced joined reporting.

Cheers,

John

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

Three common roles I encounter are as follows (but not always labeled as such):

1. Administrator

A good administrator in my mind is someone that keeps the existing Salesforce instance(s) running smoothly.  This includes functions such as:

• Reports and dashboards
• List views
• User administration
• Addition of picklist values
• Modification of page layouts
• Lead & case routing rules
• Email templates

The key here is that an administrator is not responsible for configuration of new functionality and generally speaking does not need to have a strong knowledge of integrations and other downstream impacts.

2. Architect

An architect is someone who performs business and technical analysis, and develops a solution.  They are responsible for delivering new functionality and must have an intricate knowledge of integrations and other downstream impacts.  This would include:

• Custom fields
• Custom objects
• Analytic snapshots
• Record types
• Appexchange packages
• Workflow rules
• Approval processes
• Designation of apex/visualforce (determination of where code must be written, not actually writing the code)
• Data flow and integration mechanics (not an ETL developer, but may configure an integration if it is GUI-based)

An architect has to understand the basics of administration at a minimum.  I often think of solutions architecture as a progression from an administration, but that could be because it was my own. 

3. Developer

In my mind a developer is someone who writes code.  On the Salesforce platform this necessarily includes Apex and Visualforce with custom controllers.  This designation can get confusing for a few reasons:

a) The term “click-to-configure developer” – it really is great marketing, but does confuse titles.  This confusion is exacerbated by certifications: certified developer and certified advanced developer are starkly contrast in expertise required.   A certified developer is someone who understand the basics of code and can write a vf page with a standard controller, while a certified advanced developer can necessarily write apex/vf custom controllers.  A certified developer is more akin to a certified administrator than to a certified advanced developer.

b) Generalist developers.  There are a ton of folks out there that understand code and have written bits of code on the Salesforce platform.  There is huge distinction between someone who has actively learned the Salesforce platform (including administration, apex, vf, limits, bulk apex, best practices, etc.) versus a generalist developer who has learned just enough combined with their prior OOP experience to code a trigger.  For lack of better terms Iâ€ll call the first a Platform Developer and the latter a General Developer.

Cheers @chrisodavies for the conversation last night that sparked this post.

Do you agree with my classifications?  Would you refer to these roles as anything different?

Note: there are other roles (QA, deployment experts, etc.) that I have not included in this conversation but are quite valuable as well.

Cheers,

John

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

Great info as always Jeff!  Cheers,

John

Cheers,

John

Verified

The Salesforce Service Cloud Consultant is a new certification and is available today.  You can register for the certification exam at www.webassessor.com.  As soon as I have a chance Iâ€ll be diving into this one!

Unverified

• The Salesforce Certified Consultant exam will be phased out and no longer be offered.
  • It will be replaced with the Salesforce Service Cloud Consultant (available today; see above) and Salesforce Sales Cloud Consultant exams.
    • Salesforce Certified Administrator will become a prerequisite for both above exams.
  • Those of us with existing Consultant Certifications will be able to test for one of the above certifications for free.

Further Speculation

If the above changes are true, I suspect changes to the developer certifications are in order as well.  Perhaps Certified Custom Cloud Consultant or like?  Personally, I think the Developer certification is horribly misleading, as it has very little do with development in the traditional sense.  The distinction between a developer and advanced developer to the outside world is all but lost in my experience.

Did you attend DF?  Did you hear any of the same?  Please keep me in the loop, feel free to comment below!

Cheers,

John

• 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!).