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
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:
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. |
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 attention. Salesforce 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!
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).
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:
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
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:
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:
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