A Business Use Case for Batch Apex
I want to share a recent real-world use case where Batch Apex was used to achieve our goal. If you’re not familiar with Batch Apex you can find more here in the Salesforce Development Docs.
Business Use Case
An organization’s sales team is using Salesforce CRM primarily to manage their Leads, Contacts, and opportunities. This is akin to a retail setting whereby there are multiple physical locations and each location has its own sales team and sales manager (think car dealership). In this setting, Leads (and/or Contacts) enter through multiple channels such as internet marketing, phone calls, walking through the front door, etc and are assigned to a sales rep based on a round-robin format. That sales rep becomes the owner of the Lead, but only has protection for a certain period of time before the Lead is redistributed. The protected period of time is based on the sales rep’s last activity to the Lead/Contact. In other words, if the rep is not actively working the Lead/Contact then they lose protection, and if that Lead/Contact ends up buying a product then the rep will not be credited for the commission.
The question then became, how can we automate this process of removing Lead protection based on the sales rep’s activity? One of the great features of working with the Force.com platform is that there are always multiple ways to solve these types of problems. And these are good problems to solve because the solutions free up people’s time and help advance business. In this situation, the basic design for this scenario is that when the number of days since the last activity is greater than 5 days, revert the ownership of the Lead/Contact from the sales rep to the sales manager. This lets the sales manager redistribute the Lead/Contact to another sales rep.
Make It Happen
The first step was to create a new formula field that returns a Number and call it Days_Since_ Last_Activity. The formula is this: Today() – LastActivityDate. At this point, you might think about creating a Workflow Rule that says when Days_Since_Last_Activity is greater or equal to 5 then Update the Owner field. However, a Workflow Rule is only fired under three circumstances: a)Only when a record is created; b) Every time a record is created or edited or; c) When a record is edited and did not previously meet the criteria. This means that the workflow rule won’t get fired until the record gets edited, and we want the ownership to change immediately upon the passing of the protected period regardless of whether or not someone edits the record.
The solution in this case is to use Batch Apex to query the database for all Leads/Contacts (we use Contacts in the example code) that have crossed the protected period, i.e. the Days_Since_Last_Activity fields is greater than 5. Then, we reassign ownership to the correct sales manager based on which physical location this Contact is associated with. Next, we create a new Task associated with this Contact so that the Days_Since_Last_Activity gets reset. Lastly, we schedule this Batch Apex to run each night so that the ownership is being recalculated on a daily basis.
Below are the Apex and Test Classes that make this work.
Ever send SMS messages to your Contacts and Leads?
I recently had a conversation with a fairly new Salesforce customer who wanted to send SMS messages to their leads and contacts. They had been using another CRM system that gave them this ability and it’s an integral part of the way they communicate with leads and prospects. The great thing about Salesforce and the Force.com platform is that there are multiple ways to achieve this goal. A quick search of the AppExchange will bring up a number of options. Or, if one of these options doesn’t fit your needs you could build it on your own. With my curiosity peaked, I chose the latter option and decided to spend some time looking for a way to build this functionality myself. Below, I’ll share with you the process and code that I put together.
Force.com Email Services is a great tool. Sometimes called Email-to-Apex, it allows for the ability to create an email address within Salesforce that can kick off and process Apex code. Setting up the email service address is quite simple; an overview can be found here on how to set it up. There are a number of security and functionality options that can be handled declaratively, for example:
- Whitelisting of email addresses (or domains) that the email address accepts from.
- Handling of attachments
- Failure/Error handling
- Selection of a context user that’s associated with the email address and Apex Class
I want to share one particular use case where the email service was really handy; it’s a customized Email-to-Case situation. While the standard email-to-case functionality within Salesforce makes it easy to create cases from incoming emails, all point-and-click which is great, it obviously lacks some abilities.
This example is a bit unique in that the organization’s parent company captured information from a form on their website and forwarded it via an email. There are only two types of emails being sent to this address, so the subject lines and the exact format of the text emails were known in advance. Let’s say the emails look like this…
Hi, you have received this email from your parent company. The following person has created a case. Name: Joe Test Role: Owner Email: joetest@joetest.com Phone: 555-555-5555 City: Anytown Region: Georgia Country: USA What seems to be the problem? "This is where Joe would write his problem."
The requirements in this situation were a) the ability to parse the emails for contact info; b) the ability to create a new contact if this was not someone currently in the database; c) to relate the new contact to a specific catch-all account; and d) to create a case (and populate fields in the case), then relate the case to the contact.
Below is the example code for creating this email service. Names have been changed to protect the innocent:
In the last post, I wrote about the importance of having a client designate the right internal project manager for the SFDC implementation project. Staying with the theme of sharing Salesforce.com implementation and consulting best practices I’ll share some thoughts today on documenting a clients’ extant business processes.
Let’s assume that we have an understanding of the client’s basic requirements, so for example we know that the sales team will be the user base and we know that their current tools consist of an on-premise database (or ACT!, Goldmine, etc), Outlook, and spreadsheets. What’s the next step that we really need to delve into? Right. We need to understand how these tools are currently being used and what the current sales process is – from start to finish. The best way to do this is to talk with people. And by people I don’t mean just the management or executive teams. You need to talk with the individual sales people and ideally anyone who the customer comes into contact with throughout the sales process, and even the folks who the sales people need to interact with through the process. You’ll certainly want to talk with the sales managers and/or sales execs, and they’ll most likely facilitate your meetings with the sales team, but don’t stop there.
Quite frankly there is often a disconnect between the way things are supposed to flow (according to management) and the way things actually flow (according to sales reps). If end-user adoption is a major factor in a successful CRM implementation (which it is) then a solution must be designed only after having a full understanding of how things “actually” happen in the sales process.
For the above example, here are a few key steps. We’re using the example of a sales team here but this could certainly be applied to most business units:
1. Conduct individual meetings with each member of the sales team. I’d suggest setting these meetings up in an interview format in which you have a pre-defined set of questions to cover. Set the expectation ahead of time that the meeting will take about X number of minutes and what the general topic will be. Be clear with each person as to why you are there and the reasoning behind the questions. You want to get honest answers as to what the true process is, and it’s not that most people are liars but there may be a fear that any information they give you will be held against them. This is common in organizations. Recap your understanding of the process to each person you speak with prior to exiting the meeting and have them verify that your description is accurate and complete.
There are a lot of great blogs out there that focus on Salesforce.com. I know this because I actively read many of them. Most are written with a focus on development and administration, with technical code sharing and feature explanations. This type of information is certainly a great benefit to me and many others and I’ve personally learned a tremendous amount from the development community and will continue to do so. But what about the “softer” side of Salesforce consulting?
Anyone who has experience working directly with clients knows that it’s not always about the technology. Having a well-architected solution certainly may include the need for significant customization, or advanced VisualForce and Apex programming, or external system integration, but in my opinion most CRM implementations don’t live and die by the technology – they live and die by the client organziations’ ability to adopt it. And this has a lot less to do with the technology side of things than people often believe. It has a lot more to do with how the system is internally implemented and managed, and this can be tricky to deal with when you’re an external resource and you don’t actually work within the organization.
I decided that I will focus the next few posts on these issues that deal more with organizational behavior than they do with Salesforce technicalities. The following is based on my experience.
Tip #1 – Your Client Needs to Designate an Internal Project Manager for the Implementation
This is ground-breaking, right? Earth-shattering? Utterly profound? I know what you’re thinking. In reality, though, this is much easier said than done and quite often it isn’t said…or done.