There are several third party applications that allow you to receive electronic or digital signatures from customers online without requiring you to send physical documents via mail. Many of these electronic signature gathering systems are even integrated with Salesforce.com. Over the years we've set many of these up and found them to be relatively intuitive and very useful.

Electronic Signature Downside - Ongoing Subscriptions

However, they also come at a significant cost, and that is a cost that goes on month after month in the form of a subscription. One of our clients didn't want that ongoing expense and asked us to produce a custom system that would gather an electronic signature and store that in Salesforce against the relevant records and statements to which they were applying their electronic signature.

Legal Electronic Signatures in Salesforce.com

A legal electronic signature, as declared by the ESIGN act in 2000, is one where you have captured an individual's intent to sign, meaning you've verified the user's identity during the signing process, and that the record keeping systems involved make it clear what the individual was signing - specifically what they were agreeing to.

We satisfied these conditions in this custom system by verifying the user's identity through their email address and by allowing them to physically sign using a mouse or finger in their browser or on their mobile device or tablet. Additionally, we tracked the various legal statements to which the individual was agreeing to in the various records that go along with their signature. Finally we capture the image of their signature, the IP Addresses where they initiated and then completed the signature.

Does your company need an Electronic Signature Solution?

Though the description below details how we specifically addressed these issues for one client, the concepts involved would be the same, regardless of the specific way in which they were solved. Consider the case below in light of your electronic signature needs - the concepts below could most likely be adapted to your specific requirements as well.

Electronic Signature Salesforce Case Study

For this client, we used the signing process as a way to gather the final pieces of information that conclude the sales process, so we built an online form with fields where their customer could provide them with the additional needed information. This information would be saved back into Salesforce.com and then the user would proceed to provide their electronic digital signature.

The process works like this: as a sales rep concludes the sale, they send an email containing a link to this online form. That online form is hosted by Salesforce and made visible to the client via a Sites page. Your customer does not need a Salesforce license to deliver this form to the client via Sites.



The customer would fill out this form. This form could contain any fields that the company wanted. It is a normal online form, it differs only in that it is hosted by Salesforce and is used to start the signature gathering process. The data entered by the customer into this form saves right back into the initiating record in Salesforce.com.

As part of this form we also include the various legal statements to which we need the client to agree. These are listed on the form and can be read by the client if desired.




When they Submit for Signature, we save a signature record in Salesforce indicating that they have started the signing process. We know who the contact is and we capture their IP Address. We send the client another email with a link to the actual signature page. We list again the statements to which the user agreed on the previous page, ask them to indicate their agreement by checking the box, and then sign.


Here they will actually sign, using their mouse or their finger in the form provided. This works in a browser, a phone, or a tablet.

When the person signs and submits their signature, we update their signature record in Salesforce with a second IP Address that shows where they were as they submitted the signature. Here is an example of the record created in Salesforce with the details of their signature.

PDF Document Generation

Further, we can produce PDF documents and place the image of the signature into the signature block of the document. These documents can look exactly like any official or custom form that you have. They can then be attached to records in Salesforce.com or emailed. In the screenshot above, notice the button labeled "8655". This button produces a form this company calls the 8655 and the document is pre-populated with data from the signature, the contact record to whom the signature belongs, and the account record at which this contact record resides.

Sign In Person

For those times when a client is sitting right there in the office, it didn't make sense to send them an email. If you remember, the email is a technique for verifying their identity. When they are in person, you have already verified their identity because you are looking right at them! So in this situation, we start the form from within Salesforce, hand them an iPad to fill it out, then when they Sign and Submit on the first page, rather than sending an email we proceed straight to the signature page.

The Power of a Custom Solution

The beauty of a custom solution is that you pay to have this setup for you once and then you own the solution - no ongoing subscriptions to an electronic signature solution provider. Beyond that though, a custom electronic signature solution signing process is tailored to the way that you structure your sales process. We can use sites to gather information from your customer, we can collect and save their signature as detailed above, and we can go on to make various PDF documents and place their signature onto those documents - all in a way tailored to your specific business processes.

Have Snapptraffic Consulting Build this for Your Company 

If you would like to discuss having us build a process like this for you, please reach out to us at www.snapptraffic.com. We can affordably build the pages and processes you need, right onto your existing Salesforce org, and best of all, you'll have no ongoing subscriptions, just the up-front development cost, which depending on the complexity of the surrounding functions can probably be accomplished between $3000 and $5000 and completed in just a few weeks. Use the contact us form at www.snapptraffic.com and we'll reach out to quickly, discuss your requirement, and give you a feel for the costs involved in having your solution custom built.

