Almost every time we encounter an organization with multiple applications running their operations, we always hear the same request for a fully integrated real time data solution with a CRM solution acting as the glue holding everything together. While this is technically possible, we rarely end up delivering this type of solution after going through a cost-benefit analysis with the organization. Below is some of what we consider and cover in that decision making process:

Step 1: Determine the Value Proposition of Integration

The first and most important consideration is to determine the real value that this integration will bring to your organization. In most cases we find that organizations are already generating integrated views of information even if they come from separate applications. This is often done with some manual analysis using Excel and other tools. The real value of a systems integration project can be measured in the following ways:

• Costs Savings – How much are you saving in labor costs by not making your employees do the extensive manual analysis to reconcile data from multiple applications?
• Time Savings – What benefit does having this data in real-time or near real-time provide to your organization?
• Accuracy – Does systems integration result in more accurate reporting? If so, how much in savings are you achieving through better information.

Step 2: Evaluate the Integration Approach Alternatives

Generally speaking there are three integration approaches we often discuss with organizations.

• Manual Integration – Allows you to synchronize data back and forth between systems, however, it is driven by a manual process. This is typically done on a weekly, bi-weekly, or monthly basis often with several tedious steps.
• Uni-Directional Integration – In this situation, we make a determination that one Application will be the primary and another one will be the secondary. The Primary application always sends data to the secondary application(s), however, it never receives any data back. Uni-directional integration can either be real-time or conducted in batches (such as nightly updates).
• Bi-Directional Integration – This is the most complex type of integration and also the most often requested. In this situation applications transact data (often in real-time) in both directions. For this to work effectively rules must be in place to resolve conflicts. A conflict is a situation in which both applications attempt to update the same information at roughly the same time. In this situation, we need to be able to establish an order of precedence as well as a transaction log so we can correct any mistakes.

Step 3:  Perform an ROI Analysis of the Alternatives

For each of the integration alternatives consider the Return on Investment (ROI). While you can consider an investment over a longer time horizon most IT investments are often evaluated on a 3 to 5 year time horizon.

The above chart is meant to be a hypothetical analysis of cost/benefit and ROI for an organization. Actual costs will depend on the complexity of your existing applications and the integration solutions you decide to go with. The above chart is also not meant to be an endorsement of Manual Integration. For many organizations this might be the right approach, however, that determination can only be made after a careful analysis of your integration options and your internal cost structures.  

In a previous post, I talked about a few ways that I customize web-to-lead forms. One of the most important improvements you can make, I think, is to add Javascript functions to format phone numbers.

When you enter 10 digits into a phone number field in Salesforce, it gets formatted as (206) 555-1212. Web to lead forms don’t do this by default, so phone numbers show up in Salesforce with inconsistent formatting. This is the reason I first started fiddling with Javascript in web-to-lead forms.

Javascript lets you change data when a website user moves out of a field - you simply respond to the onblur event by calling a function such as my formatPhone function. In the web to lead form, your phone field tag will look like this:

<input  id="phone" maxlength="40" name="phone" size="20" type="text"
     onblur="formatPhone(this);" />

The Javascript code goes in a <script> block within the <head> section of the web page:

<script language="JavaScript" type="text/JavaScript">
<!--
    //Written by Evan Callahan, NPower Seattle
    function formatPhone(num) {
    var re= /\D/;
    var newNum=num.value;
     if (newNum != "") {
        while (re.test(newNum)) {
         newNum = newNum.replace(re,"");
        }
        if (newNum.length == 7){
           newNum = '(206) ' + newNum.substring(0,3) + '-' +
               newNum.substring(3,7);
           num.value = newNum;
        }
        if (newNum.length == 10){
           newNum = '(' + newNum.substring(0,3) + ') ' +
               newNum.substring(3,6) + '-' +
               newNum.substring(6,10);
           num.value = newNum;
        }
      }
    }
//-->
</script>

My function defaults 7 digit numbers to a 206 area code - if you aren’t fortunate enough to live in Seattle, you can replace this with a different default (or skip the whole section).

We use web-to-lead forms pretty extensively for our Salesforce clients, because it is so much less expensive for them than integrating with the API.  We’ve found that WTL can work not just for ordinary leads, but also for simple event registration, volunteer signup, pledges, and many types of "applications" for service or grants.  Leads don’t have to be just people - they can bring in organization, donation, grant, or service information as well.

