Keeping on top of job changes

Last Updated on Thursday, 31 July 2008 12:43 Written by Steve Thursday, 31 July 2008 12:43

Keeping data in a CRM up to date is really hard work. One of the things that happens all the time is that people change jobs. Whenever we hear of a job change, we go to Salesforce.com and record it.

Recording a job change is a two-step process:

1. Edit the Contact record to show the new place of employment and other details that have changed.
2. Record the fact that this person used to work at their original place of employment–that’s good history you don’t want to lose.

To speed things up, and make sure we don’t lose that history, we created some VisualForce to make recording Job Changes a snap. Watch the video:

We use it every day and we love it. It’s a task-based UI that really nails what it’s trying to do. VisualForce seems amazingly suited for these kinds of streamlining tools–they are relatively easy to create and maintain.

Dave Manelski took this on as his first VisualForce project and he did a great job! After he was done I decided that I wanted to put the email, phone and address fields so the user could change that data in the middle of the task. Because of the architecture of VisualForce, it was a snap. It took about 2 minutes to add those fields, have them editable and have the data land in the right place.

Troubling

Last Updated on Thursday, 31 July 2008 08:06 Written by Steve Thursday, 31 July 2008 08:06

Just heard from Al queda expert Lawrence Wright that in 2001 the FBI had 7 agents who spoke Arabic.

Today it has 8.

This in light of the conservative RAND Corporation’s report that most terrorist groups have ended by either entering the political process or through law enforcement actions.

Good luck with that law enforcement while not speaking the language.

Rolling up the sleeves with VisualForce

Last Updated on Thursday, 31 July 2008 07:58 Written by Steve Thursday, 31 July 2008 07:58

I wrote the other day that VisualForce was the real deal. I wanted to follow that post up with some more thoughts now that we’re actively developing with it.

First, let me say that we are trying not to write any S-Controls anymore. One reason is that S-Controls have a shelf life baked into them. At the top of my S-Controls I include Saleforce’s AJAX toolkit, which is what makes them so powerful. But, a bunch of my code was still using an old toolkit (circa way back in 2006) that is no longer getting updated. That’s fine with me–all my new development was always with the new toolkits. But, when Firefox 3 came out, all my code with this very old toolkit broke because of something with Firefox. I have no idea why, but it did.

With VisualForce, there are no includes of files that will go obsolete. So it is the most future-proof way to build UI in Salesforce short of hosting everything yourself.

Second, after spending years building S-Controls, VF is a dream to work with on so many levels. In that earlier article I talked about the big architectural reason why it’s better. Some practical realities have hit home since I’ve been writing actual production code.

1. Testing is the gift that keeps on giving – UI that I write with VF has all it’s logic in Apex classes. I can write tests for these classes. Testing is massively helpful in creating, understanding, and maintaining code. I can’t overstate it’s value.
2. Deployment is getting much easier – moving code around has massively improved with the new metadata api. Just yesterday I dragged-and-dropped VF with Apex classes from a sandbox into production. It just plain worked. I was shocked, but it shows how much implicit respect I have for the Sf.com development team that I even tried it. I find myself constantly trying things that I know probably won’t work, and very often things just work! Kind of like using an iphone in that way.
3. Fewer languages is better – All my logic is now in Apex. So I don’t have to remember how to write logic in S-Controls. Thank god. In some cases we had moved some of the logic from S-Controls to Apex webservices. Migrating this code to VF and Apex turned out to be really easy. And ditching the webservices simplifies and speeds up everything, of course.

So every new idea we have is going right to the VF drawing board. However, there still are some things to improve:

1. Invoking code – you can’t hook VF into buttons as easily as S-Controls, so we’ll be putting URL calls in there until we can directly reference the pages. Nice thing is that we reference by the page name and not the ID.
2. List buttons – there isn’t any way to have a list button written in VF process many checked records from a list. So we’ll have to keep writing JavaScript for these functions.
3. Detail of a record in edit mode – See my idea from yesterday for this killer platform feature. I think this is a massive one for the user experience and would really compliment Apex triggers with UI based “next actions.”
4. Packaging – I’m sure this will come in the next release.

As we get more proficient with VF (and testing VF) I’ll write more. But to date, I have to say I’m very pleased with the framework. This is a learning curve well worth climbing.