As you already know, Salesforce.com has a pretty good system for managing campaigns. You can send emails from those campaigns, among other things. They even have the native capability to track opens when the email is an HTML formatted email.

However, as great as all that is, there is no native capability in the Salesforce.com campaign system to track click-throughs (or "click-thru" depending on your preference). Now what I mean by that is that when you send an email to your list of recipients, you'll frequently have links in that email, inviting the reader to click through to your website or to various landing pages. The marketing manager is always going to want to know how many people clicked on a particular link. This is useful for testing and improving the marketing message. What do you do though if Salesforce has no native capability to track this?

There are some third party applications that can do this for you, but price a few of them - they'll run thousands and thousands of dollars - PER YEAR!

An Inexpensive Alternative

There is a better way! Well, by better I mean easier and less expensive.

Salesforce.com has what they call  "Sites." It is a system that lets you publish anything you desire from your Salesforce org publicly to the web. We use it for forms, for portals, for applications - for anything where you want to interact with individuals who are not license holders in your Salesforce.com org.

By virtue of that powerful system we can setup a method of tracking click-throughs. Here is how we do it. We setup sites so that you have a domain (like yourcompany.force.com). Then we deploy a page to your site, named something like "tracking", and on that page we have some code to manage the tracking of a view and a redirect to where you really want them to land.

So the site address would be:

http://yourcompany.force.com/tracking

Now, the key is what comes as a parameter on that page.

Use Salesforce Campaigns and Sites

In Salesforce, in a new separate object under the Campaign, we setup an object called "Email Link" or something similarly named. The main field on that object is an auto number field. After that we have two other fields, one is an input field where you enter the link that you want to put in your email. The other field is a formula field that returns the link you'll actually put in your email - which is completely different than where you want to send your reader. Let me explain.

In the email, there will actually be placed a link to your sites page, that link is similar to what I showed above. That link will also contain a parameter, so fully formed it looks like this:

http://yourcompany.force.com/tracking?LinkID=0004

The link ID is the auto number in the Email Link record that you setup.

So let's say you wanted to place a link in your email to www.greatcompany.com, but you want to track the click throughs. You'll make a record in your Email Link object under the campaign. One like this:


Now, instead of placing http://www.greatcompany.com in your email as a link, you place http://yourcompany.force.com/tracking?LinkID=0004 as a link instead.

Track Click-Thru Rates in Salesforce

On the sites page, when someone arrives there with the URL populated with that LinkID, the code can find the email link record associated with that number, find the actual destination link, and redirect them to the actual http://www.greatcompany.com link. BUT - while they are there, we'll track the fact that they arrived there and were redirected. Plus, while they are there we can pick up a few details about them such as their IP Address and Browser. All these details we save into a Click Through record. This record is in another custom object that lives under the Email Link object.

So the data model looks like this:

And then after people receive the email and start clicking through, you'll see those Click Through records appearing in Salesforce.com.


(You can see my example near the bottom of the picture above).

Report On the Click Throughs to Your Campaign

Those links can now be easily reported on using a custom reports that you can easily make in Salesforce.com.

Would you like to have this system? If you have a developer, then they can fairly easily build you such a sites page, the logic shouldn't be too difficult for them to figure out.

 If you'd like us to do it, we charge a flat rate of $1500 to install this system into your Salesforce org (an enterprise level org or above) and give you some training on how to use it and build you some reports to show those click throughs per campaign. We can even make some minor tweaks to the code if you need those. Most likely we could include that in the price quoted above. For more significant changes, we'll estimate those separately.

No Subscription Required!

That is a one time charge for our effort to install this system and get it setup for you - that means NO ONGOING SUBSCRIPTION FEES!

Would you like to discuss having us install this click through tracking system into your Salesforce.com org? If so, reach out to us at the contact us page at www.snapptraffic.com. We could have this installed and working for you in just a few hours.

A very common requirement for Salesforce.com subscribers, and our clients who we help to set it up, is to implement maps that incorporate data from their Salesforce org. Most clients meet this requirement by subscribing to a mapping application that is installed into their org.

The Downside of Subscription Based Applications

While these applications are powerful and generally have a boatload of features, they also come with a hefty monthly subscription that goes on and on for as long as you need those functions. Over time, the total subscription cost could far far exceed the cost of simply having the features you need developed instead.

