Reporting on “Created by lead convert”

No, this is not another story about how it is “better to do something the hard way” – puhleeze, we all know that’s a myth. Ever do something the hard way unnecessarily, then discover afterward that there was a much easier way? Of course you have. We all have. This is one of those stories.

“How many of our accounts were created by converting a lead?” This sounded like a simple, straightforward request. So, feeling pretty darn smart because I knew how to get converted lead info – including the account IDs – off to Workbench I went.

Now, I’m not knocking Workbench – it’s one of my favorite admin resources! In a Workbench SOQL query, I can export converted lead IDs, plus the IDs of accounts, contacts, and opportunities that were created upon lead conversion. (And for more Workbench tricks, check out this blog post!)

My Workbench query yielded some great information. But it also required some Excel trickery, because although it provided the ever-useful ConvertedAccountId, some of those IDs appeared multiple times in the list – it will not differentiate between a lead converted to a new account vs. a lead converted into an existing account. So I had to go through and remove all duplicate ConvertedAccountId values.

In addition, all I could send to the person who requested this information was a number. I could also have attached the spreadsheet, but what if they wanted this information again in the future? I’d have to go through the same manual process again.

And then, guess what I found… an easy way to get that same info. And when I say “easy” I really mean “so easy that it blew my mind.” Here’s how:

  • Create a new report using the Account History report type.
  • Add the report filter Field / Event equals Created by lead convert.
  • Set a date range if you want a specific time period, or leave the dates blank to show the total number of accounts that were created by converting a lead.

Now I have a report that anyone can run in real time to get that total. How cool is that? Honestly, I’m a little embarrassed that I had no clue that an account history report contained that handy little trick. But better late than never – this is going to be extremely useful!

A couple of bonus things that I learned while playing with these reports:

  • You can also use this trick in a Contact History report or an Opportunity Field History report.
  • You can use two filters, if you want to compare records created via lead convert vs. records created manually – just use the filter Field / Event equals Created by lead convert, Created., and turn your report into a summary report grouped by Field / Event. (Make sure to add a period after “Created” or it will not return those records.)

And I just wouldn’t be myself if I didn’t give you some disclaimers:

  • If field history tracking is not enabled for the object in question, you cannot run a history report.
  • The data returned in your report will only go back to when your org began tracking – so if field history tracking has not been utilized since your org was first set up, you may be missing some records (depending on how far you want to go back).


Salesforce Limits Got You Down?

I hate limits. Speed limits. Cellular data limits. Insurance coverage maximums. Credit card limits. And don’t even get me started on those pesky Salesforce governor limits!

In the ten years I’ve been a Salesforce admin, I have run into almost every limit that exists in a Salesforce org. The frustration is the same every time. But over time, I’ve also discovered that many of those limits are negotiable – and all you have to do is ask!

Here are my favorite not-really-limits, which you can potentially increase by submitting a case to Salesforce support. Click on the links for more details, such as how to request the increase, and things to consider beforehand. Enjoy!

Workflow rules per object: Do you love workflow rules? Do you love them so much that you’ve reached the limit on your most popular objects? No worries – you can raise that limit from 50 rules per object to up to 300!

Roll-up summary fields: This limit increase once saved me during a particularly rollup-heavy project. Back in the old days – well really, it was just back before the Winter ‘16 release – the maximum for rollup summary fields was ten – can you even imagine?? In Winter ‘16, it was raised to 25 – but you can still get that limit to up to 40. (Note: you cannot raise this limit on just one object – any increase will apply to all objects.)

Dashboard filter options: Dashboard filters rock! Unless you need more than 10 of them. But wait – there is hope! You can have the limit on dashboard filters raised from 10 filters to up to 50.

Sharing rules per org: If you’re a security watchdog like me, you’ve probably built out a ton of sharing rules. What to do when you reach the limit of 300? Why, reach out to Salesforce support, of course! They can increase that limit from 300 to up to 500 sharing rules. (Note: this refers to the limit on total sharing rules. There are currently no increase options for the limit of 50 criteria-based sharing rules per object – but you can vote up that idea here.)

