Plenty has been said. Please spread the word, and sign a petition if you haven’t already.
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 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’m not normally the type to make a New Year’s resolution. After all, I figure if something is important enough to change in your life why wait until next year? Just get started now. Well it just so happens that I want to make a change and it’s the first of the year. That makes it a resolution, right?
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
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
After a very lengthy discussion on Linked In, I’ve gathered a few points managing change and documenting your Salesforce org:
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).
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
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.
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).
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.
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/
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