Lessons Learned: Record Type IDs

Yeah. I forgot I started this series. I’m only human.

I remembered it when I was thinking about this story I’m about to share (names and places changed to protect the innocent), so here it is.

(BTW, I was inspired to write in this style by the creative work of my friends at Nerdforce!)

screen-shot-2017-01-17-at-4-20-31-pm

I’m a professional, see; I don’t configure big changes in Production. I do it in a sandbox, like the big shots.

The changes were easy – one record type that needed some minor adjusting. A field added here, another field removed, a picklist value added there. Some workflows. It was the kind of work that I had done hundreds of times before. I know how to write a formula, know about adding the picklist value to the record type.

The only hiccup? A validation rule that needed to fire for other record types but would’ve spelled bad news for users of this one.

But I’m not just any dame. I’m an Admin. I didn’t break the rule, but I bent it, making sure that my record type could slip in under the radar. I knew I wanted to be precise, so I added NOT(RecordTypeID = [long string of random numbers and letters]). It’s nothing I haven’t done before. It takes a lot more than record types to get under my skin nowadays.

And my client? Another satisfied customer.

After only two hours of work, I created my change set, pushed to production, and disappeared into the night.

Then things got quiet.

Too quiet.

Until my phone rang.

“Hello?”

“Admin! Thank Benioff! We’ve got a real problem brewing down here.”

“Oh, yeah, what’s that?”

“Well that record type, ya see, it’s workin’ great except that no one can save a record. There’s a problem. It’s flashing red, and it don’t look good, kid.”

Undeterred, I flipped open my trusty laptop, “Tell me what it’s saying.”

“It’s an error message. It wants us to give it a value in some field, but we ain’t got the picklist. It’s sayin’ it won’t give up the record without it. What are we gonna do?”

I had to think fast. I had tested that very validation rule. Playing it cool, I asked, “Are you getting this error every time?”

“No. We didn’t even know it knew about this record type. Should we just…give it what it wants?”

“Don’t do that. But give me a minute to think,” I assured the client.

Like the flash of a muzzle, the answer came to me. Yeah, I had done this before, but here I was, caught like a fly in the syrup. Like some two-bit beat admin with something to prove and nothing to back it up with.

The change set. I should have caught it sooner, should have known. It had been staring me in the face. But I had to make sure.

“Let me call you back,” I said.

I hung up and stared at the screen for a minute. So this was how I would be done in.

I opened the validation rule. There it was – that 18 digit code. 18 characters between me and solving this case. I knew the answer; I wasn’t stupid, but I had to look anyway. I opened the record type. Different ID. The switch had been made right under my nose.

I’m no fool, and no change set was gonna best me.

I copied that ID, replaced it in the validation rule and saved. Not about to look bad in front of my client, I tested the change. Purred like a kitty cat.

The ringing on the other end was shrill, like it was shouting the client’s concerns.

“Admin?”

“Yeah, it’s me,” I smirked, “and I solved the problem. You won’t be getting that error message again.”

I waited while they tested it, and I disappeared during the celebration. They would be fine, I knew.


So the moral of the story here should be pretty simple: don’t hardcode IDs in your formulas or validation rules in a sandbox. Because they will be different in production.

Understanding multi-tenant architecture (which I swear, I do!), it makes sense. You can’t have the same unique identifier in two separate orgs. That would create chaos. And a sandbox doesn’t get any special treatment.

So really, you have a few options here:

  1. Temporarily turn off the validation rule in sandbox and remember to update it in production.
  2. Make the change in sandbox and duplicate in production.
  3. Don’t use the ID – use the name. You can always change it later if need-be.
  4. Don’t ever use Record Types
  5. Don’t ever use Validation Ruls

Disclaimer: Numbers 4 and 5 are not actually options. 

Either way, something like this isn’t the end of the world. But it is definitely good to keep in mind, especially if pushing changes to production late at night or early in the morning when users are less likely to be active, but you’re caffeinated and raring to go.

Also…full disclosure: this has happened to me more than once. I hope that by sharing my story, I will actually keep myself from repeating my mistake.

Have you learned this same lesson? A similar one that involved using hard-coded IDs?

 

 

Lessons Learned: Hide, Don’t Delete

There are benefits to starting at level 0.

  1. There’s nowhere to go but up.
  2. No one has overblown expectations of what you can do.
  3. Learning something new is literally the best thing.
  4. No bad habits, all best practices.

