Salesforce1 is Missing the Calendar!

With the release of Salesforce1, Salesforce.com has made it easy to write and extend Salesforce Visualforce pages to any mobile device. No doubt, Salesforce users will be doing more than ever on their mobile devices. But interestingly enough, Salesforce has decided not to place a user’s appointment calendar on the Salesforce1 application. 

There is a "Today" tab on my iphone, but it doesn't seem to pull all my events correctly or give me what I really need to manage my events and calendar. To solve this problem, we at Snapptraffic Consulting produced a Visualforce page for the calendar and enabled that for Salesforce1 and extended it to all the mobile devices associated with our org (which happens automatically, you just need to have installed the Salesforce1 enabled VF page into the org and the tab appears on any mobile device).

A New Mobile Application

Now we have a new "My Day" tab on the mobile device!

Application Capabilities

This is a fairly straightforward Salesforce1 Mobile Application Calendar system that won't need a lot of explanation. Touching the "My Day" tab takes you to a mobile page showing a list view calendar with selectable options of "Today", "Next 7 Days", "This Week", etc. Here is a screenshot of that:

Notice that we included on the Calendar:

- All Events on a given day grouped together

- The Event Start Time and End Time

- The Subject, a clickable link into a drill down page showing all details of the event

- The Name field, also a clickable link to the associated lead or contact record

- The "Related To" field which can also be clicked in order to see the associated record

- The Location and Comments fields

No "New Event" Functionality

Salesforce.com also neglected to provide the Salesforce1 user with a means to create a new event. This is probably my number one need for a mobile device - to create an event while out, away from my computer. We decided to add this to the application as well. So in addition to the items noted above, using this application, Salesforce1 can also create new events from the mobile device.

For now our application styling is patterned off the standard home page look and feel that salesforce.com  uses on their home page that you'd see in a typical browser on a computer. We'll be modifying the style of this page to make it look a little more "typical" for a mobile app as we play with the app and decide on the look that we want.

Get this Application

If you would like this application, we'd be happy to make it available and install it for you. We're offering it for a a one-time fee for installation and licensing. The setup fee is a flat fee of $250 and the licensing fee is $25 per user.

Modify this Application

If you like the idea, but have some changes in mind, we'd be happy to make any changes that you'd like to the application before installing it into your org. These can be handled at our standard hourly rate which you can see on our website referenced below.

Produce Another Salesforce Mobile Application that You Need?

Do you have another requirement that you want to extend to the mobile devices of your team? Not only can we develop salesforce visualforce pages that your internal users to salesforce are using, we can also extend these visualforce pages to their mobile devices as well. In addition, we can develop applications, based on your Salesforce org, as you've customized it,  and extend those to the mobile devices of your users. Contact us if you'd like to discuss and get an estimate for your idea. 

Contact Us

If you'd like to have us install this application in your org so that your team has access to their Events on their mobile devices, just contact us through our website at www.snapptraffic.com. We'd be happy to meet with you, install the application, and help you with any other Salesforce.com issues that you may have questions about. 

Introducing Salesforce1!

One of the major announcements at the 2013 Dreamforce was Salesforce1. Salesforce.com is powering ahead by adding capability to Salesforce that makes it possible to connect nearly any kind of device to the service. The service to the mobile device is getting better and better. Salesforce1 was previously called Salesforce Touch, which was only offered for the iPhone. Now Salesforce1 also supports Android and other mobile devices like the iPad.

This is an exciting development because we'll now be able to write one application in a Salesforce org and make that system available to any device that users in the org decide to carry.

Where I think we'll be helping our clients most with Salesforce1 is by writing visualforce pages to deploy custom functionality to IOS and Android mobile devices. Over the years we have written hundreds and hundreds of visualforce pages. Now we can deploy these pages to the mobile devices. Any visualforce pages deployed to a custom tab in the salesforce org can be enabled for a mobile device.

Example: A Mobile Quoting Tool

I'll give a simple example. Let's say we want to give a quoting tool to a sales rep in the field. The quote consists of a few details from the account, a few primary fields from a contact record, and the basic fields on the opportunity along with the product line items. The rep would like to be able to use one form to enter all the relevant details, have the system create the resulting Account, Contact, and Opportunity, and Product Line Item records, generate a PDF, save it against the opportunity, and email it to the client.