For example, we worked with a group that matches teen interns to other nonprofits that need interns.  The organizations that want interns apply for services on a web-to-lead form; the teen applicants sign up on another.  The first type of lead gets converted into an account, a contacts, and an internship "opportunity," while the intern applicants stay as leads until they are either matched to an internship (via contact roles) or rejected and deleted.

This is just one example of how web-to-lead has allowed us to set up simple website integration relatively quickly.

The more you use web-to-lead, however, the less you’ll like the HTML form that Salesforce provides you.  We edit the form pretty extensively, for several reasons:

• To arrange and align form fields in a table and apply styles
• To format phone numbers and other values as they are entered
• To provide validation, making certain fields required and helping to avoid spam
• To set hidden values, such as Lead Source or Record Type, that we don’t want to show on the form
• To create or modify a picklist for values, such as Campaign

The first thing I do for web to lead is format the form in a table - two columns, with the labels at left and the fields at right. Then I add styles for labels and fields to the stylesheet.  For examples, take a look at forms for Teens in Public Service, Communities Connect Network, and Arts Corps.  To see the form’s HTML, view the source code for the page and search for WebToLead.

I will offer other a few other examples of web-to-lead techniques in subsequent posts.

If you are using the latest Force.com IDE to develop s-controls or Apex code, you know how nice the latest upgrades are — for editing code, testing, and staying in sych with Salesforce.

I’ve just discovered something else really great — you can edit metadata for objects and fields in your Salesforce instance.  (It has to be a sandbox or developer instance, but you can then package and "deploy" your changes to a production instance.)

Have a custom object or a picklist in one instance and want to copy it to another?  Need to change a bunch of field names or picklist values?  You no longer need to package the items and install them from the appexchange, or go through all the pointing and clicking.  Instead, you make the changes in the object metadata XML files in Eclipse — you can use the XML design tools, or just edit the raw XML:

At first, I was getting a lot of errors when saving objects.  There is a bug, and I found the workaround here.  Basically, there is this file called package.xml — if you are adding an entirely new object (via the New menu), the Force.com IDE updates that file with your additions.  But if you just add custom fields, or if you copy and paste anything from one instance to another, it won’t be in package.xml, so you’ll get an error when saving or synchronizing to Salesforce. 

The trick is to open up package.xml, find or create the section that lists the type of thing you want to create, add the tags, save package.xml, and THEN save your new items.  For example, putting this code in package.xml lets me add the three custom fields shown in the Lead.object file above:

   
        Lead.Address_Type__c
        Lead.Birthdate__c
        Lead.Communication_Preference__c
        CustomField
   
Be sure to add the code to package.xml before EACH thing you add/paste and save, because Salesforce synchronizes package.xml when you save, taking out any entries that aren’t actually in your instance.

At NPower, we’ve been making increasing use of Apex code to do some things we could not do before:

• enforcing business rules across objects
• updating records automatically across objects
• rolling up data like membership renewal date and contact donation totals 
• separating the web interface of s-controls from the code that actually modifies data

All great stuff!  And we love creating and testing Apex code (and s-controls) in Eclipse.  The latest release is really slick (more on that in another post).  But what we really wanted when this was all done was to give a consultant or a client a link where they could install this code into their own production instance of Salesforce.

Until this week, I thought the only way to install Apex code was to create a sandbox or developer account that exactly mirrors the account you want to install into, create and test all the code, and then deploy.  But I found out we can now package all this up into an AppExchange download.

I tried this out yesterday with a large package of apex, s-controls, custom fields, reports, and so on. The Apex code installed, tested, and deployed directly from the package link.

This will be a big timesaver for us — and in the long run, I hope it will make it possible for us to create powerful tools that clients can install with very little help from us.

Now all we need is the ability to package page layouts on standard objects.

Here are a few tips we are sharing with our clients about keeping their CRM instances safe and secure. This is mostly targeted at organizations that are currently using the Salesforce platform.

We can broadly break up this topic into three areas:

Physical Security

