Paul Prescod is a performance engineer at Salesforce.org. He is also involved with a project called Snowfakery. This program is capable of creating complicated and unique data records for testing.

In this episode, Paul and I are talking about everything Snowfakery. We also get into some of his background, including his work with a company that created mobile games which motivated behavioral change. Listen in to hear about all this and more.

Show Highlights:

  • How Paul got into his role at Salesforce.org.
  • His impetus for building Snowfakery.
  • How complex data models are and why.
  • Where the name Snowfakery came from.
  • How Snowfakery works.
  • How much the program scales.
  • The outputs Snowfakery is capable of.
  • The benefits of Python.
  • How the developer community is involved with the creation of Snowfakery.

Links:

Episode Transcript

Paul Prescod:
Between humanities and the STEM, when I was younger, but when push came to shove, since I liked them both equally and one was obviously a little bit easier to make a living in.

Josh Birk:
That is Paul Prescod, a performance engineer over at Salesforce.org. I’m Josh Birk, your host for the Salesforce Developer podcast. Here on the podcast, you’ll hear stories and insights from developers for developers. Today we sit down and talk with Paul about his project, Snowfakery, which is capable of creating complicated and unique data records for testing. We start as usual with his early years in an interesting origin story of an Apple computer.

Paul Prescod:
My dad was more or less an electrical engineer. He didn’t have a degree in that. He was an electrician. He actually built an Apple II computer, a clone-

Josh Birk:
Great.

Paul Prescod:
He was in this strange situation where he worked for someone whose job was to localize the Apple II to Europe, and then the extra chips left over they said, “You could just go and build your own if you want.”

Josh Birk:
No way.

Paul Prescod:
So he spent months in the basement soldering together. It’s probably the world’s only wood paneled Apple II computer.

Josh Birk:
Considering you’re talking about Apple hardware, which is extremely proprietary, I would think that that’s probably highly accurate. Nice. I noticed on LinkedIn you list games among the things that you have programmed. What kind of games are we talking about here?

Paul Prescod:
Those were actually games to motivate a healthy behavior through a long strange path of [inaudible 00:01:44] shifts over time, I ended up as co-founder of a company that made games, mostly mobile games, which motivated behavioral change. You could think of it as gamification, but also education, and have it cracking all mixed together. That was kind of what got me into the universe of software for good, software that makes the world a better place.

Josh Birk:
Nice. Nice. Can you give me a specific example of a kind of behavior that’s getting a change there?

Paul Prescod:
Often just taking medication, there’re all sorts of bad habits people have where they have some condition and then they feel like, “Oh, I feel better now, so I’ll stop taking the medication that allowed me to feel better.” So we would, as I said, mix together education, explain to them why that’s a bad habit with gamification and have it tracking to did you actually take your medication? We got really deep into the behavioral psychology. We had lots of conversations with people like Dan Ariely and other experts in behavioral psychology. That was an extremely interesting part of my career.

Josh Birk:
That is fascinating. You kind of said at the start of your interest in Salesforce… I’m sorry, I jumped the gun there, software for good. I almost feel like there’s an arc there. What led you into a role at Salesforce.org then?

Paul Prescod:
Yeah, yeah. I had sold my portion of that company and I took some time off to be with my kids. I did some homeschooling, and we did some traveling, and that was all great. I said, “I don’t want to move backwards, now that I’ve discovered that it’s possible to find a job where you can make the world a better place at the same time that you’re getting paid well and having fun. I’d like to do that again.” So I had a friend, actually at church of all places, that said “Do you want to come work for Salesforce?” I was like, “I don’t really know much about Salesforce, but it seems like a relatively typical big company from what little I know about it.”

Paul Prescod:
She said, “No, actually it’s a pretty special company.” She talked about some of the amazing philanthropic things that Salesforce in general does. She said “I work in particular for Salesforce.org, which is focused on nonprofits and educational institutions and philanthropy.” I said, “Oh wow, that actually sounds like just what I’m looking for.” But I was still a little bit leery because so many people that come to work at Salesforce already have a deep understanding of the ecosystem. They already know Apex and all that sort of thing. But because Salesforce.org, a lot of what they do is opensource, I was just poking around at my friend’s GitHub, and I stumbled across this thing called CumulusCI, which is written in Python, which is my favorite programming language, and it’s opensource.

Paul Prescod:
There was a job opening, so it was like the stars aligned. It was my dream job.

Josh Birk:
Nice. That is awesome. Today we’re going to talk about Snowfakery, but before we even get into what Snowfakery is, I kind of feel like tools like this one have some kind of origin story, which is like a tipping point where a developer was like “Darn it, I’m just going to build a tool to fix this situation.” Is that kind of what happened? What was the impetus towards building something like this?

Paul Prescod:
Yeah, yeah. That is pretty much what happened. I was hired to be a performance engineer, in particular a tools builder, a performance tools builder at Salesforce.org. You’ve interviewed my boss, Jason Lance, and you know that he and his at the time boss, Kevin Wilmer, they’re very big on opensource and they’re big on thinking how we can build things that are helpful to us but also helpful to our customers at the same time. They, Kevin and Jason before I arrived, already had this vision that we should be able to test our packages, and then customers should be able to test our packages on their computers on their orgs. Then they should also be able to test their customizations of our packages so that they could determine whether a performance issue they saw was in our package or in their customizations, which is more often the case to be honest.

Paul Prescod:
We had this vision of some sort of a performance engineering platform, and I thought let’s work through this methodically. What is the first thing you need to do? Well, you need to feed the org with data that matches your schema. So, I will put my focus on that. I did a little bit of everything else you need, a little bit of visualization, a little bit of automation of actually running the jobs. We have a full suite for all of those things. Once I got into that first part of the problem of data seeding, I was surprised that there wasn’t really anything out there in the world. I started doing it mostly as a Python library that Python programmers could use.

Paul Prescod:
We have these things in Salesforce.org called opensource prints, where we actually meet with a community and work with a community so customers and system integrators, and consultants and so forth, and we bounce around ideas and we collaborate. Someone at one of those, a friend of mine now, Aaron Craftsman, said “What if we could build a declarative that you wouldn’t even need to be even a Python programmer, even lower the barrier.” I wasn’t actually at that sprint, so he collaborated with my colleague, David Reed, on a very, very early prototype of what that might kind of look like.

Paul Prescod:
David Reed brought the idea back to me. At first, I was skeptical that the complexity of the data shapes… I almost started it to prove that it couldn’t be done and that we would have to fall back to Python. I figured out some tricks, and then some more tricks. And then wow, this actually is possible. So, I took that idea and I ran with it.

Josh Birk:
Nice. Let’s dig into that a little bit more because I think when people think… Especially if you look at blog posts and presentations and stuff like that, a lot of the representation of data that’s going to be created for test data is actually relatively simplistic. It’s like here’s a few accounts where I show you. Here’s a few contacts to show you. How complex is that data shape getting and why?

Paul Prescod:
It really depends on the domain. That’s the first thing, of course. Some domains do have extremely complicated data models, many layers of inter-related objects and often they need to be synchronized in their actual data so that the dates at one level influence three levels down, or even a date influences for example an opportunity stage name, if the close data is in the past and maybe this stage name should be closed and those sorts of things.

Josh Birk:
Gotcha.

Paul Prescod:
It’s an interesting kind of almost philosophical question, which is you have to estimate to a certain extent the risk you have if your data is not representative when you’re doing your performance testing.

Josh Birk:
Right.

Paul Prescod:
You have to have a mental model I guess of the code that you’re working on, and try to determine what level of data fidelity is actually needed. It really depends on the complexity of your code, I guess, what level is needed. The data models themselves can often be objectively complex, as you know if you’ve been in this space for a long time.

Josh Birk:
Right.

Paul Prescod:
The subjective part is just all of the little details around business rules and accuracy of names and dates, and those sorts of things.

Josh Birk:
There’s the shape of it, and then interestingly the episode that’s currently in the pipe and I think will, if all things go to plan, will come out the week before this one. So, if anybody’s listening to this, rewind a week. I’m talking with [Karishmo 00:10:02] about how important it is, if you think that you’re going to try to scale something or [architecturalize 00:10:07], the litmus test is that you are testing against data that looks a lot like your production data, both in shape and also in scale. It sounds like Snowfakery does some really interesting stuff when it comes to scale.

Josh Birk:
But first, I do actually want to ask, why the name Snowfakery?

Paul Prescod:
The idea is that every data record is like a snowflake. It’s unique. It’s created on the spot and unique, and randomized. It’s fake data, so it’s like a factory for fake snowflakes.

Josh Birk:
Nice. Was there an intentional naming tie-in between snowflakes and cumulus? Or did that just sort of happen?

