I changed it into a Visualforce page with a custom Apex controller and now it runs super fast and I am able to keep the “Show Custom Sidebar Components on All Pages” option turned on and see it on every page I go to.  There’s a bit of hardcoding in here, but it gets the job done pretty well.  Bye bye s-Control.

Visualforce

The Page is almost all raw HTML.  The only dynamic thing in there are the count values.  Each one retrieves the value from a specific “get” method in the controller.  If you like the queries I use, then the only thing you’ll need to confirm are the URLs that get linked to.  The first 2 go to Views in my Org and the last 2 go to Reports in my Org.  You’ll need to change those URLs.

I named the VF Page “SidebarSummary”.

<apex:page controller="VFController_Sidebar_Summary" sidebar="false" showHeader="false" standardStylesheets="true">
<style type="text/css" media="all">
body{margin: 0; padding: 0; color: #000000; background-color: #E8E8E8;}
#DIV_Container {background-color: #F3F3EC;}
</style>
<div id="DIV_Container">
<table>
<tr><td><em>Unread Leads</em>:  </td><td><a href="/00Q?fcf=00B30000005JhsT" target="_parent"><b>{!UnreadLeads}</b></a></td></tr>
<tr><td><em>Leads - Not Contacted</em>:  </td><td><a href="/00Q?fcf=00B30000005Jhru" target="_parent"><b>{!NotContactedLeads}</b></a></td></tr>
<tr><td><em>Oppty - Next 30 Days</em>:  </td><td><a href="/00O30000001aEHV" target="_parent"><b>{!Next30DayOppty}</b></a></td></tr>
<tr><td><em>Oppty - Past Due</em>:  </td><td><a href="/00O30000001aEHV" target="_parent"><b>{!PastDueOppty}</b></a></td></tr>
</table>
</div>
</apex:page>

Apex

The controller has a method for each query to be run.  Each query is a count() query and returns an Integer.  At the end is a really lame Test method, but it does get 100% of the code covered.  I am certain the code works, so I didn’t do too much with the Test method.  Salesforce just requires the code to be tested.

public class VFController_Sidebar_Summary {

public Integer getUnreadLeads() {
return [
select count() from Lead
where IsConverted = False
AND IsUnreadByOwner = TRUE
];
}

public Integer getNotContactedLeads() {
return [
select count() from Lead
where IsConverted = False
AND Status = 'Open - Not Contacted'
];
}

public Integer getNext30DayOppty() {
return [
select count() from Opportunity
where IsClosed = False
AND (CloseDate = Next_N_DAYS:30 OR CloseDate = TODAY)
];
}

public Integer getPastDueOppty() {
return [
select count() from Opportunity
where IsClosed = False
AND CloseDate < TODAY
];
}

static testMethod void testVFController_Sidebar_Summary() {
Test.setCurrentPageReference(new PageReference('Page.SidebarSummary'));
VFController_Sidebar_Summary controller = new VFController_Sidebar_Summary();
Integer i1 = controller.getUnreadLeads();
Integer i2 = controller.getNotContactedLeads();
Integer i3 = controller.getNext30DayOppty();
Integer i4 = controller.getPastDueOppty();
}

}

Homepage HTML Component

I created a component for the Narrow side and put the following HTML into the editor.  Essentially, you create an IFRAME and embed the VF page into it.  I found a (unsupported) trick on the forums to remove the developer bar from a page.  Just add ?core.apexpages.devmode.url=1 to the URL.  This will turn off development mode when that page is rendered.  This is important for this little iFrame page on the sidebar.  From what I’ve gathered, this hack is not supported and could change at any time.

The code below should work for you.  The only thing you might need to change is the Page URL if you didn’t name your page SidebarSummary and the height of it.

<iframe src="/apex/SidebarSummary?core.apexpages.devmode.url=1" frameborder="0" height="100" width="100%"></iframe>

Let me know what you think.

Deep inside the forums, I found the trick to get some meaning into those activities.  The best you can do is get the Subject filled in, but that’s something.  The subject for a Mass Email = “Mass Email: Email Template Description“.  Giving your email templates a description is the only way to get a meaningful mass email activity.  The Description is an often overlooked field on Email Template because it’s not required, so go make sure you have it filled in.

Once you do this, the next Mass Email you send can start having some meaning.

I created an idea on Idea Exchange for what I think a better design would be.  Vote on it and comment there to improve the recommendation.

I came up with a formula that takes the Lead Status and Expected Close Date (a custom field) into account in order to derive a Rating value on a Lead. This client happens to use Leads for their entire sales cycle and converts Leads once they are sold, but this concept would apply to equally to Opportunities as well.

Requirements

The simplified requirements are to derive a Rating value as follows:

They plan to manage their pipeline closely using the derived Rating field. They want the Rating to get "better" as time passes, so that they can reinforce the use of the Expected Close Date field. For example, if there is a Lead in Presentation status and it gets forgotten by Sales, that lead’s rating will eventually get to "Hot" as the Expected Close Date approaches or is passed. Management will be asking about that Lead and it will either be accurate or the Expected Close Date will be updated to better reflect reality. Over time, they will really be able to trust the Expected Close Date field, which is a new field for them.

Solution

To accomplish this, I did the following:

1. Added a custom field on Leads called Expected Close Date. This would be filled out by the end-user and acts like the Close Date does on an Opportunity.
2. Added a custom formula field called Days to Close that calculates how many days away the Expected Close Date is. The formula is as follows:

   Expected_Close_Date__c - TODAY()

   This field was added to the Page Layout because it is pretty useful in and of itself. Also, the client is on Professional Edition, so we wanted this field available in reports and that’s how you make it visible.

3. Added a custom formula field called Rating (derived) that calculates a rating value using the requirements from the table above. I use this formula approach (using the CASE function) whenever I am doing some kind of matrixed formula result.
   CASE(1,

   IF(ISPICKVAL( Status ,"New"), 1, 0),"New",

   IF(AND(ISPICKVAL( Status ,"Contacted"), Days_to_Close__c <= 60), 1, 0),"Warm",
   IF(AND(ISPICKVAL( Status ,"Contacted"), Days_to_Close__c > 60), 1, 0),"Cold",

   IF(AND(ISPICKVAL( Status ,"Interested"), Days_to_Close__c <= 90), 1, 0),"Warm",
   IF(AND(ISPICKVAL( Status ,"Interested"), Days_to_Close__c > 90), 1, 0),"Cold",

   IF(AND(ISPICKVAL( Status ,"Presentation"), Days_to_Close__c <= 30), 1, 0),"Hot",
   IF(AND(ISPICKVAL( Status ,"Presentation"), Days_to_Close__c <= 90), 1, 0),"Warm",
   IF(AND(ISPICKVAL( Status ,"Presentation"), Days_to_Close__c > 90), 1, 0),"Cold",

   IF(AND(ISPICKVAL( Status ,"Sent I/O"), Days_to_Close__c <= 90), 1, 0),"Hot",
   IF(AND(ISPICKVAL( Status ,"Sent I/O"), Days_to_Close__c > 90), 1, 0),"Warm",

   IF(ISPICKVAL( Status ,"Sold"), 1, 0),"Won",

   IF(ISPICKVAL( Status ,"Lost - No Contact"), 1, 0),"Lost",
   IF(ISPICKVAL( Status ,"Lost - No Budget"), 1, 0),"Lost",
   IF(ISPICKVAL( Status ,"Lost - Not Interested"), 1, 0),"Lost",
   "")

4. The Lead Views and Reports we made for reps are driven by this derived field. By doing this, they have 1 simple value to prioritize on. Also, as new Lead Statuses emerge or if we re-define what "Hot" means, we only need to modify the formula. When we do, all the reports and views automatically pick it up since they are not hardcoding filters on the Lead Status of Expected Close Date fields.

Does anyone else use an approach like this? Any suggestions to make it better?

Depending upon complexity, it is possible to hit formula size limits. Especially considering the need to use the ISPICKVAL function for the Lead Status. Vote on this idea to fix the ISPICKVAL issue.

One of the major benefits of this feature is that you now get quick answers on the Accounts you are selling to without having to run an Opportunity report and get multiple records for the same Account. If you sell to a customer multiple times throughout the year, that customer will be represented once in an Account report, but will be represented multiple times (once for each sale) in an Opportunity report.

Create the Fields

To get started, create a new Account field and choose the Roll-Up Summary option and click Next.

Next, give it a name. I’d like to recommend a naming convention because you will probably create multiple of these. My personal naming convention is used in the example fields below. For the API name, you should also use a naming convention. This will help keep these fields together when viewed in Eclipse or Explorer.

After clicking Next, your options are to COUNT, SUM, MIN, MAX information from the Opportunity. Below is a table with some ideas for fields you that might be useful:

Using Formulas on the Rollups

One really nice thing about these Rollup fields is that you can use their results in your regular formula fields. Using the rollup fields I mentioned above, we can use formula fields on the account to create the fields such as:

• Win Rate (%) = # Opportunities (Won) / (# Opportunities (Won) + # Opportunities (Lost))
• Avg Win Amount = $ Opportunities (Won) / # Opportunities (Won)

Using the Roll-Ups

Now those rollup fields can come in handy in reporting to do things like:

• Filter for all sold-to Accounts: $ Opportunities (Won) > 0
• Filter for all Accounts with Open Opportunities: # Opportunities (Open - This Year) > 0

Another possiblity is in, say, an application that allows you to map your Salesforce.com data. Adding the $ Opportunities (Won) field onto the query page makes generating a map of all sold-to accounts a breeze.

What about you? How are you using Roll-Up Summary fields?

¹ [back] - Other date filters include THIS QUARTER, THIS MONTH, LAST MONTH, NEXT YEAR, NEXT QUARTER, etc. Refer to the Salesforce help for more. These date filters are particularly useful for rollup summary fields.

If you have an org that you need access to without the burden of this restriction (e.g. an org you use to perform demos at various locations and/or from many different computers where you might not have email access), you can authorize all IPs by making 0.0.0.0 the start IP and 255.255.255.255 the end IP in a Network Access record.

Doing this will essentially put that org’s security back to what it was before Salesforce made their enhancements. I wouldn’t recommend making this change unless you actually need it, but it can come in handy even if for a short-term fix.

This is the approach Salesforce.com has taken for Test Drive orgs on AppExchange listings so that Test Drive users are not restricted access to a demo. All of my Test Drives had a record with this range pre-populated by Salesforce when they made their security changes.

Note: I do not recommend anyone do this for their corporate Salesforce.com org as this would negate all the good work Salesforce has done to button things up.

There were a couple of webinars today about the changes. The customer-focused webinar will be available at http://www.salesforce.com/security soon. The partner-focused one will be available in the Partner Portal.

Below is my understanding of what was said and a high-level overview of the main impacts. Please add clarifications in the comments.

API Logins

• If you connect via a Session ID passed from a web link/tab, none of these restrictions apply as the user is explicitly providing you with login access to his/her active session.
• To login with a username and password, the IP address you are logging in from needs to be white-listed.
• Salesforce will pre-populate the org’s whitelist with IPs used in the past 4 months.
• Each end-user can generate an API token to replace their password for API logins.
• API logins using the API token do not require their IP to be whitelisted.
• API tokens do not expire. Only 1 is active at a time. It can be replaced by the user generating a new one. This automatically invalidates the old one.
• API tokens cannot be used to login at https://www.salesforce.com/login.jsp.
• Going forward, the best practice would be for end users to provide their API token to any app/service they use other than the main Salesforce.com login page.

Logging in at https://www.salesforce.com/login.jsp

• Username and password will still be the way to access Salesforce.com from the main login page
• A new feature will be added requiring you to confirm that your computer is valid to login using that username.
• The login page will check if you’ve logged in from that computer before (by looking for a browser cookie)
• If not, the email address on the user record will be sent an email to confirm that you are, in fact, the one trying to login now.
• You will click a link in that email “activating” your computer for login with that username
• Unless you delete the cookie or clear your broswer’s cache, you should be good to go for a while without repeating these steps.
• There are no new IP restrictions affecting logins at the main login page. The profile-based IP restrictions that have been around for a long time are still the way to go there.

If you are a consultant, you may fall victim of the new security measure when you try to login as your client (maybe they couldn’t afford another temporary username just for you). On the call, I was told that you can request a temporary one via the Partner Portal or ask your customer to forward you the email to confirm your PC is okay.

My thoughts

I think it is great to see Salesforce taking a step to tighten up the API, especially. I like to think that my old API Authentication List post had something to do with it, but who knows.

The biggest impact to me will be using client’s logins to get into the system from my PC, but I’ll just have to workaround that one. Security and convenience are generally a trade off and overall I’d rather use/subscribe to a service that is tightened down with my business data. If anyone can handle the inconveniences of logging in, it’s developers since we are used to doing hacks/workarounds in the first place.

I wanted to see if I could create something similar in Salesforce. Using an s-Control that is shown via an IFRAME on the sidebar, I was able to do it. The end result is like having a bunch of Metric style dashboard components stacked on top of each other. You can see it in action below. Each line shows a record count and the record count is a hyperlink to a View or Report. It’s small, clean and tells the user vital information with quick links to see more. I like the concept.

How it works

It is all running in an s-Control and uses the AJAX toolkit to talk to Salesforce. The s-Control is in an IFRAME in a homepage component. The s-Control has a function called getCount and you pass getCount the following:

• Object to Query
• WHERE clause for the query
• Label for the returned HTML
• A URL to let a user drilldown on the result

A call to it looks like this:

theHTML += getCount("Lead", "WHERE IsConverted = False AND CreatedDate = TODAY", "Leads - Today", "/00Q?fcf=00B30000001Qizn");

It uses the object and where clause to do a count() query. It then returns an HTML table row with 2 columns. The first has the label you passed it in italics. The second has the record count of the query as a hyperlink to the URL you passed it. If you don’t pass it a URL, then it shows the record count without a hyperlink.

The s-Control is made up of 2 functions: getCount() and main(). getCount is described above. main() calls getCount once for each metric and then wraps the results in some more HTML. A bit of CSS is sprinkled in to output it nicely on the homepage sidebar. That’s it.

Try It

I uploaded it to the AppExchange to let people try it and improve upon it. It is just a proof of concept. I am using it in my org right now, but it needs to be improved if I will let it stick around. For example, it’d be great to have it cache the data and only run the queries once every 30 minutes because running it can slow the load time a bit. Is anyone up for improving it to meet that requirement?

To make this work for you, you should be familiar with s-Controls. It’s not plug and play. Getting it setup expects you have a working knowledge of this stuff. I kind of hacked it together and wanted to get it out there for other to see. It’s very simple code, but I think it serves a very good purpose. I am interested in what you think.

I set it up with some basic queries, but I’d recommend you change them to meet your needs. To change what the queries are, you need to go into the main() function and edit the lines that call the getCount function. You will need a single line of code for each query you want to run.

If you really want it to work nicely, you should create corresponding Views or Reports and link to those by passing the getCount function the URL of the View or Report.

Once you have your queries all set, you need to add the homepage component. I didn’t package one in the AppExchange package because I have been unable to edit a homepage component that only has an IFRAME in it (WYSIWYG editor bug). I’ve had to delete it and recreate it every time. So you get to do that too!

1. Create an HTML Area Homepage Component
2. Choose it to go on the left (narrow) navigation bar
3. Click the Show HTML checkbox on the WYSIWYG editor
4. Copy the HTML below and replace IdOfScontrol with the ID of the s-Control in your AppExchange package. You can change the height of the IFRAME too.

   <IFRAME src="/servlet/servlet.Integration?lid=IdOfScontrol&amp;enc=UTF-8&amp;ic=1" frameBorder=0 width="100%" height="150"></IFRAME>

5. Add the new Homepage Component to your Homepage Layout

Now you should be ready to test it out. Using a tool like Firebug can greatly improve your ability to troubleshoot issues and make enhancements.

Please let me know what you think by posting comments. I am interested in thoughts on the concept, ways to improve it, issues you are having, etc.

I decided to try and see if I could incorporate Akismet into the web to lead process and I was successful in doing so! I created a set of scripts for you to download if you’d like to leverage Akismet with your web to lead forms.

Akismet is the best spam tool I have ever used. When I posted in January, it had captured 7,680 spam in its existence on this blog. Less than 4 months later, the spam count is up to 23,994. Needless to stay, spam is an exponentially increasing problem and will plague your Salesforce.com environment eventually. I feel that Salesforce.com needs to include a spam filter in their product for web to lead (vote for it).

Until then, leveraging Akismet could help you significantly.

About the Solution

The scripts are intended to be proof of concept for you to use and apply to your own environment. The code and downloads are now being officially hosted at Arrowpointe’s Open Source Project at Google.

To use this solution, you’ll point your web to lead forms to this script rather than to the standard Salesforce Web to Lead page. The script accepts the data from your web to lead form, passes it to Akismet to determine whether it’s spam or not and then passes the data to Salesforce.com’s web to lead page with the Akismet result appended to it.

In Salesforce, you’ll need to add checkbox field (e.g. “Akismet marked as spam”) on your Lead. If Akismet thinks it’s spam, that field will be set to TRUE. You would then need to add assignment rules or validation rules to do whatever you need. For example, you could have a lead assignment rule looking at that one checkbox field and put leads into a special queue if they are marked as spam.

The script leverages the Akismet PHP5 Class to handle the core communication with Akismet. I found this class from the Akismet Development page.

This script will only work on PHP5 and requires the cURL module to be enabled. cURL is enabled by default in most PHP installations. The PHP5 requirement is a limitation of the Akismet PHP5 Class. If you are on another platform (PHP4, Ruby, Java, etc.), I don’t see any reason why you couldn’t use these scripts and integrate a different Akismet toolkit into it. Additional toolkits are available from the Akismet Developer Page.

Cost

You’ll need a server running PHP5. If you have a server already setup, then hardware should cost you nothing.

Akismet is free for personal use, but has a small license fee for commercial use. If you will be using this in production, you should purchase an Akismet Commercial License Key. During development, I am sure you could use a personal key to make sure it works.

The scripts themselves are free and licensed under the GNU General Public License v3. I did this as a proof of concept for the betterment of Salesforce.com data quality everywhere.

Getting Started

1. Add a checkbox field to your Salesforce.com Lead Object that will hold whether Akismet thinks it’s spam or not.



2. Download the scripts. Three files will exist in the zip file:
   • index.php: The main script that handles the incoming data, talks to Akismet and posts the data to Salesforce.com Web to Lead.
   • constants.php: You will need to go into this file and edit some variable values based upon your own organizational setup. See the next step.
   • Akismet.class.php: This is the Akismet PHP5 class I was talking about above.
3. Edit the constants.php file:
   • Enter your Wordpress API key where it says ENTER_WORDPRESS_API_KEY. Get a personal or commercial key if you don’t have one.
   • Enter your company URL where it says ENTER_YOUR_COMPANY_URL.
   • Enter your company’s Salesforce.com Org ID where it says ENTER_YOUR_SALESFORCE_ORG_ID. This is actually optional. Doing this allows you to remove the OID from your public web to lead forms so spammers don’t know your Org ID. Doing this will reduce the amount of spam you actually need to process.
   • Generate a web to lead form in your Salesforce setup. Find the new Salesforce field you created in step 1 and copy the id value from the HTML form and put it in the constants.php file where it says ENTER_THE_W2L_CUSTOMFIELD_NAME. This step is required so that your Salesforce org is actually populated with the Akismet result.
   • PHP Advanced: The $Akismet_noPass array holds the names of fields that should not be included in the content passed to Akismet. Feel free to add/remove values from this array. The values in the array are referring to the names of form fields in your web to lead HTML form. I have no idea if this helps/hurts, but it seemed like a practical thing to add into the script.
4. Upload the scripts to your web server and note the fully qualified URL for that directory (e.g. http://www.example.com/web2lead)
5. Update your web to lead forms to have them post to the location of the files from the previous step (e.g. http://www.example.com/web2lead/ - make sure to put the / at the end of the URL. Not sure why, but I wasn’t able to get it to work without it)
6. Test your form to see if it works. The script acts as an intermediary between your form and Salesforce web to lead. The end-user experience should be the exactly the same with or without the scripts.
7. Once you know it works, you should add a lead assignment rule into Salesforce as rule #1 that looks to see if this field is checked. If so, then route the lead to a “Potential Spam” queue or something of that nature. Another option is to create a validation rule that doesn’t even allow the lead into the system.
8. Make sure your Auto Response rules don’t email a reply to leads marked as spam. If you allow this, then those spammers have an email address to try.
9. Update some/all of your web to lead forms to post to this new page. If desired, remove the “oid” field from the HTML form for each of these since the script will pass your Org ID to Salesforce automatically.

Other Stuff

These scripts are a proof of concept. I am not officially supporting them, but am happy to help people out informally. Post comments here if you have questions/comments/criticisms.

I have only tested this with leads that were either real or very obviously spam. It worked well. From Akismet’s perspective, the data it checks looks just like a blog comment and I can attest that Akismet is amazing at identifying blog comment spam. So it should work well for Salesforce.com web to lead.

I am going to update my existing web to lead forms on this site and see how it works and report back to you. I encourage you to do the same and let me know your experiences with it or recommendations on how to improve the scripts.

Enjoy!

My requirements were:

1. Ability for an end user to, from an Account view, check the records that need to be processed and click a button to process them.
2. The processing is to take place in an external PHP page
3. Pass the parameters as an HTTP POST transaction (i.e. do NOT include the parameters in the URL string).

I knew I would need to create a custom List button so that it could appear above the view. I used the OnClick JavaScript option because what I needed to do was simple and I didn’t want the overhead of an s-Control getting invoked. That solves requirement #1.

Requirement #2 could be solved by having the button use 2 lines of JavaScript to pass the parameters to the PHP page.

idArray = {!GETRECORDIDS($ObjectType.Account)};

window.open(”https://www.mydomain.com/script.php?session={!API.Session_ID}
&server={!API.Partner_Server_URL_90}&idArray=”+idArray);

This got the job done, but violates requirement #3, which is to keep the data sent to the page hidden from view.

To meet requirement #3, I had to use JavaScript to dynamically build an HTML form on the fly, add data to it and then submit it.

// create the form. Set it up to POST the transaction
f = document.createElement(”form”);
f.action=”https://www.mydomain.com/script.php”;
f.method = “post”;
f.target = “_blank”;

// add the session id as a parameter
i = document.createElement(”input”);
i.id = “session”;
i.name = “session”;
i.type = “hidden”;
i.value = “{!API.Session_ID}”;
f.appendChild(i);

// add the server location as a parameter
i = document.createElement(”input”);
i.id = “server”;
i.name = “server”;
i.type = “hidden”;
i.value = “{!API.Partner_Server_URL_90}”;
f.appendChild(i);

// Get the Account IDs that were checked
idArray = {!GETRECORDIDS($ObjectType.Account)};

// add the idArray as a parameter
i = document.createElement(”input”);
i.id = “idArray”;
i.name = “idArray”;
i.type = “hidden”;
i.value = idArray;
f.appendChild(i);

// add the form to the document.
document.body.appendChild(f);

// submit the form
f.submit();

This solution worked perfectly. The end result was that the PHP page the form posted to was able to retrieve the Salesforce session Id, endpoint location and an array of Id values via the $_POST variable and none of those parameters were visible in the URL. The PHP was opened in a new window, which was defined in the f.target = “_blank”; line above.

I don’t know if there’s an easier way to do this or not (comments are welcome), but this turned out to be very easy and is an approach I will re-use. The hardest part was trying to figure out the JavaScript syntax.

This is a nice trick for non-Salesforce JavaScript development too.

Nice work, Steve.