Blog

Lets start off by saying that Lead Conversion is fantastic. It’s a core feature that makes Salesforce.com’s Sales Cloud a leader in Sales Force Automation. The ability to take one single record and split it logically into three is extremely powerful. Just think about all that information collected on a Lead that then gets converted into an Account, Contact, and optionally an Opportunity. To me it’s a very logical way to categorize and segment a sales cycle. A quick overview of Lead Conversion for those that don’t use Leads:

• Create a Lead record in Salesforce which comprises of Person data such as Name, Email, Phone; Account data such as Company, Website, Address; and optionally create Opportunity data such as Source, as well as the Company and Person the Opportunity is for

• Click on the Convert button in order to take data from the single Lead record and “push” it into newly created Account, Contact, and Opportunity records

• Optionally create a Task that relates itself to the Opportunity for next steps

Seems simple enough right? Create a record and convert it into three records. There are however some nuances that are what I would call limitations in the flow of Conversion. Here are some of my bugaboos with Lead Conversion and some Ideas for how to solve some of them.

Record Type Selection Upon Conversion

Very often a User can select more than one record type per object they are creating. For example a User may be able to create multiple types of Opportunities based on a specific sales process. When converting a Lead the Opportunity that gets created is defaulted to the one that is specified as the default on the User’s assigned profile. I covered this topic in my Record Type blog post a few months back. It’s one of my main issues with the way that record types are assigned via profile and the way that conversion doesn’t really care which record type you want to create, it’s just going to take the default. I think this Idea on the Idea Exchange covers a way to handle this very issue in a very simple way. To boil it down, provide a way to define the default record type for the newly created Account, Contact, and Opportunity based on the record type of the Lead.

A workaround that you may want to try is to setup a field on the Lead for the record type you want to create for each object. Then upon conversion map that field that you created on the Lead to a corresponding field on the Account, Contact, and Opportunity then have workflow rules fire to change the record type accordingly. This is a workaround for sure but it should work just fine if users understand the ramifications of filling out these fields vs. leaving them blank. This brings me into my next topic, mapping of fields.

Map Lead Fields to Multiple Objects

As I described above, when you convert a lead you are taking data from that one record and creating three. The way this works is through mapping fields to one another. You click the button on the Lead fields page to Map Fields and then you can map Lead fields to any of the three objects you are going to create. While this is an amazing feature one of the main drawbacks is that you can only map a single field to another single field on one object only. An example would be a custom field called Lead Referrer. This could be a field that tells us who referred the Lead and I would want to map it to both the Account and the Contact but alas I have to pick one and only one. This Idea on the IdeaExchange doesn’t quite offer up a solution but does summarize the problem.

While reading through the comments of the above referenced Idea you’ll notice that people do offer some workarounds using cross-object formula fields to get data from the Account down to either the Contact or Opportunity but that’s just extra work. In addition, you’ll also notice in the comments that a similar Idea would be to allow for mapping of standard Salesforce.com fields. Currently you can only map custom fields, the standard fields map to where they map to, you have no choice in the matter.

I’m sure there are many more Ideas and bugaboos out there that people have with Lead Conversion. Again, I just want to reiterate, I think it’s a great feature, it just needs some love at the core product level to make it that much better.

Feel free to comment below in Disqus, on our Facebook page, or tweet with me directly at @JustEdelstein.

Custom Button Concept

While it has been a trick of the elusive Salesforce Administrator for a long while, the custom button can be used in a lot of business cases. It can do everything from being the one click link between two objects to as complicated as pre-populating a lot of fields on a new record on a different object. Mastering the custom button can help administrators cut down on complaints and help users get their work done faster with less fields to fill out.

For this blog post series I am going to be using a very fictional example of creating a new project from an existing closed won opportunity. The business use case is once an opportunity has been closed won, the project manager needs to create the project which is a totally different object, but has a lot of the same fields as the opportunity such as name, start date and description.

Knowing Your URLs

The first thing you need to know to master your custom buttons is the URLs for creating new records. To figure out what they are just click a new button from anywhere in Salesforce and you can take a look the URL in the browser and for whatever comes after salesforce.com. You can copy that url, open a new window and test it by putting in the URL bar and hitting return. It should bring you, button-less, to that new form page. For objects with record types you will have to choose your record type first to get the full link and note the “RecordType=” as the ID of the record type for your new custom button.

In the screenshot below you can see I have referenced the object /a0A/ and the create new form “e” and am referencing a Record Type.

That, was the easy part.

Passing Parameters

Ready to get into a little HTML? Good, because that is the way to figuring out which parameters you need to pass in the URL string. On the new form page in a modern day browser (Safari/Chrome) you can right click in the form element you want to inspect and choose “Inspect Element” which will bring up a new window with all the glorious Salesforce HTML. You are looking for the form element which usually starts with “input” (in screenshot below).

For the Name of the project below, we are looking for the “Name” id and simply add that to the URL string after another ampersand and test it by hitting the return button. If everything goes well, the name of our new project should be filled out in the Project Name Field.

Easy right?

Create Your Button