Further, you are very likely buying features that you'll never need or use. You might want to consider another approach.

The Power of Custom Development

A recent project we did is a good example of why a company might want to have an application developed rather than buy a subscription. Our customer finds recruits to work in their client's business locations. The people they are looking for need to be in close proximity to the business.  They needed a Google map to show their Salesforce data in two specific situations:

1. They needed to be able to find workers when a new job came up. When this happens they need to see a Google map centered on the business location with pins surrounding that showing the closest consultants, recruits, and leads. This required finding and displaying data from 4 different Salesforce.com databases on a Google map.
2. Their second requirement was to see a Google map, again centered on the relevant business, showing possible replacement consultants and recruits near the business when someone doesn't show up. Again, this required finding and displaying data on a Google map from multiple Salesforce.com objects

To satisfy this requirement, we built several components into their Salesforce system. First we wrote a trigger on each Salesforce object (database) from which addresses would be mapped. These triggers would geocode (a number that represents the latitude and longitude of the address) the address found on the particular record. The trigger executes whenever a new record is created or the address is edited. This process speeds up operation and reduces the number of API calls made when the map is generated.

To display the maps, we gave them two options. The first option displays the map right in the page layout so that they see it whenever they look at the relevant record. The second option makes a link that opens the map into a new window when clicked. That link can be placed almost anywhere so that they can put the link in various relevant locations such as lists or reports.

Is Custom Development Expensive?

This project, built specifically to solve the specific requirements that this client had, cost about $2000 to have developed. This might seem like a lot at first glance, but a key thing to remember is that this is a one time development fee. We gathered the requirements with the client, wrote the scope, conducted feasibility, developed the code, tested it, and deployed it to their team.

They now own this code and will incur no further costs with regard to this system going forward.

If you have a requirement to place Google Maps into your Salesforce.com org to display data unique to your organization and want to have it made to suit your specific requirements without ongoing subscription costs, you may want to consider custom development. We can take advantage of any of the features provided by Google Maps while displaying your map either right in your salesforce org or on external pages launched from Salesforce.

The options are nearly limitless, but the key is that they are built to your specific needs.

If this sounds like something you require in your Salesforce system, we'd be happy to speak with you, listen to your requirement, and give you an idea of the cost to have us do it for you. You can reach us via the contact us page at www.snapptraffic.com.

The existing Salesforce1 application makes creating and deploying mobile applications super easy and we've done a lot of them at Snapptraffic. You can see a blog post we did about that a while back here. But Salesforce1 has many limitations, and in most cases we can write a native iOS or Android application for a mobile device to overcome these limitations.

Overcome SF1 Limitations by Going Native!

One of the biggest limitations to Salesforce1 for a mobile device is that for the most part it needs an internet connection to function well. There are a few offline capabilities, but they aren't very strong.