A visualforce page could be written, enabled for mobile devices, and deployed to a tab called "Mobile Quote". Then on the mobile device, the user simply selects that tab and they will see the form where they can conveniently enter all the relevant details. Since it is visualforce, we can also provide countless conveniences geared towards the client's business model. For example, rather than having to use a cumbersome lookup to find relevant products, those could be presented in a picklist or found by enter a couple letters from the product name, whatever the users think would be most convenient.

When finished filling out the form, in one click the PDF could be generated, saved against the opportunity, and emailed to the client.

The options really are endless. This will be a system that we put to great use for our clients. Salesforce1 is finally making mobile a reality for our clients.

If you have a project in mind or simply wonder if the idea you have is feasible, contact us through www.snapptraffic.com, we'd love to hear about your project and let you know what it might take to develop it for you.

Salesforce Drip Marketing

Our clients have frequently asked for help with drip marketing systems for their Salesforce.com systems. There are quite a few options for solving this problem, but I'll detail my favorite below.

(We later wrote this application and are making it available for sale and you can read about the specifics here.)

At the high end there are some third-party applications available on the Salesforce App Exchange that have drip marketing systems built in, but they are surprisingly expensive. So for the purpose of this blog, I'll restrict my ideas to those you could build yourself (or get our help building).

To frame my comments below, let me explain some terms I'll be using: "Touch Track" and "Touch Point". A "Touch Track" is a way of noting the various points along the way that a lead or contact will be "touched" ("Touch Point") as a particular drip marketing campaign is carried out. For example, you might have a touch track with 2 touch points, the first being an email 3 days after the prospect is added to the track, then scheduling a sales rep to make a call attempt 4 days later. You'll see systems like this called Salesforce Automated Touch Campaign or Salesforce Drip Marketing - and probably a few other variations.

A Workflow Based Salesforce Touch Campaign

So lets review some ways you can do Drip Marketing (aka Touch Campaign) in the native Salesforce.com environment. At the simple end of the complexity scale you can use time based workflow rules (in Enterprise Edition) to kick off emails or schedule tasks. This is fairly simple and can be quite capable for the company that doesn't have very sophisticated requirements. In a nutshell, have a "Touch Track" field on the lead or contact record, then kick off a time based workflow depending on the track selected. You could have multiple tracks depending on the steps that you want executed against the particular record. There will be a time based workflow rule setup for each track. If you're just doing this against both leads and contacts, you'd have another set of these workflow rules for the second object. The steps are contained in the particular workflow.

A Better Salesforce Drip Marketing System

A more sophisticated method would be to setup a custom object to contain the steps. A good place to locate this custom object would be as child to the campaign. Then using APEX, a scheduled batch process could be written that executes daily, analyzes the steps under the campaign and how far down the touch track each campaign member is on the day of execution, then takes the action required by the step.

So lets say we call this object the "Autostep" object, our data model for this system would look like this:

The manager of the system could then simply create a campaign for a touch track. Later, leads and contacts would be added as campaign members. The steps of the touch track would each be individual records in the Autostep object. This object could have a number of fields, depending on the level of sophistication desired, but here are a few I think would be essential:

Useful Autostep Fields

Various fields would be needed on the Autostep object. Some I note below would be essential, others maybe not so much - the real requirement would be determined by the functionality that you required. Here are some that I think would be useful:
- A lookup to the parent campaign
- Days until Action: Defines the day on which this step would be executed. I'm thinking this would just be a number field and would indicate the number of days after campaign membership creation (the day the lead or contact was added to the campaign) that the autostep would "fire" against the associated lead or contact.
- AutoStep Record Type: Options for Email, Task, Event or other desired actions like "Post Card". This is a user interface consideration. The record type lets us have different page layouts for fields that may differ based on information needed for the type of action taken. For example, Work Days (noted below), wouldn't be displayed on an Email Step type, but you would want the Work Days field displayed for Tasks, and record types provides the means to choose the appropriate page layout.
- Work Days: this would only apply to a task assigned to an internal Salesforce user and it is the number of days that you want to provide to the worker to accomplish the task. So let's say a task is due on the 10th and you want to provide the worker 5 days to work on the task. The system would make the task 5 days before it is due.
- User: we need some method for identifying the responsible user. The task may define an actual user or tell the system to use the lead/contact owner, or account owner, or a certain role, etc - again, this depends on the level of sophistication that you want.
- Subject: a word or phrase that would be entered into the subject of the event or task
- Comments: text that would be entered into the comments or description field
- Template ID: the record ID of the email template that the system will send

