Salesforce Data Migration & Attribute-Driven Design Publish

Just give you a quick intro. So today, we're gonna be talking about Salesforce data migrations and attribute driven design. If you don't know what that is, attribute driven design, don't worry. You will very well by the end of this talk.

And when we do the QA at the end, if you have more general data related questions, you know, feel free to pop them into the QA even if they're not necessarily, directly related to data migrations.

So a bit about myself. So this year, it's actually this month even, I founded Gluon Digital.

So we're a firm that's wholly dedicated to partnering with Salesforce SIs and help them with all their data needs.

I've been in the Salesforce ecosystem for well over five years. I've worked with a lot of lot of SIs.

And the common theme is it doesn't even matter what my role is in that firm is they're having issues with their data migrations, they're having issues, building complex, integrations with Salesforce. And I've I've helped them shore that up, particularly with the smaller prop partners.

So, I ran the the data team at Capgemini Invent. I worked with Silverline a bit. And when I was at Playdiv as director of professional services, I helped build out their their, data team there, as well.

So a couple of years ago, about two years ago, right at the end of, twenty eighteen, early twenty nineteen, I got my book published, Developing Data Migrations with Salesforce, by APress, available everywhere on Amazon. It really, really takes you through, everything you need to know about Salesforce and data migrations and integrations, and it starts from the fundamentals of understanding traditional data management, how Salesforce's approach to data management, and then kinda moves on to, best practices. And a lot of what I'm talking about today, comes from content, in this book.

Okay. So let's give you guys another second or two or minute or two, thirty seconds to complete that poll.

And then can we pop it up?

What did this? Hosts and panelists cannot vote? That's not fair.

Dave, I think it was it wasn't showing until just about now so why don't we give it another minute and let people vote.

Okay, cool.

Tell us more about yourself.

Yeah, like I said, live in Brooklyn. Got four kids, beautiful wife.

Things haven't been better. Alright, let's move on. We'll come back to the poll, maybe maybe towards the end. Okay.

I'm gonna close this.

Alright. Cool.

Okay. So if you were new to data migrations, particularly with Salesforce, you'd probably start by you know going to Google and you type in a search something like how do you migrate data to Salesforce. And you're gonna come across something like this, right.

And you'll see, you know, probably hundreds of articles that tell you to to do a process similar to this. It tells you to plan your data migration, analyze the data source, put together some kind of mapping document, extract the data from the source system into probably CSVs, and you want to transform the data so that it looks like Salesforce objects.

And then you will load the data into Salesforce.

Then you verify that everything looks good, and it seems pretty straightforward.

Okay. And this is essentially the standard approach, for migrating data to Salesforce. Right? And it looks pretty straightforward. It's fairly easy now. But what did this actually look like in practice?

So the first thing that we do is either we get into the database and we find some way to export the data as the CSVs or we ask the client to export the data and CSVs or if they have some legacy CRM system you'll tell them, hey maybe can you mock up some reports that are exportable to CSVs and try to capture all your data points that way and then please give us the csvs.

Then we take those CSVs and even though we asked for CSVs, we really wanted them in Excel. So the first thing we do is we convert them to Excel.

We massage the data a bit, maybe add a column, maybe do some VLOOKUP type work, and then we convert the data, the Excel files back to CSVs doing a file save as.

Then we take that CSV, the first one, We use the open up, the Apex Data Loader, we configure our mapping, and we run that through the Apex Data Loader. And that spits out two files, one that's an error file and one that's the success file. And the success file tells us all of the records that went into Salesforce. And then the error file is gonna tell us all of the files that errored out. We then take the error file, we open it up in Excel, convert it to Excel, we fix the bad data, then we save it back at the CSV, then we run it through the data loader again and we find out if the if there are no errors and then we'll continually do that until we get back no errors only success files.

And then we will move on to our next file. We take the next CSV, we open it in in Excel, we'll build some kind of vlookups to get the Salesforce IDs from the success files files. You got six success files because you had errors, then you merge them together. You get a master success file. You'll then do you know, build v lookups, to get Salesforce IDs, and then we merge that, convert it back to CSV, and then we do that process again. And if you have, you know, eight or nine objects to load, you would go through this iterative approach, eight or nine eight or nine times.

Now, this process, if you look at it, it it seems quite insane or crazy, and it seems like a lot of work, and it absolutely is. But if you talk to people who are in the Salesforce world, this eventually is the standard, and this is how people are doing it.

Now the good news is that, in years since I've started since I've started, in kind of promoting best practices here, and I'm not taking the credit for this. It's probably just a coincidence. I have seen quite a bit of improvement in this, but it's still not nearly where it needs to get.

So okay. Great. Let's move on.

Okay. So if you look at these two processes, right, we have something that looks like a very straightforward, easy, let's, you know, get our data, we extract it, use data load, into something that's like a an absolutely insane iterative painful process.

But the truth is the truth is that this is not wrong. The second process that we're looking at the screen, you know, really is exactly the same as the first process, it's just more detailed.

And it's always the details that wind up wind up, you know, killing us, right? This is to say the the devil is into the details.

So let's dive into why exactly this process is so bad, and how we ended up in the situation where so much is lost, in translation.

Okay. So why is this so bad?

And the number one reason why this is so bad is because it works.

And when it works, people people keep doing it.

And they they kind of do it three times and they feel great about it. And then they'll go online and then author an article about how to do it. And then this kind of knowledge is perforated all online, telling you that this is the right way to do things. So what happens is, this works great, particularly for a small migration, right? I'm loading, you know, a hundred accounts and four hundred contacts and there are just a couple of basic fields. I do that once, I do it three times, hey, I'm feeling great.

I'm able to do data migrations really well.

But then what happens is you try to scale it up and this doesn't only fail when you scale up. It absolutely fails catastrophically to the point that almost the entire Salesforce project, could fail in it. Now when I'm talking scale, I'm talking three points primarily. One more data.

So you're no longer dealing with a few hundred records, you're dealing with thousands of records, potentially hundreds of thousands of records, maybe even millions. You're dealing with more objects. So now I'm not dealing with, you know, accounts, contacts, opportunities. I'm dealing with accounts, contacts, opportunities, activity, activity relationships, meaning multiple activities.

I might now be doing the Salesforce email object model which has email recipients and an email and a and a shadow task.

It might be going back to account contact relations where we have to create inverses.

And you can easily see how this can get up to to not to mention the custom objects, right, how we can get up to twenty five, thirty objects.

And then as you introduce more objects and more data, what happens is we introduce more transformations. So it's like we wanna change these pick list values because we were doing it bad before and we had too many of them, we wanna simplify. Right? So the complexity goes up exponentially, and then again you end up with a failure. So why exactly we fail?

One, Excel begins to crawl, so it slows you down simply because you try to open the CSV file and Excel chokes and will often crash. Excel starts modifying your data in ways that although you might have expected and you can deal with it on small values becomes a major headache that the volume goes up. It does things like dropping zeros from your zip codes. I've seen it add decimals to external IDs and then those don't match because loaded one object and it's like twenty nine point zero zero, and the other object is just twenty nine, and the external ID is a string in Salesforce. It becomes incredibly time consuming.

So I'm I need to do, you know, eighteen objects in order.

Each object had its own set of transformations that you need to do in Excel manually. So you end up taking lots of notes and I'm very careful to take notes.

And I end up with a checklist of like eight pages long with load accounts, open it up in Excel, do these seven transformations, clean up this column, make this vlookup, convert these pick list values, change the camel case, right, and have to do that every time we run the migration.

Then great, you got through the migration, now you test it, the client, you know, may find mistakes. So they want to give you a new set of files because the original original set of file is old or missing data and they send you new csvs and guess what the csv files are completely different than the first set of files that they gave you.

Often the client can't deliver clean CSVs because they just don't have the skill set to do so.

Every time we need to do a round of QA, I need to redo, you know, four hundred manual transformations.

And again, we end up with this giant runbook on how to do that, and that's assuming you're organized.

So often what happens is you you do your data migration, you have the client test it, the client reports a defect. There is no way in heck because of this one defect, I'm gonna rerun this entire data migration. It takes two days.

So you just patch the data, then you forget to write that additional transformation into your your migration runbook, and then you run the next round. And guess what? The same defect showed up because this is not an automated process. This is a human manual process.

So so what what essentially happens is you're QA ing a human process, and human processes don't don't run consistently time and time again, except with extensive practice. And then you end up having the same defects show up again, often you go live and then the client was like, well, we fixed all the defects, why are they showing up again, you know, when we did this migration to production.

So so you cause frustration on your client side.

Defects can often be found months after go live and there's not much you can do about it because you don't have a way to fix the data. And then often minor defects can take hours and hours and hours to fix and often, require a ton of of data analysis.

