I have a love - hate relationship with SalesForce. Some things that they do are fantastic, some drive me nuts. This week, I think that I'm probably generally in love with it.
I feel I've been working on the bleeding edge of what Salesforce wants to do. I've been writing some reasonably complex AJAX, creating some custom pages and moving data around a bit using te API. Here's the key points (that are not commercially sensitive) of what I've been doing.
Dependant Picklists
I've had several cases where I've had to move data from a single picklist to a pair of picklists with a dependancy. While you can use the replace function in the user interface (Setup, Customize, select the object, fields, select the picklist field and choose replace), this will not allow you to move the data to a pair of picklists. To achieve this, I've had to create some VB code that uses the API to copy the data from the main picklist to the dependant one. I've then used the same code to update the master picklist. The beauty of this is that it could all be tested in the Sandbox, and then executed on the live server.
Multi-Picklists to single picklists.
Some data had to be moved from multi-select picklists to single ones. Changing the field type like this deletes all the data. The same tool developed above could be used to re-implement the data once the type change had deleted it.
APEX Custom Pages
The Apex programming language is incredible. It really is the ultimate in cloud computing. Based on the Model / View / Controller architecture, you can create incredible functionality with relative ease. I've been...
- Displaying notifications to users to make sure that they are aware of the procedures for various parts of the sales process.
- Making it harder to create an opportunity (so they find it easier to go down the Lead / Convert route for reporting purposes)
- Automatically creating emails that used to take upto 30 minutes to gather the information for, and sending them directly to business functions when appropriate.
- Creating a charging structure based on the importance of the account, and the number of previous activities.
Time Zone
One of the interesting challenges was to take a free text entry for the country, and convert it into a timezone so that the lead qualification process could have a better idea of when to call. In addition to this, for the USA we wanted to know what the approximate timezone for the state is. We've implemented this using an external web service. In support of this, the website that feeds leads in to SalesForce has been updated so that if the country selected is the USA, then the visitor has to select the state too.
Test coverage
I was really impressed that, before you can deploy an apex class to production, you are forced to test it. It's an incredibly clever system that forces you to write classes that use all of your functionality before it will allow you to deploy the new code.
Data Validation
Prior to deploying the changes and running the data updated, I took a backup of the Salesforce data in to SQL Server. I ran the backup again after the updated, and have been able, using some simple SQL, give a complete report of which fields have been updated, and to what values.
Feedback
Because these changes are the implementation of a new sales model, it's important that we understand how things are going - so we've created a custom object for feedback. It's a really simple idea, but one that ensures that people think that they are being listened to, and gives us a good feel for how well it's being accepted. Each time some feedback is added, I get an email so I get to stay on top of it too.