Now that you have the url and parameter you are going to pass between objects it is time to go create that first button. Back on the source object, in this case the Opportunity, in setup create a new Detail Page Button, give it a name, choose your behavior and then paste the URL into the button field. Using the Insert Field widget and add the source field parameter, in this case Opportunity Name, after the equal sign. This is telling the button to pass the Opportunity Name into the form in the Name of the new project.

Save the button, add it to the page layout and test away. You might want to play with the window behavior depending on the business case.

In Part 2 we will come back and discuss how to do complex things like populating lookup fields and in the meantime you leave comments below or hit me up on Twitter @JasonMAtwood

Summer is approaching and with that we can expect some exciting new features and functions that Salesforce.com will be offering as part of their Summer ‘13 Release.

For all of us Sales Cloud lovers, Salesforce stayed true to the core and added some nice time saving and overdue enhancements to Opportunities. As done for Spring ‘13,  here are three features from Summer ‘13 every sales team should be excited about and why.

Opportunity Splits

The ability to split credit for Opportunities has been a request for quite some time and with Summer ‘13 you finally get it.  There will be two types, “Revenue Splits”  which provides credit to team members who are directly responsible for revenue that an opportunity creates and “Overlay Splits” which provides credit to team members who work on an Opportunity but are not directly responsible for generated revenue.  The Revenue Splits must total 100% of the Opportunity amount but the Overlay Splits do not.  This feature is great and will roll individual sales credits into quotas and pipeline reports without the need to create duplicate Opportunities which is a nice time saver.

Activity Enhancements

There are a few small enhancements to Activities that I thought were worth mentioning. Previously, the limit on Contacts associated to shared activities was 10 but with this release they get a bump to 50 which helps with Activity accuracy. Email to Salesforce got a nice boost piggybacking off of the previously mentioned bump in the number of Contacts related to a shared Activity. Previously email to salesforce would create a separate email task record for each contact in an email but now with Shared Activities being enabled, it will relate up to 50 contacts to an email task record.  This enhancement helps users get a more clear and accurate view of their historical Activities.Lastly, to go along with the Shared Activities theme, all reports will now show all Contacts related to the activity instead of just the primary contact.

Customizable Price Books

Keeping up with the love for Salesforce core functionality, Summer ‘13 offers customizable Price Books.  Previous to this release, business groups could have their own price book but no ability to customize them for their specific needs.  With Summer 13, custom fields can be created along with page layouts and record types to give each group this flexibility. Users can also now easily see their price lists through the new Price Books tab.An example use case would be a company that has seasonal price books. By creating a custom date field users can specify the start and end dates during which the price book is active. Price Books are looking more like a first class object by the second! Additionally, to save a step in the archiving process, Salesforce created a new Archive button that now quickly archives the price book without directing you to an error page that it did previously.

There are many enhancements in Summer ‘13 and I would recommend you take a look at our rapid reaction blog as well as skim through the release notes to see if anything else catches your attention.   Hopefully these few got you as excited as they got me.  If you would like to discuss further tweet at me at www.twitter.com/Salvatoriello or comment below.

It should come as no surprise to anyone that we here at Arkus are a big fan of Permission Sets. Not only did some of us have something to do with their birth at Salesforce but we built a free tool to manage their assignment in mass called The Permissioner. Now that I have that shameless plug out of the way, let’s get into some new Permission Sets in the Summer 13 release that are worth a second look.

Record Types

While it was mentioned in the blog post by @JustEdelstein last week, it can do no harm to mention such a great feature again. New in the Summer 13 is the ability to use Permission Sets to control access to create Record Types. The use cases for this are almost limitless so go back and re-read the release notes section which deep dives into the how.

Allow Email Based Identity

On the security front Salesforce is rolling out SMS Identity Confirmation for all users with verified mobile phones. This replaces the email based identity confirmation for users who enable it. If your users are not connected by mobile phones or that isn’t a good option you might want to assign the “Allow email-based identity confirmation” Permission Set to your users to let them continue to stay on email. This might also be used as a way to allow you some time to figure out how to roll out the SMS based identity.

Salesforce Touch

While Salesforce Touch went GA prior to the Summer 13 release this is a good time to remind everyone about the features and what it means for you Permission Set junkies. Salesforce Touch is a new mobile view of Salesforce based in HTML5 allowing for easier navigation and manipulation of data. While you still login to Salesforce it looks much different with features like swiping and overlays that work better on mobile devices. Aside from all the new features in Salesforce Touch it should be known that it uses the same security settings of profiles and Permission Sets. This means that any assigned Permission Sets around things like Record Types will be inherited by Touch. A little bit of “Can’t Touch This” just got easier.

Community Membership

One of the jaw dropping new features coming in Summer 13 are Salesforce Communities which could be easily described as Portals 2.0. They are based in the Chatter suite of features and will allow for external users to collaborate with internal users in a branded workspace. While we have not gone hands on with Communities yet, we do know that the release notes for them are littered with mentions of Permission Sets. Out of the box Communities give access based on profile, which is not very granular so Salesforce highly recommends using Permissions Sets to grant access to newly formed communities at the user level. I wonder how you could assign a whole bunch of users the same community Permission Set at the same time?