Executing the Touch Campaign

To target an individual in the salesforce drip campaign, simply include that person's lead or contact record as a member of the relevant campaign. The campaign, as a reminder, is the "container" of all the various autosteps - it becomes, in essence, the salesforce touch campaign. The kickoff date will be the created date of the campaign member record (or other relevant field if requirements dictate).

An APEX scheduled batch process can then be written that executes every night, evaluates all the campaigns where autostep records exist, look at the "Days Until Action" field, identify the campaign member records that qualify for an action, and take that appropriate action.

Advantages of this Method

- The same system can handle both leads and contacts (by virtue of the campaign member's association with either a lead or a contact record).
- This system takes advantage of the existing system of campaigns, the advantage being that these names can be provided via the campaign to other major systems such as third party email providers.
- Since this is a custom system already, when a need arises, the system can be further customized to include new functions. If the workflow method described above is used, it only has the capabilities available to the workflow rule - it can't be customized.
- Unlike the workflow rules, the steps can be easily modified by adding and removing autostep records.  To modify a time based workflow rule you have to deactivate it and delete all future scheduled activities - meaning a simple change can completely disrupt ongoing processes.
- Salesforce Web 2 Lead can add a lead to a campaign automatically, so a touch campaign against a new lead can be initiated upon their form submission.

Note: when using the native Salesforce system for Drip Marketing Campaigns, Salesforce.com is sending your emails for you and they have a limit of 1000 to the number of emails you can send each day. You'll want to keep that in mind as your campaigns grow in size. But as with all custom development, we can almost always find a way around problems like that. If you do find yourself running up against email limits, the system could simply add the send requirement to another custom object handled by its own scheduled batch which has the responsibility of sending 1000 emails a day. When over the limit, the remaining emails could be sent the next or following days.

If you would like to discuss this idea further, or get some help developing this functionality, please contact us. It's our business to help companies using Salesforce.com get the most out of their investment. You can find us via www.snapptraffic.com.

Salesforce.com Touch Mobile Application Development

You see the advertisements every day now when logging into or out of Salesforce.com - it goes something like this: "Building your mobile app to work with Salesforce.com is easy as pie!"

So you start thinking: "okay, cool, my team sure could use a mobile app while out on the road to access their Salesforce.com data, and the standard mobile app doesn't do what we need - so if it's so easy, lets do it."

Then you start trying to figure out how to do it and you realize, this isn't actually "easy as pie." It's actually quite involved. But, it is doable - and our development team has done it - so let me tell you what we've learned.

There are several ways to provide access through a mobile device to salesforce.com data.

Salesforce.com Mobile Device Options

1) Use the native browser on the device to login in to Salesforce.com
2) Using a Salesforce Sites page - format the output of the website to fit in a mobile browser screen size
3) Build a native application on a mobile device that can access Salesforce.com data
4) Use HTML5 and the Touch platform to deliver salesforce.com visualforce pages to a mobile device.

It is option #4 that Salesforce is advertising. And while it is WAY easier to build applications on the Touch platform than it is to build a native application on IOS or Andriod (option #3), it isn't necessarily "easy as pie".

The Touch Platform - Web Pages in an App

Here is the key thing to know about  HTML5 and the touch platform: you are simply viewing a Salesforce.com visualforce page in the mobile browser on the page without the skin of the mobile browser. Even more simply: its a web page. A mobile web page. But it LOOKS LIKE an application on the device.

In Salesforce.com, visualforce makes it possible for us to write custom pages that provide custom functionality to your users. These visualforce pages can be built with display on a computer through a normal internet browser in mind, or they can be built with the intent of displaying them on a mobile device.

The Pro - Quick and Inexpensive Development

