Posts tagged ‘automagic’

January 10, 2014

Small but Mighty


OK, so maybe a small group of citizens doesn’t apply here. But what about a small group of fields? Oh perhaps even just one simple field.

This is a field that I’ve added to many orgs that I’ve worked with, and shared with even more admins who have added it to theirs as well. It’s a field that several Salesforce MVPs have their own twist on. A field that when I tell folks about it, I get some pretty amazing reactions, especially for companies that have high-touch processes. And I can’t believe that it took me 4 years of working with Salesforce before I thought to make this field – and once you hear it, I bet that you will think that same thing.

So what’s the field? A time-zone formula field for Leads, Contacts and Accounts (and really, any other object you what to throw it on). Now you want the formula, right?

read more »

July 26, 2013

Don’t go on autopilot

With all my raving on the automagic in, the title of this post may cause you to do a double-take. But I assure you, dear reader, that I am completely serious when I tell you not to go on autopilot. Perhaps a bit of an explanation is necessary.

AutopilotAs Salesforce admins, we have a bevy of tools at our disposal for making Salesforce appear to have that automagic. We can use workflow rules to make fields update, emails gets sent or tasks get assigned. We can leverage triggers to create new records, sum values of non-detail objects or update multiple records. We can use schedules to deliver reports & dashboards to an executives inbox. And with the new Chatter Actions, you can extend that automagic even further. And all of that is great & fantastic, and I am in no way advocating that you stop doing it. In fact, do LOTS of it!

read more »

April 20, 2012

Enter -title- here

This week brings another “how to” post from yours truly. One hot topic that sales and marketing folks seem to always struggle with is lead and contact segmentation. Over the course of my Salesforce career, I’ve tried a couple different attempts as how to best segment contacts and leads based on title.  Neither are perfect, but I don’t think segmentation ever is. (People don’t like to be in buckets!) Hopefully they will give you some value, or at least provide insight into a different way of doing your segmentation.

More input

The first approach was to increase data collection by added two new picklist fields – one for department and a second for job level. The department field contained values for the typical departments we would sell to, as well as some more general catch-all categories to handle other titles. The job level field contained a range from C-Level to Staff. This allowed us to be able to target the c-suite executive for specific campaigns.


In this instance, we weren’t concerned with department as much as job level, so I decided to use a formula field to help calculate the level value. This field remained a work-in-progress and we added values to it as we thought of more options. My original formula is shown below.

IF(CONTAINS(“VP:AVP:Vice:V.P.”, Title), “VP”,
IF(CONTAINS(“Manager:MGR:Mgr”, Title), “Manager”,
IF(CONTAINS(“Supervisor”, Title), “Supervisor”,
IF(CONTAINS(“Analyst”, Title), “Analyst”, “Staff”))))))

Now, these won’t be the magic bullet for most organizations. But perhaps you can think about your segmentation in a new way to help your sales and marketing teams target the right folks. What are some other segmentation methods you’ve tried?

June 24, 2011

What’s your flavor?

Looking at the landscape of Salesforce admins, there are really three flavors – the newbie admin, the ‘button-click’ admin & the super-coder admin.

  • Newbie Admins – These are admins at small companies, or companies that are new to Salesforce. Usually administering Salesforce isn’t their only job duty, but most are eager to learn & get super excited about how *cool* Salesforce is.
  • Button-Clickers – These are the seasoned admins who wield all the declarative power available to them with the platform. Typically, they’ve been using Salesforce for a few years & probably even have a certification or two. They are the auto-magicians of Salesforce.
  • Super-Coders – People who fall into this category usually have a technical coding/development/computer science background.  They dream in SQL and SOQL. They know the difference between an object and an sObject. They use phrases like ‘standard controller’, ‘instantiate’ and ‘system-dot-assert.’

The problem that I think a lot of us ‘button-clickers’ run into is how the heck do we make the move to the next level. Fairly recently, Salesforce started offering the DEV 531 course (which you already know that I’m a huge fan of), and that’s a step in the right direction for enabling admins to progress. But a 5 day course isn’t going to get you all the way there.

Enough with the rambling – what’s your point, Becka? My vision for this blog is to really target that need. I’ve already started with a few of my posts, but I really hope to continue that vision & really flush it out. I’m only baby steps into this journey, but I invite you to join me.

(While joining me in the journey, why not also join me on Facebook!)

May 27, 2011

An elegant solution

While we all have different titles, what this Salesforce admin/developer job really entails is “Problem Solver.” Some of the solutions are slick & cool, others are a bit messy but get the job done. Usually the person with the problem doesn’t really care so much how it gets fixed, so I was surprised the other day when someone commented on how elegant my solution was. To me, it was fairly basic stuff, but the more I thought about it, I realized that it was something pretty clever that I had come up with.

What exactly did I do? I should start with the business problem. Without going into too much detail, we have leads assigned to a queue & the business wanted a sales rep to actively accept or reject the lead before working it, and also capture some key data points at the time of acceptance or rejection.

Now, the fun part – how I solved the problem. I created a new record type, and made it the default. I create a page layout with only key fields displayed & the only buttons that exist are the ‘Accept’ and ‘Reject’ buttons. “What are the ‘Accept’ and ‘Reject’ buttons?“, you may be asking. Pretty simple – a clone of the “Edit” button, except the are passing a value into a field on the record. This passing of a value allowed my to write validation rules to conditionally require data based on whether the lead was accepted or rejected.

So far, pretty cool, but nothing amazing. But wait! There’s more! Once the user is done editing the record & hits “Save”, a workflow rule fires (based off the accept/reject field containing a value) and a field update occurs. Still pretty simple, right? Well, the slick part comes in that the field that gets updated is the Lead Record Type. (Ta-daaaaaa!) The record saves & then the user is presented with the standard lead layout with all the fields, related lists, and other bells & whistles they were used to having.

Magic transformation – all in a day’s work for a salesforce admin!

%d bloggers like this: