Comments Off on Announcing a New Resource for Salesforce Certification

Announcing a New Resource for Salesforce Certification

Posted April 3rd, 2013 in Site Updates by John Coppedge

ForceCertified has been quiet for some time, and that’s because I’ve been working a new and improved resource for learning and preparing for Salesforce certification: CertifiedOnDemand.com.

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

Welcoming any and all feedback! Cheers & happy learning,

John

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 Salesforce.com Analytics Edition [Pros and Cons]

Salesforce.com Analytics Edition [Pros and Cons]

Posted February 8th, 2012 in New Releases by John Coppedge

Analytics Edition has been a bit of a ride.  Initially it was to be a paid add-on, pricing was rumored to be $50/per/month with the requirement all users in the org must be licensed.  Customer reaction (myself included) to this pricing was negative enough that it garnered press attentionSalesforce responded by offering Analytics Edition for free.  Well done Salesforce for listening to and responding to your customer base.

 

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

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!

 

Cheers,

 

John

Comments Off on Defining Salesforce.com roles and responsibility [Recruiting & Employment]

Defining Salesforce.com roles and responsibility [Recruiting & Employment]

Posted August 6th, 2011 in Uncategorized by John Coppedge

I regularly talk with all sorts about employment opportunities on the Salesforce platform.  It is clear to me now that it can be very challenging to define exactly what you’re looking for as a prospective employer.

 

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.  Smile

 

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?

 

 

image

 

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