Right? And again, it's just an overall bad experience for your client, and it frustrates the internal sales team. And this is one of the reasons why so many Salesforce consultants absolutely hate, doing data migrations.

Okay. Attribute driven design.

Hey. We got our poll results.

So wow. Thirty three percent of us have been, spared the headache of, of actually having to be involved in it.

And it looks like it's pretty evenly evenly spread between, happy and unhappy, which is the which is a bit a bit surprising, honestly. But that's good news.

So twenty two percent The ones who haven't had a big one are the ones that are It's very possible.

There was you're going to be very unhappy or moderately.

Yeah. Well, we did say relatively large.

Okay, cool.

Okay, so, what is attribute driven design, or ADD? I love to call it ADD because it sounds like attention deficit disorder, which is what people who, who need attribute driven design.

They're the kind of people who need it, people like me.

So, yeah, so attribute driven design is essentially where you you come up with your or you build your methodology and your software architecture around the attributes that you want to achieve, right? And when we're defining the set of attributes, we want to to define them in such a way that it enforces the quality of both the process and the data. The the end game here is not just great, I want to have a data migration, and I want the data in Salesforce to be of good quality and to match the legacy system.

But we also want the process to be one that that is relatively painless, you know, and, you know, and drives the the quality of the data.

So this is not a project management methodology or, you know, or or a software architecture. It's more of a philosophy.

Right? So it is contribute with, you know, agile waterfall and all the attributes.

So many of you guys have heard of of Simon Sinek.

If you haven't you really, really, really should listen to him or read him book read his books the guys the guy's absolutely brilliant.

Generally talks a lot about what motivates people, and what makes things great. And he re authored this book, Start With Why. He there's a TED talk on it, which I highly recommend.

You you listen to it's about twenty minutes. So essentially what Simon says is is that the why is why you're doing something and the and what are your end goals. And if you start with why, that should determine how you're going to do it and then ultimately what you're gonna do, right? So if I come up with the attributes for what's gonna be a great data migration, then I know my why, and then I'm gonna take my how and my what, how exactly am I gonna execute on that data migration, and what my elven goal is gonna be, and it's gonna be able to tie that back to the why. And when I have these fundamental principles, and everything that I'm doing ties back to those principles, I know that this is gonna be done in a good way.

Right?

Okay.

So this is how I define the six attributes of a good data migration.

So the the first attribute and by far the most important attribute is well planned. I'm gonna quickly go through this and then we're gonna discuss them each in detail on the following on the following slides. So most important attribute is well planned, that's why it's in the center. I'm gonna talk through that more in a moment. Next, it needs to be automated and what that means is I need to be able to redo it without much effort.

It needs to be controlled, reversible, repairable, and testable. So let's do a deeper dive into each of these. Okay. So number one, well planned. So again, well planned by far the most important attribute.

And the reason for that is that any of the other five attributes can be compensated through the use of planning.

But nothing will ever contemplate for a bad plan or even worse a no plan, right? So for example, if you look at our our our previous example where we had you know this eight page manual process, essentially what we're doing is taking all the attributes every step of them, and putting a planning process in place to make sure that it goes well. So we're essentially trying to offload all the other five attributes into the planning attribute and basically plan for every possible scenario, take detailed notes, and do everything with planning. So though you still need to plan, right?

But you want to have a good plan, not a plan of do everything manual. But when you can't meet one of the other attributes, then we can go back and plan for how we're gonna manage that edge case. Okay. The second attribute is automated, and that means it's redoable.

So so if I need to rerun my migration, you want it to be as close to one click as possible, end to end. So that means the data extraction, the data transformation, and the data loading is wholly one click. And truth be told, I do a lot of the planning automated as well. I have code that automates my mapping document.

It automates a lot of my data, data analysis. It's a little bit off topic for this talk, but perhaps we can we can discuss it a bit in the q a sessions, if it comes up. Right? But again, the goal is to get as closely to one quick, as possible.

Automation eliminates human error and saves time.

I cannot stress this enough, automation saves time. When I when I talk to people about automating their data migrations, I get a lot a lot of pushback that says, come on, we're only gonna run this once, I don't have time to write all this code.

And my answer is always automation saves time. It does not, it does not add time.

And the reason for that is because people look at data migrations and they think it's one time run code, but it's really not one time run code because it's one time run to production code. But I still have to do QA, I still have to do UAT and then production. So that's a minimum of three runs of your data migration, if you're doing things properly. And if you have a sophisticated client, that's not risk averse, and wants to do a lot of testing, you probably need two or three rounds of QA, maybe two or three rounds of of UAT. So you're talking easily easily in the five or six runs of that. And if you have it automated, it it saves you so much time.

