What I learned this week: Data Skew

Disclaimer: In the spirit of full transparency, I learned about data skew a little while ago. But the whole point is “what I learned this week.” In some cases, “this week,” just refers to this week in time…like…last week, last month, whatever.

My first brush with NPSP was as a consultant. I remember very clearly thinking that some of the features would have been very handy for my B2B sales staff back in the day. In a lot of ways it was love at first sight. I still get prickly when people say mean things about it…

[Insert about a half hour of me looking for the best option for a “Don’t talk to me or my son ever again” meme before realizing there could potentially be a better use for my time.]

That said, the first time I started getting error emails at about 2am was ALSO around this time.

You know, this one:

Message: “First error: Update failed. First exception on row 0 with id 001……………; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record or 1 records: 001…………….: []”

And I was flummoxed. What does that even mean? Why are you locking anything? Who said that you needed exclusive rights? And what does this have to do with merging records?

For a while I sort of…ignored it. Honestly it would run again at some point, right? It rarely happened more than once for the same record.

Sometimes I would have dozens of them. Usually right after some major data change or something. I suspected they were related, but I had other pressing concerns, and eventually everything would be sorted.

Over time I filled in the blanks. Unable to lock row meant that whatever the code was trying to do, it couldn’t get update access to the record.

If I spent more than 30 seconds on it, it made sense. A record cannot be edited by more than one person at a time, so why would it make an exception (ha ha – get it?) for custom code.

And then again, for a while, I left it at that.

Enter Data Architect Trailmix, stage right.

A super important part of the large data volume considerations that are discussed in the data architect arena is the concept of data skew. And as I read about it, I was taken back to a project early on, a move from the Starter Pack and a bucket model to NPSP with Household Accounts.

This client was looking to upgrade to the new success pack. They had been using the bucket model for YEARS – more than 50,000 contacts all inelegantly shoved into this single Account called “Individual.”

It was difficult to report on things. It took forever for the record to load.

I knew that there was a correlation, but I could not, especially at that time, explain what it was. I had a sense that having to many child records was a bad thing. I didn’t know what to call it. And I wouldn’t know, until years later, that that very situation was what caused errors during the overnight batch processing.

Data skew occurs when we have too many child records, plain and simple. It has an impact on loading time (you try showing a record and querying tens of thousands of records at one time), reporting, and…yes, automation.

It doesn’t exactly help me fix the errors all the time. Sometimes it’s just bad timing, and not even because of data skew. But putting a name to something makes it more accessible, less concerning.

Carry on, NPSP. Carry on.

Online Proctoring: My Horror Story

I enjoy my creature comforts. I like working from my couch some days, with blankets all bundled around me, feet propped up, and a cup of coffee nearby. Most importantly I like all of those things in my own house. If offered an opportunity to get coffee at a fancy coffeeshop or make myself a cup of Chock Full O’ Nuts at home, I’m going to pick home. Every time.

So when I learned that certification could be done from home, those many years ago, I signed up immediately. The first online proctored exam I took was not actually for Salesforce. It was my Marketo Certified Expert exam, and I took it in December after signing up for a training course that came with a voucher. I figured it couldn’t hurt. And given that December is prime time for crap weather, I was excited, despite the “it’s not awesome” warnings available online. How bad could it be?

Well…

First my webcam just stopped working. It had been fine, doing its thing, and literally just before it was time for me to sit down and show my stuff, it stopped.

Kryterion was super chill. Their support team rescheduled my exam for an hour later, and I ran out to get a new webcam. Done.

Fun fact: new webcams are better than old webcams. The resolution on my new one was too good, in that it couldn’t match my face because the old picture I had on file for facial recognition didn’t have as high a resolution.

No worries. Super awesome support team reset that. Face recognized. Typing recognized. It was time to take the test. Aced it.

When it came time to take my first Salesforce exam, I figured I had worked out the kinks and could handle anything.

Well…

I just couldn’t log in! After about three or four attempts, calling support, and still not being able to access my exam, we discovered there was a server error on their side. They told me they would reschedule my exam (for free, again, thank you super awesome support team!) and call me when I would be able to log in.

I made myself a drink and watched an episode of the Office. I was halfway through my vodka-cran when they called and said I could get started. Aced it.

I took a few onsite exams after that. Switching it up, I guess. But the testing location was not a huge step up from the headaches I’d had at home, so it was back to online for me.

