If one of your company’s contacts jumps to a new company or gets a new job within the same company, isn’t there value in being able to refer to the information?

A sales organization, for example, may want to keep track of friendly (or adversarial) customer stakeholders–especially when these stakeholders move from company to company. It would be useful to know where friendly contacts are moving to so the organization can leverage this information as they develop their sales strategies.

Organizations who capture information about elected officials may also want to know and track when elected officials end up in new posts. It could be advantageous to keep track of a lawmaker’s disposition toward your company throughout his/her career.

Interestingly, Salesforce does not offer the functionality to track contacts over time.  Yes, there is a way to track fields, but only for 18 months, which isn’t a sufficient length of time for the above requirement.  I’ve built a fairly simple solution to this problem that doesn’t involve any code.

Road map

This configuration has seen several iterations in my Salesforce environment, but I think we have arrived at a fairly simple and straightforward method to track contacts and their movements. The steps to setting up this configuration include.

• Create a new object called Contact Position.
• Develop validation rules to insure that only one contact position is active at any one time.

• Write a (cross-object) workflow so the Contact object will display the current position information.

The Contact Position Object

The most important step is to create an object called “Contact Position” which will be on the detail side of a Master-Detail relationship with the Contact object. The Contact Position object should hold whatever fields are useful in understanding each contact’s position. (e.g. name of position, description of position, and account/company).

Although the contact will always be connected to an account, you’ll be able to track the movement of that contact if you also have the account stored in the Contact Position. You’ll also want to include a boolean field called “Active” and/or effective dates.

To make this object shine, you can include some nifty validations to ensure that:

• the end date does not occur before the begin date. The error condition for this would simply be: begin data > end date.
• the “Active” checkbox does is not unchecked until an end date is entered. (i.e. An inactive position must have an end date.)

Validating that only one contact position is active at any one time

The requirements for this project state that only one contact position for any contact may be active at a time. To guard against multiple active contact positions, we would have to know if there are any other contact positions active. Although Salesforce is unable to make this computation from the contact position object, we can determine the number of Active positions from the Contact object. Here’s how to do it:

• Create a Roll Up Summary field on the Contact Object that counts the number contact positions for a given contact.

• Create the validation rule in the Contact Position to guard against there ever being more than one Active position. Here’s what I came up with (note the reference to the Roll Up summary field called Active_Positions__c).

And(OR( PRIORVALUE( Active__c )=FALSE, ISNEW()), Contact__r.Active_Positions__c>0, Active__c =TRUE)

Pushing the current Contact Position information to the Contact Object

Now that we have the Contact Position information connected to the Contact, and we make sure that these positions follow some basic rules, we can push the current Contact Position information to the Contact.

• Create a workflow rule that will run everytime a record is created or edited. The rule criteria is simple: if the Contact Position is Active, it should trigger an action. (e.g. Active__c=True)
• Than setup a field update action which updates the Contact object. By updating the Contact object from an action in the Contact Position, we have just setup “Cross Object Workflow” (new in Spring ’12 release). See below:

• Before clicking Save, setup the formula to update the field in the Contact Object.

That’s all there is to it. Now users will be able to keep track of their contacts when they move to other companies or positions! I had a fun time putting this together, and it allowed me to eliminate some code that was previously deployed to do the same thing. Please drop me a line if you have any suggestions or have questions.

At work, I manage a team that provides technology solutions to several small but important departments within my organization. In the not-so-distant past, others in my role resorted to using tools like MS Access (hardly scalable), Spreadsheets (not easily shareable), and innovative uses of file shares and email templates to get the job done.

Along came Salesforce.com, and we have been able to create solutions that can withstand the demands of many users and data, promote collaboration, and maintain data integrity in ways that departmental solutions have been unable to accomplish in the past. Below are a list of reasons why our business unit’s implementation of Salesforce (aka Force.com)  behaves like an enterprise application. (In the future, I’ll publish a list of Salesforce criticisms, but today I’m a fanboy).

1. Salesforce was an easy sell. With a greater percentage of the costs known up front, Salesforce takes some of the guesswork out of costing a solution. No hardware to purchase, no network engineers to engage, and no obtuse licensing makes Salesforce seem less of a fiscal gamble. In my case, I do all the development work, so we don’t even have to worry about a pricey consultant engagement.
2. Salesforce helps the business to easily share information between and among departments. I have found that sharing information has become one of the biggest selling points of implementing Salesforce. After we implemented our first application in Salesforce, we found that other departments within the business unit wanted to use that data to help satisfy their own business needs. Instead of generating spreadsheets to share with other departments, we immediately began bringing on other areas so they can share data at the source.
3. Salesforce provides the tools to quickly prototype, rollout, and change applications. Most business requirements can be met simply through a point and click interface. Although nothing replaces thorough analysis when developing an application, the basic concepts behind Salesforce administration is intuitive and its developer interface is streamlined. This shortens the cycle time for development and allows the business to see their changes implemented quickly.
4. Salesforce takes IT out of the equation. Departmental solutions always lose when they have to compete with enterprise applications. IT just doesn’t have the resources to take on all applications and solutions for all departments. Thus, the needs of smaller business units can not always be addressed in reasonable timeframes. Salesforce allows departments and business units that don’t have the attention of IT to effectively roll out solutions without IT resources.
5. Salesforce provides quick reports and dashboards to measure and communicate our accomplishments. A couple weeks ago, a business user asked me to generate a Salesforce report for the preceding fiscal year. It was in her inbox in about 5 minutes. The last year’s report took two days to gather the data and a day to crunch the numbers. Also, I’ve created dashboards that are visible at login that immediately remind users that their data actually means something in aggregate. With these types of reminders, managers and executives can’t argue with the benefit of Salesforce.
6. Salesforce makes it easy to engage users in the development process. After meeting with users in the morning, I can go into a developer sandbox, make a change, and show them the change by lunchtime. With that kind of speed, users stay engaged and feel comfortable asking for changes. The first thing I tell new user groups (after I tell them that Salesforce is NOT a sales application) is that the application is THEIR application and that we can work together to create an application that fits their needs.
7. Salesforce has a primetime feature set. Workflow, custom webpages, approvals, triggers, granular permissions, forms, reporting, dashboarding, and email parsing are all functionalities that we use in our departmental solutions–and we are just scratching the surface. These features have allowed my little department to develop applications that are producing real value to my business unit and the organization as a whole.

The above items (along with a lot of hard work) have helped to make Salesforce a valuable tool for my business unit. It’s not a perfect implementation (maybe I’ll write about that in the future), but we’ve been able to leverage the strengths of Salesforce to create departmental applications that provide enterprise-grade functionality and productivity.