This was how I started my Salesforce journey…just like everyone else.

I took over an instance that had been around a few years. I was excited and nervous. I started learning with Salesforce’s Premier Support Getting Started video and training series.

I learned all about naming conventions, org security, page layouts, Chatter, and all of the things we all know and love. I learned that duplicates were bad, too many fields was unnecessary, and that Chatter could help teams communicate cross-functionally. Can we just take a moment to appreciate how amazing Salesforce is, though, seriously?

Anyway. I was a little embarrassed. My org, the one I had just adopted and decided to raise as my own, was not house trained yet. I didn’t want people coming over, even though they already knew the org and weren’t really aware that it wasn’t in optimal condition.

I went on a little bit of a change spree. I documented my org, interviewed my users, ran some reports, and I decided to do some dusting. With a back hoe.

I took out so much stuff.

We had fields that hadn’t been used in ever. Page layouts that no one saw. Profiles whose contents had been emptied long ago. Role hierarchy?! They didn’t need no stinkin’ role hierarchy. (Just kidding. They did.)

I went in like a wrecking ball, and I started to lose track of some kind of important things. Namely my users. And data.

In my desire to makethingsbetterrightthissecond, I just started making changes. Sure, I knew that best practice was to use picklists instead of MSPs, but I missed some things along the way.

Such as hiding fields before you delete them.

As it turns out, sometimes fields are sparsely used because they’re only used on certain record types or in certain use cases. If you delete them, that data goes away.

For instance, if you have a field to track those people that need to be invited to a special client event every year, and that number is small – like only 50 people – it may seem like it’s almost never used. And technically that’s right. But it’s also sparse because it’s kind of a VIP indicator, and not everyone can be a VIP.

People were displeased when that field suddenly went missing.

I received emails and phone calls. I explained righteously that since the field had not been used, it clearly was not needed. Ah…I was incorrect.

Oops.

The next things I learned were how to restore records from the recycle bin, the location of our weekly data exports, and how to import data.

What I should have done

I’m not the first person to learn this lesson the hard way. I won’t be the last. But if I can help one person avoid it, I will consider myself successful.

Hide fields. Hide them. Remove the field from the page layout, take away Read access, whatever you have to do to hide it.

But don’t delete the field.

I know you want to clean your org. You should. It’s a good thing to do. But you have users to consider, not to mention your own time.

So when you’re digging through the muck, don’t throw everything out. Put it out of sight, out of mind. Your users will let you know if you took away something important. Trust me, they will let you know.

Since I didn’t go about it the right way, I can’t tell you what a safe timeline is, but I’d probably give it 6 months to a year. It looks excessive, even to me looking at it after I just suggested it…but really, it’s viable.

In the example I gave, there was a once-per-year conference, so giving my users a year to realize that they were missing it? Totally reasonable.

Take this small but important piece of advice and live by it. You will be glad you did.

 

Lessons Learned: Vocabulary

jargon

Linguistics is a truly fascinating subject, if you think about it – the study of how people communicate, how words are formed, changed over time. The same word in the same language may mean something different, depending on where you live.

It might also mean something different, depending on what software or platform you’re using and discussing. That can cause issues in a business setting.

Let me take you back in time to a conference room in Holland, MI, where a ragtag bunch of marketers (and their CCO, and a marketing consultant, and a commercial intelligence director) are sitting around a conference table.

One of them, a short young woman is waiting patiently for her boss’s boss to finish his question.

“Who are the people getting the nurturing emails?”

“Any Leads associated with the Engagement Program.”

“And Contacts?”

“Yes.”

“Contacts are in the Program?”

“Correct. Well, any Contacts that the Sales Directors have added to the Campaign.”

“What Campaign?”

“The nurture Campaign…whatever we end up calling it.”

“Ok, that’s what I’m asking about, then. Who are the people getting the nurturing emails?”

“All of them. As long as they are added to the Engagement Program.”

….

We’ll leave them there for now.

You might be a little confused, too. Sure, if you read English, you probably understand, in general terms, what all of those words mean. In the context of this conversation, it might even be possible to glean what exactly is happening. But I can assure you that at the time, it was not very clear, and the conversation went on for a while before I realized I was transitioning between platform-specific terms with the ease of someone who had greased their gear before going on a luge.

