gokubi.com

Earlier I faked a drip email campaign, but here’s the real deal. Matthew came up with this idea and I think it’s brilliant.

Basically, you mark that a Contact should start a drip email series, and from then on they will receive your templated emails automatically, at the time intervals you configure.

The sending of these emails requires no User intervention, and no code is necessary to make this work–it’s unattended drip emailing from plain vanilla Salesforce.com.

I love working on a team, because someone often comes along with a different approach to a problem that I was blind to. This is so much better than what I was coming up with. We still have a limit of 200 emails a day, but because these are going out daily rather than in large batches, we have more ability to level our sends, staying under 2000.

I’m not sure why workflow sends to Contacts was a blind spot for me. I guess I have been thinking about email as large-batch sends, rather than thinking about them as one-offs. Or maybe I still haven’t recovered from summer vacation…

Thanks again to Matthew for this great idea. If anyone can think of limitations we’re not considering, or ways of doing this better, please post a comment!

We’ve done about 20 Salesforce implementations, and have 5 more going right now. We’ve developed a base template–a set of objects, fields, reports, dashboards, workflow, scontrols, visualforce, and apex that we start with for each client. We then customize that to their needs.

When I first started this work, it would take about a week to get a base install set up. All the objects had to be created in the web interface. Fields and values had to be done by hand. Code had to be copied by hand. It was a drag.

Then came the Appexchange, and we got to package up some things and install them with a few clicks. Then the Appexchange got better, allowing for more things to be packaged.

The last time I did a base install of our template, it took about 8 hours.

Much of this time was getting the page layouts to look right. If you’ve ever worked on a page layout, you know how complex they are. First you have to get all the fields in the right place by dragging and dropping them. But you then have to click into each field if you want to make it read only. You have to pick the buttons you want to show up on the page. You have to pick the related lists, and then each related list has a list of fields in a specific order, as well as sort order.

Page layouts were a significant piece of work, and I’d often find out in training with the client that one related list didn’t have the right fields, or wasn’t sorted the correct way.

The Metadata API and the Force.com IDE have changed how we deal with page layouts. We can now set them up in our template instance and copy and paste them into our customer org.

I have a new customer and I set them up with our base template yesterday. It took me 2 hours.

For each customer I deal with, the Metadata API will save me 6 hours of point and clicking in page layouts. I can’t tell you how happy that makes me–hand-tweaking page layouts isn’t the greatest value-add to the environmental cause.

You can also copy and paste Profiles, so we now have some template profiles set up, and the next install will go even faster.

If you’re a consultant, you need to use the Force.com IDE and the Metadata API. It’s a massive time-saver and will only get better as more things are added–roles, sharing rules, record types, buttons and links–who knows what’s next?

Dreamforce is on election day. I hear tell San Francisco is Obama country. Anyone know of a good place to party after the results come in?

We don’t have an email blasting tool that effectively supports drip campaigns, so we’re faking it a bit. A picklist represents all the steps in a drip campaign. After we send all the communications for this month, we shift everyone to the next step. To make this easier, I built a VisualForce page that updates all Contacts to the next value in a specified picklist.

You could do this kind of thing with workflow field updates (there is an option for moving fields to the next option in the picklist) but there isn’t a great way to query the objects. A List Button won’t work because you have to page through and select all your Contacts before clicking the button. So, this is what I came up with.

Scott Hemmeter has a cool new feature for his Salesforce.com mapping product Arrowpointe Maps: proximity searches. Find nearby Accounts and Contacts on a map. Very cool Scott!

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.

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.

I would like to create a VisualForce page to override the Edit page for my objects. I can do this now, but I have to build the form by hand. Please enable the “Detail” component, which renders the correct page layout for the object/profile combo, to be put into edit mode.

This would be incredible, because I could then put a conditions-based redirect after the save action to send my User to the next action. This could be:

* a page for next steps on a recently won Opportunity
* a page outlining research steps for a newly created Account

This is a very powerful platform feature I’d love to see!

I just got a note from John Rotenstein announcing his blogging efforts around his Salesforce.com work. Always nice to hear a new voice, especially someone who has applied his Salesforce.com love all the way through to his blog skin.

John also brings up the valid point that Summer ‘08 is really Winter ‘08 for Australians. To address this, I think the next release of Salesforce should be called “Salesforce 98.”

The Force.com IDE and the new metadata API have enabled copy and paste moving of Page Layouts. Here’s a quick movie showing just how easy it is: