Juicy questions 1: Six digit numbers and the question of patterns

I have a small number of questions that pop into my head from time to time. I bat them away because they're juicy and I'd like to consider them another time. I never do though. Until now though. My question, which I think I've been thinking about since I was a child, is this:

How many numbers have patterns in them?

Let's restrict it to 6 digit numbers for sake of example. My phone number used to be like this (digits have been substituted): 230191. That 191 is a pattern, as the digit 1 is repeated either side of the 9. 

I'm using one time codes in lots of places now. A lot of the time* the third and fourth numbers seem to be the same. That feels like a pattern too. As does 128348, and so on.

The key question then is, "what is a pattern?". Apart from repeated digits, can we generalise it? That is why it's a juicy question, and I'd welcome any wisdom on it.

*This is one of those hundred or so cognitive biases.

Secret money (if you know what I mean) - can you trust it?

I'm using the words "secret money" but you know what I mean - c----------y.

"When are you going to give us your opinion?", literally no-one has been asking. I had some vague thoughts, which never got anywhere. I mentioned this in the comments on Tim Bray's post on AWS and Blockchain. 

"If I could get some coherent thoughts on it I would write something about "you've got to trust somebody", like the person who created that executable that's your on-ramp to the blockchain."

Doug K said

"Bruce Schneier wrote that coherent essay, look on his website for the post Blockchain and Trust."

Here it is: Blockchain and Trust.

 "What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they're often single points of failure."

Thanks Bruce, for putting it so well.

 

FormAssembly and Salesforce connectors - advanced techniques

Following on from my initial post about FormAssembly and Salesforce, here are some advanced techniques.

We use a particular technique with our FormAssembly forms and Salesforce when it comes to looking for existing contacts, creating new ones, and doing further updates on Salesforce.

The Form Submitted connector runs after the user clicks the submit button. Once it's finished the user gets the acknowledgement message, or gets redirect to the page saying it's worked. The reason we put some of our processing here, is because if it fails the user gets told with an error message. If we used the After Form Submitted connector then they wouldn't see the error message they would think it worked. Although we get emails if the connector fails, it may be a few days before someone gets round to reading that email and contacting the user to say it didn't work.

The error message won't mean much to them, as it'll be Salseforce jargon, but hopefully they'll pass it onto us and we can help them. Or if it's something that is fixable (e.g. an invalid email address) then they may retry. (FormAssembly email validation lets email addresses through that Salesforce says are invalid.)

So in the Form Submitted connector we look up the user by email, and create a contact if they don't exist.  If they do exist we also take the opportunity to update fields, like their name. Then in the After Form Submitted we look them up again. We know this will work, because the previous connector created them if necesssary. Then we do whatever the form requires, e.g.

• if they're signing up for a subscription then add them to a campaign
• if it's something we need to do, create a case
• if it's giving consent for something, add a consent (we use GiveClarity's own consent system)

Duplicates

One problem with creating contacts like this, is that you may get a duplicate message. Even though Salesforce considers this a warning, FormAssembly considers it a fatal error. (I suggested to them that they don't do that, but I couldn't get them to understand what I mean.) So we had to set our duplicate settings on Salesforce so it does nothing about them, apart from add them to the possible duplicates report. It does mean though, that we need to be vigilant about running that report.

Do you have any tips about using FormAssembly and Salesforce together?

FormAssembly Salesforce connector review

One of the consultants we used for our switch to Salesforce and NPSP recommended we use FormAssembly for getting data from webforms into Salesforce. That was a very good recommendation, and so I'd like to say a bit about my experience with the FormAssembly to Salesforce integration.

FormAssembly has various integrations, Salesforce is only one of them. They can run at one of three points - when a form is loaded, when it's submitted and after it's submitted. The difference between the latter two is subtle. When you click the submit button then "when" run is one and the user gets the success page when it's complete, or an error if it fails for any reason. At that point the "after" one runs and the user is unware.

I'm not going to do a full tutorial as the FormAssembly documentation is very good. I'm just writing here to say that it's very easy to use, even if you're not a Salesforce admin. When you start using the connector you can create, update or lookup an object. Depending on how that went you can then create, update or lookup a subsidiary object and so on.

So a typical case might be that you lookup the email address on the form to find a contact with that email address. If you find them carry on to the next step, otherwise you add them. 

You can do all this by clicking around the user interface, so it's very #clicksnotcode. FormAssembly has a formula function, not specific to the Salesforce connector, and this can be used, for example, to turn two address line fields into a single Mailing Street field with a carriage return between the two lines:

@CONCATENATE(%%tfa_10%%,@IF(%%tfa_11%%,@CONCATENATE(@CHAR(13),%%tfa_11%%),""))

tfa_nn are the internal names for the fields.

This combination of FormAssembly and Salesforce has met our needs so I'm very pleased with it.

Update: I wrote a followup post on FormAssembly and Salesforce advanced techniques

Are spreadsheets really all that bad for storing data?

Photo by krakenimages on Unsplash

There, I said it. You were thinking it though weren't you?

If you're responsible for a CRM then spreadsheets are the bane of your life. People download them and then leave them lying around for years. People use them for storing information that should really live in the CRM but for various reasons they set up their own spreadsheet.

Some of those reasons are understandable. Spreadsheets are really good for laying small amounts of data out and easy to update. If the information was in the CRM it might be a bit more work to find and maintain. The downside is (I feel I hardly need to tell you) that it's not easily accessible to other CRM users, it goes out of date and just feels wrong.

I'd like to propose the controversial opinion that there may be some circumstances where that data is OK living in a spreadsheet. At this point I expect you're sharpening your pitchfork ready to come and drive me out of the CRM village, but hear me out. I think there are a limited number of cases where it's OK. Here they are:

The number of records is limited. You may have X thousand or million records on your CRM but for a small group of records there is a lot of extra information you want to store. Rather than add a number of fields for all those records, it may be OK to store them in a spreadsheet.

The data isn't complex. It fits on a single sheet. There are no complicated relationships. There may be lookups, but they have simple lists behind them.

Everyone knows where it is. Well not everyone, but everyone who needs to know. So access does have to be limited to those people.

The procedures are clear. Although the data is stored in an informal way, it still needs to have good procedure around it so that people know how to update it.

Have I convinced you? Are there other rules you'd want to add to my list?

Users as testers

Photo by Michael Dziedzic on Unsplash

By "Users as testers" I don't mean the way some companies throw out software which isn't quite finished, without admitting that, and let people find the bugs.

I'm talking about normal human beings, as opposed to IT people, who get to use technology that previously would have been unavailable or require too much specialist skill. This article is for you normal human beings, and says what you need to know about testing stuff.

Thinks break by themselves

I remember someone who had set up some sort of automatic process and was surprised when it stopped working, without them realising. He said, "I assumed that once it was set up it would keep on working". It would be really nice if that was the case, but unfortunately it's not. The trouble is with processes like this, like something that sends you an email if some rare event happens

• something somewhere along the line gets changed and things don't fit together and they stop working
• something was a paid service and someone stopped paying the bill, or a credit card expires and no-one notices
• a computer gets upgraded and the thing is no longer possible with the upgraded system
• someone leaves, their email gets closed down, and then no-one gets notified

So if a process is important to you, then it's worth checking regularly that it works. How regularly? Ask yourself how soon would you like to know that it stopped working.

If you change something then you have to check it

Many years ago I was working on a system for controlling gas pipelines. Something asked me to make a very small change. I didn't check that the change worked, as they were in a hurry. They took the tape the next day (it was many, many years ago) and went to the control room and installed the new version. It didn't work, so their whole day was wasted.

Even if you're not a programmer you might:

• write a spreadsheet formula
• create a form
• use some fancy website tool which links two things together

If you change something then you have to check that it works. The thing you change might be something as simple as adding a new thing to a list. There are several ways that just adding the thing may not work out:

• There are in fact two lists, and you need to add the new thing to the other list too
• You may have typed something in that's too long, and it doesn't work
• There are a maximum of five items in the list and you just added the sixth

So if you change something, then check that whatever you changed has the effect that you want.

The other check

The other thing to check is that everything else works as it should before. As I said above, just because something was working doesn't mean it will carry on. In making a change in one area something else may now not work, as a side effect of what you've just done. It's not going to be practical to check every aspect, but you can check two things:

1. If you have an idea how things work underneath (and you may not, some things are very mysterious) then you can check the things that are linked to what you changed.
2. The important things - do they still work?

How to check

I can't give much specific advice on this, because a lot depends on whatever it is you're changing. Here are some general tips though:

• Check things two ways, such as adding up numbers from two different sources that should be the same
• Assume you know nothing about how it works (which may be true - see "mysterious" above), check that it does what it should be doing
• Check the extremes - the biggest or smallest numbers
• Put in rubbish - if a number is expected then how does it handle ?Elephant99!
• Try different combinations. If you have something that can be A or B and something else that can be X or Y then try AX, AY, BX and BY in case there's some interlink