Archive Days for Activities: Salesforce archives certain events and tasks on a weekly basis – click here for the archive criteria – and the default setting for the age of these activities is 365 days. But you can have that limit raised to up to 2555 days! (Note: Salesforce recommends a maximum of 1825 days to avoid performance issues.)

Recycle Bin Retention: Ever try to locate what you thought was a recently deleted record, only to find that it has already been purged from your org’s Recycle Bin? Can you believe you only have 15 days to undelete a record? Well, not anymore! This limit can be doubled to a Recycle Bin retention period of 30 days. Huzzah! 30 days to dig through the trash looking for user-deleted records!

Things to consider:

  • Salesforce does not just assign limits arbitrarily – they are in place to keep things running smoothly (as are all of the limits I mentioned at the start of this post). Before you request any limit increase, make sure you have tried all other options. Example: if you have access to a developer, consider populating number/currency fields with Apex code, rather than maxing out your roll-up summary field limits.
  • Keep in mind that increasing too many limits can severely affect system performance, and it may take longer to view/save records, run reports, etc. Is performance degradation something you are willing to tolerate in exchange for a limit increase? It’s a tough trade-off. Be ready to hear complaints from your users, and explain the situation to them.
  • Salesforce support requires that you supply a business reason when you request a limit increase. Based on your business need, they will decide whether or not to allow the increase – it is not guaranteed!

Curious to find out what else Salesforce support can enable for you? Check out this far-more-complete document – put together by the amazing Meighan Brodkey – for a comprehensive list of every feature that can be enabled.

Bonus: check out the only Limits I actually like!!

Validation Checkbox: One little Field = One Big Win

We all want our users to be happy, right?

Sure, we may occasionally threaten to give them a read-only profile or lock them out altogether… but in all seriousness, ease of use is crucial if you want any kind of user adoption. And while you can’t just say yes to every single request that comes your way, it’s not hard to find a quick win here and there that will make things easier for your users. This post is about one of those wins.

I don’t know about you, but every org I have ever worked in has had multiple validation rules around setting opportunities to Closed Won. Here is a sample set of some common opportunity validation rules:

Now, put yourself in the shoes of a brand new sales user who is not yet familiar with the process and all of its rules. Imagine the frustration when this new sales rep tries to close an opportunity, but is immediately hit with a stack of errors like this:

To admins, those errors all make sense. We built them. We know how they work. But our users hate those big red errors more than anything! I’ve lost count of how many people have complained about my validation rules – and I honestly can’t blame them. Too many errors at once can be confusing, overwhelming, and at the very least, annoying.

From the point of view of a sales user… instead of closing your opportunity and just crossing your fingers and hoping that it will save without any errors, wouldn’t it be nice if you had an indicator that told you it was actually ready to close? Something like this?

Admins – this is where you can make magic happen.

If you have a large group of validation rules that are all based on a common criteria – in this example, setting an opportunity to Closed Won – you can save your users from all those errors with one simple checkbox!

First, start by creating a formula checkbox field. Then, combine all of your validation rules into a formula that will return a value of true if the record meets all validation criteria. Here is the field I created to replace the validation rules listed above:

Important: don’t forget to put specific details in the field’s help text! You don’t want to tell a user that their opportunity is no good, and then not explain why.

Once you’ve got a validation checkbox in place, you can deactivate that list of validation rules! Here’s what I did:

  1. Carefully evaluated my existing validation rules (you’ll see that I had one rule that was based on Probability, not on the Stage being set to Closed Won – so I left that rule active.)

      2. Deactivated the validation rules that were included in my validation checkbox.

      3. Created a new validation rule using only the checkbox.

This is a win for admins as well as users, because you’ll have fewer validation rules to look at when you are troubleshooting validation errors in code, from mass updates, etc.

Bonus: You know that terribly vague “Unable to Submit for Approval: This record does not meet the entry criteria or initial submitters of any active approval processes” error? Well, your users never have to see it again. A validation checkbox is also a great way to let them know if a record is ready to submit for approval! (Or we can keep voting up this idea for the rest of our careers…)

What else would you use a validation checkbox for? Case closure? Quote validation? Lead ready-for-conversion?