Machine Access – If you or your staff operate in a fairly public environment where their machines could easily be accessed by others, you need to take extreme care to ensure that your users logout whenever they are away from their machines. Since it is likely that Users will forget to logout it would be prudent to setup a frequent Session Timeout. You can do this in Salesforce by going to Setup –> Security Controls –> Session Settings. We would recommend the 30 minute timeout for anyone who operates in a public or semi-public space.

Written Passwords – Ensure that your users are not writing their username and password on a sheet of paper which is next to their computer. We have witnessed this many times and it defeats even the best security measures!

Digital Security

Strong Passwords – We recommend that you set your password policy so that at least 8 characters are required with a mix of alpha and numeric. Never allow the password to be used as a part of the username or the security question. To manage password policies in Salesforce go to Setup –> Security Controls –> Password Policies.

Password Expiration – We recommend you have your passwords expire at least once every 90 days and more frequently if you organization can handle it. Please note that if you have external applications (such as a website) which interface with your CRM, you will also need to reset these passwords when they expire.

Disable Accounts – Don’t forget to disable accounts for former employees and consultants who may have been on the system in the past.

Audit Your Login History – Check out who is logging into your CRM instance by viewing the Login History or User Adoption Dashboards. You may even want to setup a report that you can check on a periodic basis.

Recovery

Backup Your Data – Please backup your data! If you are a Salesforce user, you can backup your data for free every week. Simply go to Setup –> Data Mgt –> Data Export. If your data changes so frequently that a weekly backup is insufficient, consider using a product such as Demand Tools or get an ODBC Driver which allow you to connect to your CRM and download all data on a more frequent basis.

Following the above tips should leave you in pretty good shape for your CRM security. Also, please be sure to read any security bulletins which your CRM vendor sends to you and alert your users to any new threats as they arise.

Some time ago, I had a client who needed an easy way for inexperienced users to filter a report, on a regular basis, based on several different criteria.  In Salesforce, anyone can filter a report like this, but it takes a couple dozen clicks and a bunch of typing.  I wrote a simple s-control that allowed users to filter the report in a really simple interface.

When the user selects values and then clicks Search, the Javascript code builds a long URL that tells Salesforce to open the report and apply all the selected filters - something like this:

https://na3.salesforce.com/00O50000001QCuS?pc2=00N50000001JsTx&pn2=eq&
pv2=American%20Sign%20Language&pc4=00N50000001JsUX&pn4=in&pv4=Immunizations&
pc5=00N50000001JvOE&pn5=in&pv5=North%20End& pc6=00N50000001JvNO&pn6=eq&pv6=1

I showed my s-control to Drew Piston at a Salesforce event last year, and it turns out he was hoping to do something similar for his group at the Bay Area Chapter of Red Cross.  This week, he posted a Jing screencast that shows his version of the s-control in action.

Thanks Drew! 

While reading Steve Anderson’s blog (http://gokubi.com), I was inspired to put up one of our screencasts. 

Anand was nice enough to put together a great screencast about creating a basic Apex trigger. This dives into some code but isn’t too technical that the average Salesforce admin can’t understand it. Take a look!

http://www.screencast.com/t/KZyKK0NXrXR

I want to show you how a particular nonprofit is using Apex code: the Center for Employment Opportunities (http://www.ceoworks.org).  They demo’d their Salesforce configuration at the NYC Nonprofit User Group (run by Lisa Glass-Kornstein, just back from her honeymoon!).  They use Apex to do complicated business logic like cross-object verification and data transfers based on triggers.  I know Jessie Grenfell from CEO is going to update this presentation, but I figured I’d get it out there so people can see it.

Are you using S-controls or Apex in your organization?  What business process are you solving with these tools? 

By rob

My apologies for the spotty posting and test posts. Beth’s linking brought more subscribers than I anticipated during this soft launch.  I’ve been back from San Francisco almost a week now, but I feel like I’m just surfacing.  I was hoping to do a more formal launch of this blog at the conference - and post much more during the conference than I did - but I was having some technical difficulties with Wordpress…so there you have it.

A few DF roundups:

• Steve Andersen captures the week well in his wrap-up post
• Jenny Council did a great report out of the post-npsf summit meeting
• Everyone is looking for CRM consultants in the sector
• I posted a few of my take-aways

I plan on doing a broader announcement sometime soon. If you are reading this via RSS, please spread the word (and contact me if you are interested in blogging here about salesforce).