My point is – I forgot that the same things are often given different names, depending on the platform you’re using. Something about intellectual property law.

In this case – Marketo Programs are the capsule for an entire marketing initiative (thanks, Gaines, for getting me the answer to that one), where Campaigns are a Salesforce object that track attribution for Leads, Contacts, Accounts, and Opportunities.

For me, using the terms interchangeably, as I mentally moved between the two platforms, was easy. I understood the waterfall of events:

  1. Sales Director adds a Contact to a Campaign (or, more accurately, tells someone else to do it)
  2. The Contact is added to the Campaign, and in the next Salesforce-Marketo sync, the Lead record for that individual is added to the Program and given a Program Status
  3. The Engagement Program (think: drip campaign) does its thing and captures that person’s interactions with our content
  4. The Lead’s Program Status is changed, and in the next Marketo-Salesforce sync, that information is pushed back to the Campaign
  5. The Campaign Member junction object now has a new Campaign Status for that Contact
  6. Reports for all!

It made 100% sense to me to move back and forth between the terms. Because that was the flow of information.

But while I might be a walking dictionary of “Jargon Sam Has Learned,” I don’t have pages that people can flip to. The CCO couldn’t pause me, scroll through a glossary, and then press play. And I, in my wanting to be back at my desk and no longer in a meeting, just explained in the quickest way I knew how.

The meeting, of course, just went on longer, accordingly. And then we had a second meeting.

meetings

I would love to say that that happened only once, that I realized my mistake and, moving forward, chose my words more carefully, choosing instead to deliberately explain any and all platform-based decisions in a way that would make sense to anyone.

But then this wouldn’t be a lesson learned “the hard way.”

This happened so many times. Like all the time. I just couldn’t stop myself from throwing around Objects, Records, Tokens, and Flows. And it wasn’t until I was practically out of breath that I saw the glazed-over look in their eyes.

A system admin for a non-tech group like Marketing needs to be able to translate. Over time, yes, I learned to do that. I learned to get out the jargon because I couldn’t help myself, then go back and offer a more clear explanation.

Why is that so important?

Adoption. Validation.

If your users, internal customers, stakeholders, what-have-you cannot understand what you are saying, they will not understand the value that you or your platform provide.

It seems simple. This wasn’t news to me. But in practice, I often fell short.

So how did I combat this?

I continued to use the terms; I didn’t dumb down my content or what I said. But I made sure to also include explanations. After a while, the conversation would have gone more like this…

“Who are the people getting the nurturing emails?”

“We can select any existing Contacts in Salesforce or new Leads in Marketo and put them into the Engagement Program in Marketo. Sales Directors can add Contacts via the Campaign in Salesforce, which is connected to the corresponding Program. Once they do that, Marketo will take over, sending them the emails in a steady drip. Once they respond, we have a Campaign in Marketo that will automatically update their status, which will then sync back to Salesforce, and give the Sales Director visibility into their Contact’s interaction.”

Still uses all the fancy terms I was tested on for certification, and it describes what the platforms will be doing. It makes me sound super awesome for being able to do that, too, right? They don’t have to know that it was all the matter of about 10 clicks.

When have you used jargon to the detriment of getting your point across? How do you combat the temptation? Comment below or tweet to @thesafinhold.

Lessons Learned: An Introduction

Remember Jack Handey?

Yeah, ok, full disclosure – I was going somewhere with that, and then I started looking at Jack Handey quotes and 15 minutes later, I don’t remember why I brought him up.

Which brings me to my point: I have made some hilarious mistakes in my life. I’ve made some not-so-funny ones, too, but who wants to read about those?

Some of those mistakes were all about Salesforce and/or Marketo. Some were about working in general. Some have been ridiculously specific, or immediately apparent, or…I mean, you get where I’m going here.

Think about when you offer to help someone. I bet money (not a lot. I mean, like $5) that you have said, at least once, “I’ve learned about X the hard way, so if you have questions, let me know.”

You’re offering to share the lessons you have learned through trial and error, so that your friend/family member/vague acquaintance/barista/frenemy/etc. doesn’t have to.

My own mentor said it to me just the other day, so in a stunning act of plagiarism (not really. Please don’t sue me) I decided “BLOG SERIES!!!”

So that’s what this is. Well, not this one in particular. This is just an introduction. But anything worth sharing should be adequately introduced, so here we are.

standby