Paul Prescod:
It actually mostly just sort of happened, but it is a nice coincidence. At some point, we will also have a plugin to connect Snowfakery to Snowflake, and the confusion will be completely circular.

Josh Birk:
I like it, and you could put it up on Azure and then everything is just all lost.

Paul Prescod:
Yeah.

Josh Birk:
I think you’ve touched on a few of these bits, so this might be kind of a summary question, but there are other tools that do these kind of things out there, I think. I’ve even had at least one or two of them on the show. What was the thing that you were like, “No, I need Snowfakery to be able to do this in order to be successful for this goal”?

Paul Prescod:
There’s a few different aspects. The first is that we wanted it to be as declarative as possible, low code. We’re not quite to the point of clicks not code, but we’re low code. That was the first main goal. Second, it didn’t need to scale up to hundreds of millions of records because Salesforce.org, we work with some of the biggest nonprofits in the world and they have recurring donations. Some of them, you can imagine have people who have been donating to them once a month for 10-20 years. There’re records for all of that stuff.

Paul Prescod:
So, the scale can get enormous over time. That was another one. Capacity to be integrated into CumulusCI, was another one. So, Snowfakery is implemented in Python, the same language as CumulusCI. A capacity to build these complex data shapes, the references, there were so many tools that would let you build any one table, but connecting the tables to each other, especially in a way that’s compatible with Salesforce. I’m talking about tools that are not necessarily designed specifically for Salesforce. That was another gap that we kept running into.

Paul Prescod:
We found a lot of people were using Mockaroo, which is again one of these mostly one table at a time type things, and then they were doing just unreal complex spreadsheets to build the relationships. It was a very manual process, and every time you wanted to change the data you basically had to do it again from scratch.

Josh Birk:
Gotcha. Gotcha. Let’s talk about that scale a little bit because the general flow for Snowfakery seems to be set up that data shape, as you’re saying, in YAML, and describe what it is that you’re going to want, and then run Snowfakery either within the tool that’s being associated with [inaudible 00:13:29], and then you output whatever it is that I can then upload or insert into Salesforce or the database I’m working in. There is a line in that YAML that is count, which is give me this number of records to be represented. What is the top number? What’s the maximum value for that?

Paul Prescod:
That’s a great question and one that I get a lot, just how much does thing scale? Let me just first say that as cool as the count feature is, I actually encourage people to do the big numbers in the command line or in CumulusCI. What you can do is tell it to do a multiplication beyond that count. In your count, you might say “I want 20 records,” and then on the command line you could say “Actually, I want 100,000,” or a million, or ten million, and it will just execute the recipe over and over again until it hits that number.

Josh Birk:
Just to ping on that a little bit, is that kind of going back to the YAML that’s described in the shape within the processes, the one that’s actually in charge of “I need 100,000 of that”?

Paul Prescod:
Exactly. And then you don’t have to edit your YAML when you want to… All the time, I’m just testing this so I’ll just run it on a small number of records. Okay, it looks good. Now, I’m running it on 100,000, a million, 10 million. It also has its own kind of a batch mechanism, which means that it can discard information it doesn’t need anymore. That makes it essentially unlimited in its scale. I can tell it “I want a billion records,” and it will only keep around let’s say a couple hundred thousand at a time. So, it basically scales all the way up. It’s the org itself that has the memory of the first 990,000 [crosstalk 00:15:19].

Josh Birk:
Snowfakery itself is generally just not the limiting factor. It sounds like it’s on the other end of the process. It’s where you’re trying to actually put the book on the shelves.

Paul Prescod:
Yeah, exactly. Yeah, yeah, the limits to every relational database and so forth.

Josh Birk:
Right.

Paul Prescod:
Snowfakery itself discouraged information, so the limit is always on the other side.

Josh Birk:
This is a broad question, I’m just going to admit that, but just kind of on that point, what kind of tips and tricks in Python were you learning along the way to make that efficient?

Paul Prescod:
That’s a great question. I think it was more of a design philosophy than anything particularly that I learned, but it was really about that design philosophy of keep around as little data as possible and upload it as quickly as possible, and then I can forget it. It’s a little bit like using a notebook, instead of trying to just sit in a class and memorize everything, you use a notebook and now I don’t have to think about that. I can come back and review it later.

Josh Birk:
Gotcha.

Paul Prescod:
That, I think is the… The other interesting aspect about that is what I call horizontal striping, which means that I’m uploading let’s say 10,000 accounts, 20,000 contacts and 30,000 opportunities all at once. Then I come back and do 10,000 more, 20,000 more, 30,000 more. They’re like packages or portions, since we use food metaphors often in Snowfakery because we call our scripts recipes. So, it’s like a portion of food. That’s one of the things it also does that’s different than a lot of tools [crosstalk 00:17:02].

Paul Prescod:
That again allows us to once we’ve uploaded a particular portion we can just forget about it altogether and move on.

Josh Birk:
Let’s touch on that last part a little bit. Configuration files for your data shape, process for what that shape is going to be done with, what kind of output/outcomes is Snowfakery capable of?

Paul Prescod:
Snowfakery, in terms of data shape, it can represent every data shape that we’ve so far discovered. It can join tables with no problem, any kinds of look up relationships and so forth are no problem. I think that’s a problem we have not yet run into. I think it might have a gap around polymorphic look-ups, but no one has yet asked me to do a polymorphic lookup. So, far that’s theoretical but I may have to add that feature at some point. I just realized that recently, I probably do have a gap without polymorphic look-ups.

Josh Birk:
Nice.

Paul Prescod:
I’ll do that… So, just to finish up on formats, Snowfakery, it can connect directly to the Salesforce orgs through CumulusCI, so the output goes directly into the org. You don’t have to do any extra load process. It also can output a CSV file, a Jayson file, and the way of making new output formats is very straightforward. So, theoretically it can connect to anything. It does also connect to relational databases through a SQL connection as well. So, it can connect to a live relational database or it could generate an SQL file.

Josh Birk:
Got it. Got it. No, I was just going to say who doesn’t have a blind spot when it comes to polymorphic fields?

Paul Prescod:
Oh, and I forgot one other output that’s a little bit fun, is for reasonably sized data graphs you can even output an image, a picture of the graph, which I use quite heavily in the Snowfakery documentation to say, “With this YAML file you’ll get a data shape that looks like this. With this YAML file, you’ll get a data shape that looks like that.”

Josh Birk:
As soon as you said that, I was like “Why?” But yeah, that actually makes… So that you can get a preview of what’s going to happen before you throw anything into an org.

Paul Prescod:
Exactly.

Josh Birk:
Yeah, that’s really cool.

Paul Prescod:
That’s another good reason why you don’t want to over-use that count button. If you put a count colon a billion, then when you try to visualize it you’re going to have a problem.

Josh Birk:
Yeah, yeah. Yeah, and I would assume if you accidentally pressed the command line on that billion count number you’re probably also going to have to go make yourself lunch.

Paul Prescod:
Yeah, exactly. Yeah, yeah, yeah.

Josh Birk:
I do want to get into one of the cool tricks that it does. I know other test factories do similar things to this, but I just kind of want to get the concept of the breadth of it, because you’re creating unique snowflakes. What kind of, I guess masks might be the right word, because you can just say “I want my first name field to look like a first name. How many of those sort of nouns is Snowfakery capable of faking?

Paul Prescod:
Just tons and tons. It builds on a library called Faker, a Python library called Faker. In Snowfakery 2, which is just coming up later probably before this podcast launches-

Josh Birk:
Nice.

Paul Prescod:
Its forward-looking statements, et cetera, et cetera.

Josh Birk:
Right.

Paul Prescod:
It’s all opensource so you can track the progress on GitHub. In Snowfakery 2, we have quite a library documentation for what we’ve imported from Faker, and we contribute back to Faker as well as an opensource library. Yeah, it’s got names across just tons and tons of locales, Swedish names, Japanese names, French/Quebec names. It’s quite a broad locale in terms of nouns, everything from IP addresses, banking numbers, credit card numbers, everything you would think of with respect to addresses, all sort of computing things, different data computing dating types and so forth.

Paul Prescod:
Yeah, it’s very broad and you can build your own in Python. You could build your own with what we call a Python plugin, or you can use a formula language. Snowfakery itself has a built in formula language so you could, similar to how you might combine two things in an Excel spreadsheet or a Salesforce org from two different fields, you can do that in Snowfakery as well. You can do math in those formulas too. You can do things like incrementing numbers as a way of getting uniqueness.

Josh Birk:
Nice. Nice. Back when you were talking about some of the weird complexities, first of all it’s fascinating that somebody was like, “I need only Japanese names.” “Here’s a bunch of Japanese names for you.” Could you theoretically, for instance, insist on first name and last name being Japanese names because of the region field for instance is Japan?

