Test Data Formula

It's quite a while ago that I wrote about having test data in your production org. (I'm still a fan.) But recently I set up an additional way to work with those test records: formula fields that designate a record as part of your test suite.

My client For Pete's Sake (FPS) really needed this trick. FPS has quite a few contacts that are test records and they come from various franchises or no franchise at all because they've been created by different people at different times for slightly different reasons. That makes it pretty hard to keep track of them all. Let's just list some of who they have:

• Patient Homer Simpson, his wife Marge, and children Lisa, Bart, and Maggie. They went on respite several months ago. Homer and Marge share phone numbers with a couple of FPS staff so that we could test notifications asking them to complete pre and post respite surveys.

• Patient Wonder Woman and her caregiver Spider Man went on a later respite. They, too, shared phone numbers with real people.

• Micky and Minnie Mouse have also gone on respite and filled out surveys.

• There's a doctor Frank Enstein who has nominated some of his patients for a respite from FPS. (That one still makes me giggle. Kudos to Pam, the FPS staffer that came up with it.) On quick glance in a report or list view he is not obvious as a fake!

• The Flintstones are in there.

• And then there are Im Testingagain and Atest Nominator, both of whom I get the blame for. (I wasn't feeling creative by the umpteenth iteration of testing a FormAssembly form.)

• Etc...

We created several of those patient and family groups in the fall, when FPS was testing a new mobile app they'd launched for patients and caregivers that includes their surveys. We needed to be certain the SMS notifications were going out and that surveys completed in the app flowed through the integration to Salesforce. And then we needed (and still need) to keep those test patients going so that we get the follow-up surveys at 1 month, 3 months, 6 months, 9 months, and 12 months post-respite. We can't restart and reuse those same people as though they're newly nominated or we'll lose our test of the ongoing follow ups. This also means we might add some new test records during upcoming respites if we find we want to test other things.

But that's not all! For each patient in the FPS program we have onboarding records and respite records as well. Those are related to the contact by a lookup field and are auto-numbered. So even if the patient name were an obvious test record, the respite or onboarding might not be.

For Pete's Sake also uses leads for the initial nomination of a patient by their doctor. So we're going to have some test records in the Lead object, either as new nominations or already converted into some of the contacts above.

✅ Formula Field to the Rescue

Easiest way to know if a contact is a test record is to have a field that is automatically checked if they are. No magic here, that's just a checkbox formula called Is Test Data.

There are several ways you could approach making the formula that actually controls this field. One way or another you're going to be hard coding something into this formula by which you, the human, are directly telling Salesforce that this record is a test and all others are not. I haven't been able to come up with an alternative to hard coding. And don't forget that if you add test records, you're going to have to edit this formula to account for them.

What you hard code is up to you. One option would be to hard code record Ids. As long as nobody goes merging duplicates of your test records, those Ids won't change. I decided to actually hard code the names of the people themselves so the formula would be easier to read:

( FirstName = "Spider" && LastName = "Man" )

|| ( FirstName = "Wonder" && LastName = "Woman" )

|| ( FirstName = "Mickey" && LastName = "Mouse" )

|| ( FirstName = "Minnie" && LastName = "Mouse" )

|| ( FirstName = "Fred" && LastName = "Flintstone" )

|| ( FirstName = "Wilma" && LastName = "Flintstone" )

|| ( FirstName = "Bam Bam" && LastName = "Flintstone" )

|| ( FirstName = "Homer" && LastName = "Simpson" )

|| ( FirstName = "Marge" && LastName = "Simpson" )

|| ( FirstName = "Bart" && LastName = "Simpson" )

|| ( FirstName = "Lisa" && LastName = "Simpson" )

|| ( FirstName = "Maggie" && LastName = "Simpson" )

|| ( FirstName = "Blank" && LastName = "Suzie" )

|| ( FirstName = "Frank" && LastName = "Enstein" )

The formula on Lead is exactly the same.

I could have consolidated a bit by just using LastName = "Flinstone" because I strongly doubt there are real people with that name. But that would barely matter.

Formulas on Other Objects

Here's the part where you have to know your instance: Do you need formulas on related objects to know if they go with a test record? In FPS's case, the answer is Yes. We needed formulas on Respite and Onboarding because they're related by lookup, not master detail, and there are a couple of fields that could mean they're test data, if either the nominee or patient is fake. (Hopefully it's either both or none, but people make mistakes...) Onboarding, for example, has two lookups to Contact, for the nominee and their caregiver, so we have this formula field:

Nominee__r.Is_Test_Data__c = true

||

Caregiver__r.Is_Test_Data__c =true

The nice thing here is that we didn't have to hard code for the child object's formula field. We just look up through the relationship to the formula field on Contact. If the contact is a test record, we know the onboarding is too.

Now Reports are Easy!

All those dashboard reports that you've been filtering with Full Name not equal to Harry Potter, Super Man, Homer Simpson... are now a breeze. Just use Is Test Data equals False.

No more remembering who all the fake people are. It's easy to flip back and forth to see only the test records. And it's clear for any user looking at report filters to know why that filter exists.

Also a handy filter for a related list:

As long as you're updating your hard coded formula, this filter keeps up. That's far easier than editing every critical report in the org to filter off the new test record you've just created!

Bonus Points

Want to really help your users and yourself? Put a banner on record pages to remind you that you're looking at test records. You've already got the field to conditionally display a message. So throw on a Lightning Messaging Utility banner that only shows up when the field = True.

I've set up this same banner on Contact, Lead, Onboarding, and Respite. (That was four repetitive instances of the same task, but it took all of five minutes.)

Future You and your users will thank you.