What I learned this week: Providers & Self-Signed Certificates

I would say that about once a month I have a client or coworker sending me an email that looks like this and asking “what do I do?”

SelfSignedCert has expired
SFDC Expired Certification Notification

I remember getting my first one of these and panicking, and the documentation available for admins with little knowledge of single sign-on is poor. I am pretty sure that we have all found the answer via the Answers section of Salesforce’ Help, as opposed to actual documentation.

I have kept a link on hand to share for just this occasion (it’s here, in case you need it).

Fast forward a few years, and I’m studying security and identify more in-depth than I have in the past, and much like data skew, that involves learning the correct terms for what used to sound like jargon.

As the link above to Salesforce’s help article states, this Self-Signed certificate is most commonly used for Single Sign-On settings, but…what does that mean? As with anything else, stating the purpose or cause of something doesn’t always answer a person’s question. Many people much smarter than me have rightly pointed out that if you cannot explain a concept to a child, you do not truly understand that concept. And Salesforce’s Help Articles aren’t always great for that level of explanation.

So let’s start with the basics: Single Sign-On.

If you work for a company in an office, you may already experience this everyday. You log into your computer, and doing so logs you into other company services – an extranet, your inbox, etc. To varying degree, the idea is in the name – you sign in once to multiple platforms.

Ultimately this works because there are two entities working together to allow this to happen.

The Service Provider is the system you’re being logged into secondarily – let’s say JIRA. This is the platform that is requesting your login credentials. Normally this request looks like a login screen, but for single sign-on the whole point is that you bypass that screen. So instead of asking YOU, it asks the system you’re logging in through.

This initial system is the Identity Provider. It is helpfully passing along your credentials to the system that needs the information.

Salesforce, as you can imagine, can be both. And the self-signed certificate is sort of like your global permission slip. And like a permission slip it needs to be updated every once in a while.

“But I don’t have single sign-on enabled!” you cry.

Well sure, that makes sense. That means that Salesforce may not be a Service Provider in your org.

Have you installed any connected apps, though? Many connected apps walk you through a setup process that includes a handy UI that takes on the heavy lifting of setting up your API connection. During this process, some of those apps may create a certificate, which you’ll see by reviewing your connected apps link to that certificate. Sometimes these will take care of themselves – the third party companies you’re working with KNOW about this, and they plan accordingly, but at the least, you’ll know.

And if you’ve enabled Salesforce as an Identity Provider, even if you’re not using it that way…well, there you go.

Long story short: if you don’t remember setting this up, it’s very unlikely to cause issues, but it’s also very easy to update. Bookmark that link, and next year when you get that email, you’ll be ready.

 

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.