The cool thing about using the touch platform is that we can fairly quickly write these visualforce pages and your users can take advantage of them on their mobile devices. Many companies have realized the incredible upside to building custom applications on Salesforce.com. They can provide their user's with the means to quickly handle business processes against their data stored in Salesforce.com. At Snapptraffic Consulting we've written thousands of these applications and have seen first hand how the right functionality can greatly increase an employee's effectiveness. Salesforce Touch makes it possible to provide the same kind of custom functionality through the mobile device when away from a computer. Visualforce pages can be written relatively quickly. Native mobile applications (option #3 mentioned above) are much more time consuming. So writing visualforce pages that can be deployed through Salesforce Touch is a great way to increase productivity for your mobile employees without the expense of producing a native mobile application

The Con - An Internet Connection is Required

The downside, to use the application you've written, you must be connected to the internet. If you want the application to have the functionality to download data for offline use, then the touch platform isn't for you - a native mobile app developed for the device that accesses and downloads salesforce.com data (again, option #3) is what you'll need.

Ready to Build Your Own Salesforce Touch Mobile Application?

If you're thinking about building a mobile application to access your salesforce.com data and want some help making it happen, give us a call. We'd be happy to listen to your idea, give you a feel for the costs and timeline involved, and help make your mobile app a reality. You can reach us  through www.snapptraffic.com

Salesforce.com Mass Update Anything

A commonly needed functionality by Salesforce.com users is the means to do a mass update on a given database object, like accounts. Salesforce does provide some mass functions, like mass delete (from the setup menu in Data Management), but this isn't available to the standard user.

Mass Update via List Views

It is a fairly simple development project to provide "mass" capabilities of any sort. These are normally provided by placing a button on a list view.

Maybe you've noticed that when you look at a view, there are checkboxes to the left of the listed records. The user can check as many of these as desired, or check/uncheck all of them using the topmost checkbox. Once the desired records are selected, they can be passed to a function via a button on the list view.

See this screenshot of the "All Accounts" view in my Salesforce.com instance:

We can place buttons above the list of records (to the right of the "New Account", "Follow", and refresh icon). Those buttons can invoke functions that do any desired operation against the list of selected records. 

Commonly needed functions are those like Mass Delete, Mass Update, Mass Change Owner, Mass Change Status. This can work against any object in Salesforce that has a tab, both standard objects like Accounts, Contact, Opportunities, Cases, etc, as well as custom objects that you create. 

Lets say that you have a custom field that you regularly need to change en mass - like the opportunity stage. Maybe a sales rep needs to be able to quickly review a large number of old opportunities and set the stage to closed/lost. A "Set to Closed/Lost" button could be placed on the opportunity list view page layout and users could create whatever views they needed, select records, and pass those to the closed/lost function. 

Incorporating a Visualforce Page

A Salesforce.com Visualforce page could also be included in the process whereby the user selects their desired records, invokes the visualforce page through the button and on that page they could select values or enter data that they want to pass into the selected records. 

Take a look at this example. Here a company wanted to incorporate some campaign management functionality right from the Contact List View:

Here the user would select the contacts that they wanted to incorporate into a campaign, then select the "Manage Campaign Membership". That would open this next visualforce page:

On this page the user could confirm the contacts against which they were about to make a change, then select the campaign and an option for handling the contacts. 

This is entirely custom functionality, designed by a Snapptraffic consultant on behalf of one of our clients while discussing the business problem at hand. 

Since we're talking about custom development, we can literally do any function that might be needed by an organization. 

Related List Mass Update

A mass update can also be deployed against a related list. Related Lists are the sections of information below the detail portion of a record. For example, you'll find an Open Activity "related list" on your contact page layout. When adding a custom button to a list view, a setting can be selected by the administrator that turns on checkboxes to the left of each record on the related list. These checkboxes can be used to pass records from the related list to the developed custom function. Here is an example: 

In the example above, the user can select activities that are open and pass them to a custom function, possibly a "Send Mass Reminder" for your upcoming events. 

Is it expensive?

One of our developers could typically produce a simple mass update function and deploy it to your system in about 5 hours of effort. A more complex process involving a visualforce page might require 10-12 hours of effort. So at the Snapptraffic Consulting hourly rates, a project like this would probably cost $500-$1500 depending on the complexity. Normally a project like this can be built and deployed in just a few days. 

Once the project is complete, you own the code. No ongoing subscriptions.

Is Custom Development for You?

If you think a mass update function like this, or any other development effort you're considering might improve the business practices for your salesforce.com users, feel free to reach out to us via our website: www.snapptraffic.com. We'd be happy to speak with you about your idea, discuss it's feasibility and likely cost. We can also let you know how quickly the project could be completed and deployed. 

A Salesforce.com Custom Portal Case Study

The Need for a Customer Portal 

In November 2012 we received a call from Huong Nguyen of Shiloh Event Creations asking if Snapptraffic Consulting could help her configure the standard customer portal that is available through Salesforce.com. Huong has an event planning business and wanted to move the management of her event planning business into Salesforce.com, but she also wanted to distinguish her company from the competition by providing her customers a portal in which they follow along real time with the planning of their event.

Huong had already considered several project management solutions available on the app exchange and was close to buying one of those. Before doing so, however, she wanted to be sure that certain details of a project could be made visible through the Salesforce.com customer portal. She was asking for our help to determine if it was possible to show to her customers some important aspects of the project (from a third-party application), but to keep other items concealed.

Building an Application rather than Buying Off-the-shelf

We discussed these goals with Huong and suggested that instead of buying a project management system, we build inside of Salesforce.com, using the standard tools provided, the various databases that would be necessary to track her event milestones, assignments, the budget, various charges, invoices, and payments. This approach would have the advantage of a system built according to her existing processes - and further, once the development was complete, the system would belong to Shiloh Event Creations and there would be no further subscriptions for a third-party project management application.

Standard vs. Custom Portal

We also discussed options for the portal itself. While the standard portal provided by Salesforce.com is easy to setup and modify, it didn’t provide the look and feel that Huong was hoping for.

After talking through all the options, she decided that a custom portal with a design based on her existing website would be the best approach. A custom portal doesn’t use the portal system provided by Salesforce.com at all, but is built on Salesforce.com Sites and uses the authentication of a customer portal license. This approach would also permit us to take full advantage of the project management system that we would build in lieu of the App Exchange offering.

Looking for Savings - Platform Licenses

Another important decision in our planning process was to build as much of the system using custom objects (databases) rather than standard objects like Opportunities and Products. Using custom objects means that many of the future internal users of her system would be able to login using Platform licenses.  Platform licenses are significantly less expensive than full Salesforce.com Enterprise licenses.

The Business Process Review

With those choices made we kicked off the project by conducting a business process review in which we noted how Shiloh Event Creations currently planned for and executed the events that they were managing. We discussed how work was scheduled, assigned, and completed. We also talked extensively about the financial side of event planning.

After these conversations we had this sketch from which to work to create the data model in Salesforce.com.

The Shiloh Event Creation Data Model Sketch

We immediately began creating the custom objects (databases) in Salesforce.com, adding the fields, and configuring the page layouts. In just a couple of days, Shiloh Event Creations had a fully functioning Project Management System in Salesforce.com built to their exact work requirements. Even if the portal was never built, this was an impressive advance in the management of Shiloh Event Creations business processes.

The next step was to design the custom portal. For inspiration, we looked at their existing company website, noted the design, the styles, the colors, etc and began sketching a portal with these concepts in mind.

Here is one of our actual sketches from the design process:

This was the longest part of the project, but during these planning sessions we sketched out all the various pages of the Shiloh Event Creations portal. Once that was complete, the development began. The Snapptraffic Consulting development team went to work analyzing the data model, the application already built in salesforce.com, the sketches, the existing website style, and the project requirements – all in the context of the end goal. After that we started writing code!

Over the next few weeks we would meet with Huong every few days to review our progress, take her inputs for changes, and continue development of the requested pages. Here are some screenshots of the final result:

The Portal Login Page

A Detail Page from the Portal of a Shiloh project

A Typical Page from the Portal

Hopefully this case study gives you a feel for how the development of a custom portal built on the Salesforce.com platform can proceed. Thinking about a custom portal for your company? Call us at 800-422-6490 or visit us at www.snapptraffic.com to speak to us about your project.