Testing with a Mac is different. Testing with the new MacBook Pro (with its nearly universally despised Thunderbolt 3 ONLY connections) is actually impossible. Literally. If your external webcam (which you have to use) is connected via a dongle (which is has to be), the feed won’t go through.

For my Pardot exam, it took us about 2 hours to troubleshoot. If not for the super awesome support team at Kryterion, I would still be in the fetal position upstairs. I ended up needing to use the gaming computer to take my exam. Sweet graphics, anyway. I still had to stop like five times to adjust where the camera was or the microphone volume, or whatever.

I’m really not trying to scare you off. Legitimately not my purpose here. But I want you to KNOW what you’re getting into, if you go the online route.

First of all, your test may go way smoother. I had at least two that went off without a hitch. But just in case, keep these things in mind:

  1. If you have a brand new MacBook Pro, just plan on taking the exam onsite or with a cheap-o PC you pick up at Best Buy for like $200.
  2. When they say that you should buy their specific webcam…consider it. I didn’t. I had to buy one last minute, and I just wasn’t going to reschedule. But they have one that works, so you might as well.
  3. Download Sentinel and do your “biometric scan” in advance but not TOO in advance. Like two or three days beforehand is fine. But if you sign up for the exam in June to take in November, just wait.
  4. Be prepared to spend some time getting INTO the exam.
  5. Be prepared to be interrupted DURING the exam to fix something.
  6. Lean heavily on the support staff there. They really are awesome, really patient, and they have the answers.
  7. Be NICE to the support staff. Their job sucks. They just watch a bunch of under-dressed, maybe showered, work-from-home people take exams and get mad all day. And they can help.
  8. Maybe make a drink beforehand?
  9. Definitely eat beforehand – it might be HOURS before you get another chance.
  10. Be prepared to retake the exam. After fighting with computers and getting interrupted and feeling like NOTHING YOU DO IS WORKING, you might not be in the best place to take an exam…so be patient with yourself, too.

Maybe I’m a glutton for punishment, but I’ll probably continue doing the online proctored exams. That is how much I hate driving in snow.

 

Obligatory apology and excuses blog post

That’s right, folks, it’s that time again, where I fish for flimsy excuses about why my (now paid) blog site has lain dormant as Moria for the past…can we say weeks? I’ll feel better if I say weeks.

Right, so let’s get it over with.

I’ve been working. Really, truly, I have. Statistically speaking, it takes about 12 months for someone to become (or at least feel) proficient in a new job. I’m about halfway there! In the meantime, I still forget details, sometimes – little things like checking a box or something. And then bigger things like balancing time or wrapping my head around how long it takes me to do Things. I still don’t always know if something is going to take me an hour or six days…

I’ve been meaning to write. As I was explaining to my Professional Writer father the other day, at any given time I have at least 3 draft posts, and then there are times that I have 7 or 8, all sitting there, wondering if I’ll ever get back to them. At least one of those drafts has been around longer than my new job…so….I’m sure I’ll finish it one of these days.

To be fair, I’ve had a lot going on. After Zoe left us so suddenly, I can safely say that the very last thing I wanted to do was…anything.

The first time you skip or forget something, it’s minor, right? It’s just a hiccup. The problem is that if you then skip a second time, or a third, it starts to snowball. And it snowballs fast. I guess that’s kind of the point of that metaphor, though, right?

Eventually going back seems that much more daunting. What do you mean I have to roll this 2 ton snowball back up the hill? It was so much smaller when it started falling! I’ll just wait for it to thaw a bit.

It doesn’t thaw. Winter has officially arrived.

My point is just that after a while writing a post seemed like an insurmountable challenge. It had been too long. I put in work to provide regular content, and then I let it fall to the side, in order to take on some more pressing things, and coming back to it means facing that gaping chasm in between last post and this post.

I don’t even want to THINK about how many of these posts I’ve made. But whatever. I’m only human. I disappear sometimes. The weight of things gets just a little too heavy, and my response is to tuck myself away.

So maybe this can be my blanket post moving forward? For the next time I need to limp away to lick my wounds and can’t work up the energy to put this kind of stuff into words.

I have some ideas in the works, though…all of the “well at least I’ll think it’s hilarious” variety. But it’s something, at least.

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.