Paul Prescod:
Absolutely, yeah. Yeah, yeah, yeah. In fact, there is a concept of a locale built into Snowfakery so that you can say that this whole contact should be… You can randomize that as well. You can say that I want a random mix of Japanese and Canadian, and Dutch contacts, and then it will have all of the fields be in the correct locale.

Josh Birk:
Got it. When you’re setting up all those configurations, if you need relationships like that, do they need to be in the same YAML file? Or is one YAML file capable of pointing to other ones so that you can kind of divide and conquer your data shape?

Paul Prescod:
Yeah, you can absolutely break up the YAML files and include other files. We’re working with the opensource community that I mentioned before. We’re trying to push the boundaries of making libraries of kind of reusable recipes that you can combine in the same way that you combine programs in a programming language.

Josh Birk:
Okay, so I’m now trying to get my head around that complexity times however many records I’m trying to put into a system, times the fact that Snowfakery is trying to be as sufficient as possible in using as little memory as possible, I guess is a way to put it.

Paul Prescod:
Mm-hmm (affirmative).

Josh Birk:
How are all of these records unique? Help me get my mind around this, Paul.

Paul Prescod:
Yeah, yeah, yeah. At sufficient scale, if you need them to be literally unique then you can do tricks like indexes or UUIDs, is one of our built in data types.

Josh Birk:
Got it.

Paul Prescod:
I have an open issue that a colleague has given me a challenge of “Can we get a UUID down to 10 digits?” I’ve got some interesting ideas about that. For now, you need long UUIDs because that’s just what’s built in. I think I have an idea for an algorithm that you could get [uniquifying 00:24:27] codes down to 10 or 12 digits and so forth. Without that sort of a thing, it’s mathematically impossible. If you just have standard first names and standard last names, eventually you’re going to have a conflict no matter inefficient your code is, because there were only so many unique first names and last names.

Josh Birk:
Right.

Paul Prescod:
I know for a fact that there does exist another Paul Prescod in the world, and there probably is a different Joshua Birk and so forth.

Josh Birk:
There is indeed a different Joshua Birk, with the last name spelling, B-I-R-K, which statistically, and I’m not even making this up, I actually have figured this out by doing the kind of weird name math like what your kind of talking about here. B-I-R-K is the fifth least frequent way to spell my last name.

Paul Prescod:
Oh, yeah, yeah.

Josh Birk:
And that dude is in computers.

Paul Prescod:
Oh, wow.

Josh Birk:
It’s a little freaky. If you Google… I have a bigger footprint, but every now and then people are like, “I thought you weren’t living in Bloomington anymore?” That was the other thing, he’s also I think a Midwesterner. We’ve probably met at some point, I don’t know. I love the dot.org culture that’s like “Paul, you’re doing some really mad science, but could you do it a little bit more crazy and just get this down to 10?”

Paul Prescod:
Yeah. Yeah, yep that’s definitely our culture. Yeah.

Josh Birk:
Speaking of this, I just have to ask, why is dot.org so in love with Python?

Paul Prescod:
I think it all started with Jason, and then he hired a bunch of us. So I think… Yeah, yeah it’s one of those path dependence things, to be honest though.

Josh Birk:
Yeah, it has a Jason Lance evil plan feel to it for sure.

Paul Prescod:
Yeah, yeah, but it is a very… For the kinds of things we do, it is a pretty logical language. It’s very faster to write code in. Actually, with the exception of Snowfakery, usually the types of things we do do not need the highest performance. Snowfakery does have to push the boundaries of Python’s performance. Luckily, there is so much happening in the Salesforce org itself, and Snowfakery 2 is going to be a multi-processor. So, between those two things we can easily generate data faster than the org can ingest it. A lot happens in the Salesforce org when it’s doing data ingesting, all of the validations and triggers, and et cetera, et cetera, et cetera. So yeah, we can pretty easily exceed the ingesting performance of a Salesforce org.

Josh Birk:
Got it. Got it. I do want to talk about 2.0, but also just to wrap that up a little bit, the other thing I had noted whenever Jason is showing me neat tricks that Cumulus can do, and then my conversation with Dr. Clark about the robot framework, is how Python’s insistence on nice formatting is so useful for tools like this, because even somebody who doesn’t know Python can read a script and kind of understand what’s going on.

Paul Prescod:
Absolutely. Absolutely. We have so many apex developers who work inside and outside of dot.org who say, “I’ll just learn enough Python to extend this thing.” They may not be the most idiomatic code, but it gets the job done. So yeah, yeah, that’s definitely true.