And, of course, again eliminates human error because there's consistencies in your run. And you're not you're not worried about an error that you fixed in the previous migration popping up again. Okay. Controlled is in terms of what data is being pushed.

So if I'm doing a data migration, and I'm wholly automating it, we've been partially automating it, I I want to be able to control what data is being pushed. And what that allows me to do is perform rapid fix and test cycles. So if I needed to load, let's say five hundred thousand accounts, I don't want to have to load five hundred thousand accounts, wait forty minutes, go in and validate my data. I want to be able to quickly add a small parameter, push it a thousand accounts, validate, fix my transformation code, run, validate, fix.

That's how developers like to work.

Right? So it it takes the ease of fixing fixing my code, and I can do these rapid tests and fix cycles. There's also this additional benefit of if you're dealing with partial smaller environments, let's say a dev sandbox or a partial sandbox or even a scratch org, right, I can do a mini data migration to those orgs, and again do some testing there outside of the production environment even if they don't necessarily have a full sandbox because I'm able to control, the data sets. And again, these attributes apply to each other, so the control should be automated as well.

Okay.

Just a point of note for each of these six attributes. Right? Incremental improvements are key. They make a big difference.

You might not be able to get to partial to wholly automated, but if you can get partially automated, it's better than none. If you can get fifty percent, it's better than forty percent. If you can get eighty percent, it's better than fifty percent. Right?

If you can get partially controlled, it's better than no control. Right? So incremental improvements. Nobody's saying that you have to, you know, start from zero and get to a hundred overnight.

Okay.

Next up is reversible.

Reversible if the ability to undo immigration either partially or wholly and in a controlled and automated way.

Right? So I I migrated data, I want to run the next round even if no defects were tested, I want to do a no if not found. If I want to do a second round of QA, I should be able to back out of my migration, get the data back to its native state, have the client validate. Yeah, that's how we were then rerun the process again. And that's how you do proper testing. Right, if you're doing proper testing and if you're doing QA and you don't have a valid step starting point, how are they supposed to properly test the data?

So yeah, to just enable proper testing, and you don't have to wait for a full sandbox refresh, which we know can only be done once a month.

Okay. Repairable is to be able your ability to fix data in a very targeted way after mistake has been found. So I shouldn't have to I shouldn't have to run the entire data migration to fix a data point even though if it's wholly automated. So I go live three months from now like, hey, you missed the data point. I shouldn't have to run the whole migration and potentially override updated data. I want to be able to fix that data and that means we need easy ways to know what records were updated, how they were updated, and when and tie them back to the source data so that we can do very, very targeted fixes.

And then testability, that's the ability for our users or for our QA team or for ourselves to to test the data in a relatively easy way. Right? So data needs to be traceable back to the source and we should be able to easily isolate what data has been updated when. So, right, we can run through our test scripts, and it's really just as simple as opening the the Salesforce, opening the legacy system, looking at the UI, validating the data, or or running queries against it. Okay.

So, essentially, if you look back at the original diagram, right, the process didn't change. Right? Even if we apply all of these six attributes, the the overall process didn't change. What really changed here is heavy amount of planning, and then we take these six attributes and we're applying them to each step here. So six attributes apply to the planning stage, to the extraction stage, right? The extraction needs to be automated, needs to be testable.

The the transformation stage also, again, automated, testable, reversible if we need to undo it. And then again, the load, reasons I'm not going to get into now, I'm not, I'm not a big fan of the data loader. I feel, it, it enforces bad habits.

So ideally, you should use an ETL tool. Data loader, bad.

And then the validation as well, you know, we should apply the six attributes. And essentially, when we're aiming for one click, the extraction to the load, we want that to be fully automated, in a single click process.

Okay.

Awesome. Okay. So, in my book, I go through these six attributes. I think I have, depends how you count, a chapter and a half on them, maybe two chapters.

And then the next chapter in my book is I go through, okay, now that you define your attributes, what do those attributes mean in in practice? And you'll find that those attributes drive a whole set of detailed best practices, right? But the the attribute is the why, and then the best practice becomes the how and the what, right?