Data Loader Gotchas

I love Data Loader.

Seriously, it is one of my favorite things. I remember my excitement when, as a baby admin, I downloaded Data Loader and discovered the magic of updating thousands, tens of thousands, hundreds of thousands of records at a time!

I also remember the intense frustration of my biggest Data Loader mistakes. There are so many settings and formatting quirks that are just too easy to miss! Here are my Top 10 Data Loader gotchas:

Batch size: You may want to adjust the batch size (found in Data Loader Settings) of an insert or update, based on how much automation and code your org has in place. If a lot of workflows, processes, and/or Apex code will be firing during your mass update, it’s a good idea to reduce the batch size to avoid getting too many errors. Whenever I get “record locked” or “Apex CPU” errors in my Data Loader error log, I reduce the batch size by half and reload the records that errored out. Pro tip: want a bigger batch size? Check the Bulk API box and you can update thousands of records per batch instead of hundreds.

Null values: This is a great feature with a big gotcha. If you want to insert null values into fields during your update, check the Insert Null Values box. It will delete any values in the fields that you’ve left blank in your upload file. Here’s the gotcha: that box stays checked until you uncheck it! Always take a look at your Data Loader Settings before you begin a upload, to see if you’ve left that box checked. Vote for this idea to get a warning when the box is checked.

Lead assignment: Many admins don’t know this, but you can run a set of leads through your lead assignment rules by entering the Assignment Rule ID into a box in the Data Loader Settings. Awesome, right? Sure… until you go back to do a lead update and accidentally reassign over 400,000 leads because you left that ID there. (In case you were wondering – yes, that is a true story!) Again, this is in your Data Loader Settings – always make sure the Assignment Rule setting is blank if you do not want to reassign leads while you are mass updating them.

Sandbox vs. production: Don’t forget to change the login URL when you switch from your production org to sandbox, and vice versa! Otherwise you will be slamming your head against the wall, wondering why your username and password aren’t working.

Security token: If you are using password authentication, don’t forget to add your security token at the end of your password. Pro tip: I have a folder in my inbox that is specifically for security token reset emails, because I have so many Salesforce orgs and sandboxes that I update with Data Loader.

Missing objects: Can’t find the object you are looking for in the object list? Check the Show all Salesforce objects box – it will expand the list to include objects such as Opportunity Product, Contact Role, Price Book Entry, and many more. Check out this great idea for a setting to default this box to be checked – and vote it up!

Date formatting: My least favorite mass uploads include date fields – or worse, date/time fields. Unfortunately, the super-detailed documentation that existed in the past has been stripped down to this semi-helpful article. But I did find this question in the Answers community that offers a great answer (including screen shots of the lost documentation) for both date fields and date/time fields. Note: this is for US-formatted dates.

Converted leads: I almost called this one “files that you get from other people” – because one of the biggest gotchas of all is bad data. And your users won’t always know the best way to export the data you need for a mass update (non-.csv-formatted files, no record IDs, etc.). But converted leads is one of the biggest causes of errors that I’ve ever had, so it gets its own place on the list. Make sure that when you export leads from a report, you’ve filtered out converted records. And if you got the file from another user – make sure that they did the same!

Validation rules: This one bites me in the backside almost every time I mass update records. In a perfect world, we would never create a validation rule without first going back and making all existing records meet the rule. Any of you live in that perfect world? Yeah, me neither. If you are updating old records, you may get a lot of validation rule errors – so make sure you’ve deactivated any rules that you think might be troublesome. Warning: don’t forget to turn those rules back on afterward! Vote for this idea to disable validation rules during Data Loader updates.

Email alerts: Do you have workflow rules or processes that send email alerts when records are created or updated, or when a specific field is changed? Make sure you are aware of any alerts that may be fired by your mass update, so that you can shut them off if necessary.

Whether you are an experienced admin or just starting out, these are easy mistakes for any of us to make! Watch out for the gotchas and your data loading will be much easier.

Bonus gotcha: Make sure you download the latest version of Data Loader (Setup | Data Management | Data Loader) before TLS 1.0 encryption is disabled in March!