Good overview & petition: http://www.fightforthefuture.org/pipa

Companies taking action: http://mashable.com/2012/01/17/sopa-companies-dark-list/

Google petition: https://www.google.com/landing/takeaction/

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

Over the last year or so I’ve become quite disconnected from the Salesforce community.  For a variety of reasons (primarily time), I haven’t been posting and sharing with much frequency.  I miss the interaction with the community, and decided it is time to reengage.

What are your resolutions this year?

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

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