So the in the book, I think I go through forty of them or so. I list a couple of them, a couple of them out here. I'll talk through one or two of them. If anyone had a question on a specific one of these, throw it in the in the questions window, and we'll get to it shortly in the in the q a cycle. I'll be more than happy to talk through, any one of these or any other best practices, during the q a time.

So, just to pick one or two of these, fix code dot not data. This is one of my favorites. It's one of the bigger mistakes that people make is, right, they get the extracts in CSVs, they launch in Excel, and then they clean the data there manually.

What I'm saying is expect that you're gonna get a new cut of data, the new cut of data is going to have the same data issues potentially against new records or different records. So we should code that into our transformation layer to fix the data. So for example, if I wanna apply some kind of phone number formatting, so that the phone numbers look right in classic, it's kind of was dealt with in lightning, which is nice. I would put that in my fixed in my transformation layer.

If I'm finding that emails are erroring out because Salesforce validation is failing those records, I put code in the transformation layer that checks the email address. If it's not valid, don't load the email or I put it into a secondary field called bad email. And then it can be fixed in Salesforce later. The the admin can run a report and say, oh, these were records where they couldn't load the email address into the email field because it couldn't it couldn't fit.

I have I have a code that actually, like, fixes a lot of the common mistakes in emails. Like, they copied and pasted with a bracket, the, the greater than sign, less than sign, or or they they put, you know, funny characters in the email.

So that's like one of the best practice that you learn. And if you if you can easily tie that back to vary a couple of the attributes, one, obviously automation. Right? I'm not fixing data because that will never end. I'm fixing the code that's moving the data. Right?

Yeah. Again, fits back to repairability because all I gotta do is fix my transformation layer, rerun the code, and then it will fix the the damaged the damaged data.

Start early hits just about every one of these. So start early, again, this is a common mistake people make it they think data migration I got to finish the Salesforce build first and we get to the data migration last. Wholly disagree with that. We want to start early, look at the data, start our data mapping exercises.

What often happens is you'll find business edge cases that then feed into, the discovery sessions. So you'll find by looking at their old legacy data, you'll often find, again, the data telling a different story than what the user is telling you that they do. And maybe it's because their process changed, but they never updated the data. But in data migration, you have to handle that.

So by starting early gives you time to proper plan against all of these all of these kinds of issues. And it also allows you to know you know what kind of issues you're going to you're going to face.

Okay. Awesome. So that summarizes it as you can imagine is talking for nearly forty minutes now this barely scratches the surface on the subject. If you want to know more feel free to reach out to me davidglowandigital dot com.

My blog Salesforce Data Blog, I talk a lot a lot a lot about this stuff. My post regularly on LinkedIn and my book Developing Data Migrations and, and Integrations with Salesforce is available everywhere including Amazon, Barnes and Nobles, yada yada yada yada.

Awesome.

Hey, David. Here's our first I'm gonna move us along because we just have a few minutes left.

Here's the first question.

If looking at merging Salesforce orgs together

When it comes to an external ID in the records floating into the target org, do you find it acceptable to use the existing record ID from the retiring org? Is that external ID? Would you as a best practice assign an entirely new UUID to those incoming records it would associate to both the source org record and the target org org record?

So the answer is absolutely use the existing ID. So keep in mind that the external ID serves two purposes. It's not just to tie the record back and to allow for upserts, it's also to allow testability so that I can find the record in the legacy system so that we can compare the two records.

So yeah, there's no reason to generate IDs unless you absolutely absolutely have to. You want to maintain that linkage, that linkage long term.

Yes.

Great.

Well, here's another one. How much time should you spend on planning? Some believe too much planning is a waste of time.

Those people are wrong. No. So the answer is there's no easy answer. So you kind of just know.

So happens is there's a balance between I can plan for every possibility and this goes for everything in life not just data migrations. I can plan for every possibility and then I won't affect I won't get hit with side effects or the repercussions of missing a possibility. But at some point you hit a level where the repercussions for what you didn't plan for is not as bad as the time spent planning for it, right? So you wanna find the balance where the risk of something going wrong doesn't outweigh the time spent planning for it, right?

So sure, should I plan like I live in New York, we don't get hit by earthquakes. So I'm not planning when I'm building my house for an earthquake because I'm willing to accept that risk. So it's really it's really a risk a risk question of you know how how how much risk am I willing to take? And then I only risks that are deemed unacceptable or at least where the time to plan it completely outweighs the, you know, the potential you know impact of that risk.

I hope that answers that question.

Yeah, I think it did. Next question, can you go into more detail as to why logging everything, run times and failures is such a benefit?

