One of the great things that I have said many times about the Salesforce platform is the ability to customize it to your organization’s specific needs. This can be done either by finding an application on the AppExchange that satisfies your requirements, or rolling up your sleeves and building “it” yourself with We recently encountered a sleeve-rolling-up challenge with a client who wanted to provide a calendar for their custom objects that represented dated activities.

We first explored what was available on the AppExchange. There were numerous options with a couple standouts, but we had a couple of barriers that lead us in a different direction:

1. Price quickly became an issue when we did the math. Although most options had a low per-user, per-month pricing model, the size of the organization did not make it a cost-effective solution.

2. Outlook integration was a key requirement from our end users that couldn’t be satisfied with AppExchange options.

3. Printing was also important to our users and unsupported with the off-the-shelf applications

4. Our clients needed the ability to customize the application with things like look and feel, and specific business logic requirements.

So after some back and forth, we decided to build our own calendar application. We didn’t want to reinvent the wheel, however, and explored existing UI components that might be available for us to use as a starting point. That is when we ended up using the jQuery FullCalendar plugin. The plugin is AJAX-based, which means we get an interactive calendar with features like drag and drop. It also can be extended to your specific needs.

One of the key needs was the ability to send Outlook meeting requests from Salesforce itself. Without going into the detailed requirements, we were able to add a feature that a user could select one of the custom objects we were displaying on the calendar and generate an invite to specified users with all the object information in the body of the invite. The biggest challenge we faced with this was getting the correct format to work with the different versions of Outlook that we needed to support.

The second key requirement was the ability to print. We satisfied this in two ways. The first is a printer-friendly web page version. This was accomplished using the jQuery calendar built-in print capabilities. The second method was a PDF version, which required some additional coding outside of the jQuery component.

These were just a few of the key aspects of the build-versus-buy conundrum that we went through with our client. But in the end we built a nice calendar widget for our application that satisfies our users.

Have you had similar challenges when evaluating the B vs. B discussion? Share your thoughts in a comment.

Leave a Reply

Your email address will not be published. Required fields are marked *