If you know and love Permission Sets hopefully these new ways to use them in Summer 13 will be helpful. If you have never heard of them before, dive into our blog archive here and read up on them.

Are you a Permission Set junkie or just love The Permissioner too much to handle? Leave some comments below or hit us up on Facebook or @JasonMAtwood

• Direct Download (Time: 44:44 - 21.5 MB)
• CloudFocus RSS Feed
• Subscribe via iTunes

CloudFocus App Pick of the Week

• CrowdGuide by TrainTheCrowd from Justin
• Instacast for Mac by Vemedio from Jason

Follow Us

It’s that time of the year once again where we Salesforce geeks get to dig in and read some release notes. This time around for Summer 13 we got delighted with 264 pages worth of Salesforce goodness. Here are a few of my favorite features as well as a few that are extremely impactful in the ecosystem that is Force.com.

Chatter Communities

I can’t think of a more impactful feature going GA since Chatter itself. Chatter Communities are taking over so get used to it. Gone are the Customer and Partner portals and in come Chatter Communities. They are front ended by Sites.com website technologies and are going to be the way that organizations connect with their customers and partners using Salesforce.com for the foreseeable future. I’m personally sad to see Partner Portal and Customer Portal go away (don’t worry for those who already use these portals, you can continue to use them) though the complexity of pricing and options for which portal to choose will hopefully get better this time around with Communities. It appears as though there will be two different types of Communities - one for Partners and one for Customers (sound familiar) with each being accessible by any “internal” Salesforce licensed user. Each will have their own set of permissions outlined in the table below.

Communities are really a culmination of all the work being done on Chatter and a great way of bringing outside users into the Chatter fold without the use of Customer Groups (which I am not a fan of). Aside from allowing external people access to collaborate within Chatter, they can also participate in business processes such as customer service and sales. This truly is the start of seeing the Customer Company vision become a reality.

Publisher Actions

When Marc Benioff makes a statement to the effect of Chatter being the new user interface for Salesforce he isn’t kidding. With publisher actions we are finally seeing what working directly in the Chatter Feed really means. The best example or use case for explaining this feature is using Accounts. From an Account feed a user would be able to create related records such as Contacts or Opportunities. Publisher actions also respect validation rules and required fields unlike the dreaded quick create menu. Administrators can modify and customize which Publisher Actions are available to users and can even embed Visualforce pages to do even more advanced creation of related records.

With Publisher actions also comes the ability to see Chatter from children records. Using the Account example again we would be able to see Chatter on any related Opportunities directly from the Account Chatter Feed. As a clarification point here, in order to see the Chatter on the related Opportunities you must be following the Opportunities; still a very nice time saver and a way to see a wholistic view from a single record.

Opportunity Splits

As I recall I saw this on a stage about three years ago at an event in New York. This is the main reason for the ever famous Safe Harbor Statement, Salesforce is serious when they talk about something maybe not being delivered for a while. Though it’s been a while it’s a welcome feature for those sales organizations that need to split Opportunities amongst team members at a revenue or a quantity level. I’m excited to see core features such as this make it’s way onto the platform, particularly since it was worth demoing to a large audience three years ago.

Record Types in Permission Sets

Finally my idea has been marked as coming in the next release. I’ve been clamoring for the ability to assign record type selection at a Permission Set level for a while now so that I can assign users in different profiles the ability to create certain record types. Imagine a Call Center with reps, engineers, managers, and executives all needing their own profile simply because of the types of Cases they need to be able to create. This problem no longer exists - Permission Sets to the rescue - just assign the appropriate Permission Set to different users to indicate that they can create a certain record type of Case. I love when product managers deliver on ideas from the community. Shout out to Adam Torman! Also a shameless plug for The Permissioner which makes assigning and revoking your permissions sets in mass extremely easy and efficient.

Owner Fields in Custom Formulas

Raise your hand if you’ve had to write a trigger to copy the owner of a record into a User lookup field on the same object. Ok, put your hand down and keep reading. I know we’ve had to write this trigger many times for the simple reason of getting the owner’s first name, last name, or email address into a formula field on the object. This trigger can go by the wayside as we can now just use the owner field to bring over any information that exists on the User record. Button Click admins across the world just got a nice tasty treat with this feature.

Approval Process Deployment

Last but not least is the ability to use cloud deploy to migrate approval processes from sandbox to production. For far too long this feature has been missing and I’m glad to see it make it into this release. Every time we build approval processes we have to build them in a sandbox to test them and then have to go through the task of rebuilding them in production. This made no sense (and still doesn’t make sense to me) as workflow rules were able to be migrated from sandbox to production. This is another core feature that is being delivered and I couldn’t be more happy about it as someone who just had to build then rebuild eight approval processes with multiple steps in each one.

This release is jam packed to the brim with not only cool new features like Chatter Communities and Publisher Actions but also some very key core concepts and features like pushing approvals and Opportunity Splits. This is the way all Salesforce releases should be moving forward - address visionary concepts and forward thinking functionality while also continuing to strengthen the core of an already world class platform.

Feel free to comment below in Disqus, on our Facebook page, or tweet with me directly at @JustEdelstein.