Josh Birk:
Let’s talk a little bit about using Python like that a little bit. You mentioned them before, what’s a recipe and where do they lie within Snowfakery, Cumulus and the YAML configuration files?

Paul Prescod:
A recipe is itself a YAML configuration file different than the CumulusCI.YAML, which kind of orchestrates the overall configuration of an org. The recipes are YAML, and then the Snowfakery Python code kind of compiled into an internal optimized format and then evaluated sort of like an interpreter, within an interpreter, so you’ve got two levels of interpretation going on.

Josh Birk:
Gotcha.

Paul Prescod:
Its modern computer that’s still fast enough that even with two levels of interpretation I can generate a lot of information very, very quickly.

Josh Birk:
Nice. To kind of put a wrap around the role of the opensource community, but you mentioned this started with an opensource sprint, you’ve mentioned that people are using pole requests and things like that to increase the number of things that can be faked in the recipes themselves. Just give me the summary statement of how involved the community is in producing a project like this?

Paul Prescod:
Yeah, well I mean it definitely varies from individual to individual. I’d say there’s not too many people doing check-ins yet at least to the main Snowfakery code base. More often when it comes to the main Python code base, they were contributing either requirements like through ideas and I do brainstorm ideas with the community regularly in Slack and [Powervest 00:29:24] Hub and Trailblazer community. Then also they might be able to do a bug fix.

Josh Birk:
Gotcha.

Paul Prescod:
Implementing a brand new feature, we haven’t really onboarded a lot of people to that level. Then the other thing that they can of course contribute, documentation and recipes themselves. That’s actually… Because I’m not an expert in every domain of course, I know little bits about education domain, but I don’t have internalized the whole education data architecture. So, the experts in that that focus on the recipes that were late to that. Then when someone else comes along and a brand new edition of Snowfakery, they don’t have to imagine from a blank slate. They say, “Oh, I’ve got 90% of what I need in this EDA recipe. I’ll just add my custom objects to it.”

Josh Birk:
Gotcha.

Paul Prescod:
Or even included as we described before.

Josh Birk:
Got it. Nice. Okay, so this is all online. Documentation is online. I think your road map’s online too, right?

Paul Prescod:
Yeah, yeah a lot of it’s expressed in GitHub Issues, yeah.

Josh Birk:
Got it. What are some of the other highlights that are coming out with 2.0?

Paul Prescod:
As I mentioned, a multi-push. That’s where that’s one of the two big ones. The other big one is the ability to… So with Snowfakery 1, the model was that in all of these like a blank slate because it was designed primarily for performance testing and you can just delete all the data, repopulate it and run new tests. With Snowfakery 2.0, it can actually pull in information, especially IDs, from the org and connect information in your recipe to information that already exists in the org. It doesn’t have to be a blank slate anymore, which is really powerful when you have pipelines of tools, different other tools are loading data that maybe that you’ve written by hand. Or basically data that comes from somewhere else.

Paul Prescod:
Sales people are increasingly interested in Snowfakery of sales engineers, of course, are getting increasingly interested in Snowfakery because of this capacity to “Well, I’ve already got this data that I hand created three years ago, but now I want to scale it up to show a dashboard, or to show some visualization at scale.” So, Snowfakery can be used in that context as well. That’s also where a lot of the really sophisticated fake data accuracy type of stuff comes in handy to make it… The sales engineers are the most picky about “It doesn’t make sense that if the stage is in this field-”

Josh Birk:
Right.

Paul Prescod:
“And the date needs to be this. Three objects down, that would need to be in this state if that’s in that state,” and so forth. So, they push the boundaries of the conditional logic in the coordination.

Josh Birk:
That’s our show. Now, we will have links in the show notes, of course, to the Snowfakery project up on GitHub as well as some articles that Paul has written on the subject. Now before we go, I did ask after Paul’s favorite nontechnical hobby.

Paul Prescod:
Well, I live in the beautiful Vancouver, so we like to get outside and camping. We actually camped across Canada. I mentioned that I took a sabbatical at one point and we camped across Canada. That was awesome.

Josh Birk:
I want to thank Paul for the great conversation and information, and as always, I want to thank you for listening. Now if you want to learn more about this show, head on over to Developer.Salesforce.com/podcast, where you can hear all the episodes, see those show notes, and have links to your favorite podcast service. Thanks again everybody, I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.