One of our clients has technicians that spend much of everyday in locations that do not have an internet connection. Their job assignments are made in Salesforce by a person working in the office and logged into Salesforce the typical way via browser, but the technicians are out on the road and logging into Salesforce from a computer is impractical, especially when they have their phones with them all the time (even if they don't have service much of the time).

Provide Offline Capability with Salesforce Native iOS Application

Not only did the technicians need a convenient way to see the jobs that they needed to do, they needed to a way to:

- Accept the job and confirm that they were going to take it
- See the details of the job and the assets against which they would be working
- Be able to log their conversations with on site personnel
- Log their travel and work time
- Update their status to indicate that they had completed the work or provide other feedback
- Perform inspections and fill out various forms

All this would frequently need to be done while offline.



To provide these capabilities we wrote a native iOS application designed for the Iphone since that is the device that their technicians have been given. (doing this for the Android is done the same way)

Salesforce Mobile SDK 

Salesforce provides a Salesforce Mobile SDK which gives us the tools to use Salesforce as the backend server to the Mobile device. So whenever we want to retrieve data from Salesforce and bring it to the mobile device or write data from the device back up to the Salesforce.com org, we can do so using the tools provided in the Salesforce Mobile SDK.



If you've used other mobile applications that sometimes expect to query data on the internet, you know how frustrating it can be when waiting for the application to make a connection attempt. It's like it never occurred to the designer that the device wouldn't have a connection at some point! We wanted to specifically avoid this frustration and instead built the Salesforce native mobile application from the ground up to only attempt a sync after testing that there was a connection or when the user specifically requested a sync.

Working off the Grid

So we wrote the application pictured in the images posted above that would let a technician sync their phones at whatever point during the day that they had a connection. Then as they worked throughout the day, both with and without connections, the phone would work without pausing to check for connections. The rep could do any work needed on the device. Making status updates, logging conversations, logging time, making notes for their work, doing inspections, filling out required company forms - all of it, from the convenience of the device without needing an internet connection.

Later when "back on the grid" they can open the app, go to the sync page, and see a summary of work completed offline that is waiting for sync, then by clicking sync the device will login to Salesforce and upload all the work done while offline. At that time it will also pick up any new assignments or changes to affected records and bring them down from Salesforce to the Mobile Device.

Are Mobile Applications Expensive?

A mobile application is generally going to be more expensive than writing a Salesforce1 application delivered to the device via visualforce - those are easy and cheap to produce, but again, with the limitations noted above. For a simple application with a few pages involved, the cost will probably be in the range of $10k-$15k. And obviously, as complexity and size go up, so will the effort and cost involved in producing it.

Get an Estimate for your Project

If you have a project that you're thinking of, we'd be happy to discuss it just to give you an idea of the costs involved. If you'd like to tell us your ideas and get a feel for the costs involved, visit www.snapptraffic.com and fill out the contact us form there. We'll schedule a call to discuss your project.

One of the projects we've built over and over in many forms in salesforce.com is the zip code lookup to return a city and state or the time zone lookup to get the timezone from a state or area code. These are similar projects in many respects.

In a nutshell, you have some input parameters, a custom object that contains those input parameters and the needed output, and a trigger on the target object that takes the input parameters, does a query against the custom object to find a matching record, and returns the needed data to the target object.

To get you past that gobbledygook I'll give a specific example of the city and state lookup from a zip code. The ideal place to put this functionality is on the lead object, but it could also be done from account or contact addresses.

So lets say that your reps are on the phone with a prospect and they need to enter the prospect's address. They'll get the street address, but instead of asking for the city and state, they could instead just ask for the zip code and leave the city and state fields empty.



Then when they save the record, a trigger from the lead object in salesforce will use the zip code to do a lookup against a zip code salesforce custom object. That object would contain a table filled with all the zip codes in the country, their state, and their city. Once the trigger found a match it would bring the city and state back to the lead object and populate those fields.

Another common request along these lines is a small visualforce page, either as a standalone page or a component that rests in the lead page layout where the address is entered. In this method, as soon as the zip code is entered the system grabs the state and city and populates those fields on the fly. The previously mentioned technique doesn't populate until the lead record is saved. As you can imagine, the salesforce visualforce zip code lookup component is more convenient and user friendly, but it would take a few more hours to implement given the need to create a visualforce page. If you're on a tight budget, you could get by with just the trigger, if you want the function to be a bit more seamless, then the visualforce component for the zip code lookup would be a better choice.

Another common need in salesforce is to determine the time zone automatically from whatever inputs you have available. Normally when speaking with a prospect you have a state and frequently you also have a phone number. From either the lead, account or contact addresses in salesforce, the state can be used to determine the time zone in most cases, but there are a few states out there that contain more than one time zones, like Florida, which enters the central timezone around Panama City. The area code can be used to fine tune the result. Zip codes can also be used to determine the time zone, you just need to obtain a database that contains the timezones by zip code. I found a few pretty quickly via google.

This project would be implemented using the same methodology as the zip code to city state system described above. In this case, the custom object would be called Time Zone and have fields for the inputs, so state, or area code, or zip code. A trigger on the lead object could take the inputs on save and find the matching time zone record and bring back the time zone into the appropriate field on your target object.

Likewise, a visualforce component could also do this if you wanted the timezone lookup to be populated on your lead page layout dynamically right as the inputs were populated. Again, this technique is going to cost more to implement, but it provides for a nicer user interface.

The beauty of salesforce, visualforce, triggers, apex, and the like is that via custom development we can solve these problems in whatever way suits you and your business processes best - and it doesn't have to break the bank. A trigger like described above would cost about $500, the visualforce component might reach $1200 or so. It all depends on the exact requirement, but that gives you an idea of what you might have to spend (with Snapptraffic anyway) to get this built.

If you're doing a project like this, or just need to have this done for you and would like our help, feel free to reach out to us via the contact us page on our website: www.snapptraffic.com. We'd be happy to help with this or any other custom development project or salesforce.com assistance you may need.