So I didn't say to log everything but Tell us more about what you what you should log then.

So it's definitely it's definitely for integrations, and I know it's a little bit off topic, it's more important to log your start times, your end times, you definitely need row level error logs so you know which records are failing and why. And then you can deal with those. For data migrations, you run them three four times you kind of know it I don't think it pays to invest that much time in in the logging.

But at a bare minimum you need to know how long it takes because I need to plan my go live and it's probably going to be after hours. And I want to know do I need to peep you know do I need to plan a whole weekend or I need to plan you know an evening? One of the nice things about wholly automating these things is one they go much faster. But two, like I rarely work weekends doing data migrations. It's usually an afternoon, or a Sunday morning. I'm a Sabbath observer so I can't work on Saturdays, and it makes you know this kind of stuff makes it really really easy to do a go live over you know over a weekend.

But you definitely definitely need to log row level errors.

And I do log the start and end times of the jobs.

And my ETL tools allow for a lot more logging capability but for data migrations like task level run logs running I really rarely log that kind of stuff.

Again you're just so intimate with it and and it's not going to be maintained it's not like you know three years from now we want to go look how did the performance of my job denigrate over the past three years, when did it denigrate, what code was released that caused it to denigrate on that you know that same day.

So yeah, much much more important for an integration than a than a data migration. But again, it's exactly the same thing with the planning question, right? You want to log up into the point where you're getting diminishing returns that it doesn't it doesn't pay.

Yep. Our next question is how much of the challenge in data migration is the human element of getting a company's team on board for proper UAT testing and accepting downtime during cutover?

So, again, wholly automated, I can plan because I know exactly how long it's gonna take.

So once you know the client is much more susceptible, right? In and truth be told, even me as a consultant, I'm very happy to do it off hours because it's it's like no joke. I wrap up work, I bring my laptop in front of the TV, I start the job and I check on it every twenty minutes. It's run so many times that it doesn't it doesn't really fail.

Training the client to do proper QA, is a difficult one. It it really is. So the you know, I I ask a lot of questions on the data mapping, and that's one of the reasons we start early. So I know this sounds nuts because nobody in the industry does this except for people I've worked with on my team.

When we start UAT, all the data is in the system. So when they're UAT ing the Salesforce functionality, they're UAT ing the data migration with real data at the same time.

So they go hand in hand. It's not a separate UAT, and it doesn't extend the timeline, and it really gets them to get a good sense of how the system how the system will. And then just in doing that day in day out, they can check all of their edge cases, all the weird opportunities, all of their various record types that we're migrating to, and they're testing the Salesforce code with real data. It adds so much so much so much value to the to the Salesforce testing side of things as well, not just data.

And then they they just pick up on the anomalies.

So And that's because you're creating an org you're doing it when you're doing a migration you've created a new org and your automated stuff just pushes everything in there, right?

So often doing the migration to the same org that the build is happening in.

If it's a greenfield system off and that's production, which is fine because I can back out, right? So I back out and then we're ready to go live, I get a new data set, run the same automations, load the data into the same production org. Work.

Yeah.

Great, okay that makes sense.

That was the last, I think that's the last audience question but I had a couple. Why do you do holding accounts in Coder, why and how do you do that?

Sorry, why do I You had a yeah, one of your one of the bullet points was doing holding accounts in code.

Yeah, yeah, That happens all the time. So what happens is there then there's a scenario that says if the legacy system didn't enforce that I have to have an account for a con for a contact that allows me to have, let's say, person accounts. But in Salesforce, we're moving to a model where we where we don't have person accounts.

Or we have invalid email addresses and there's a need to say, in this scenario we're going to put these contacts in this account called, you know, to be fixed or to be matched or whatever, right? So that's what I'm calling a holding account. Now what happens is every freaking single time that you don't create it in code, somebody forgets to do it because it's somebody stepped to create it manually, and then all of these records fail. Not only that, if I want to push to another dev environment or to a different sandbox, I got to continually remember to manually create this step and and why should you right just add it to your add it to your code that creates that as part of the account load.

Yep that makes sense.

Yeah.

David we're out of time, It's been great. Thank you so much. Thank you to the audience for participating. And for those of you that are part of the conference, we've got one more presentation, five o'clock or five o'clock my time, top of the hour.

And I would invite you all to attend. Thanks again, David.

And see you.

Awesome. Yeah, thank you for having me. Was an absolute pleasure.

‍