Salesforce Data Integrity Webinar

It's live streamed to YouTube.

Let's see here if I can see that. We've got people on. So it looks like it's slow. The number of participants is growing quickly. So I'm just gonna let Zoom do its thing for a moment. Welcome everybody who's here already. We're just waiting for other participants to get in.

We'll just give it a couple more seconds and we'll do introductions and so forth.

Okay, that looks like we kind of installed the number of participants. That means everybody who is waiting has gotten in and I'm sure more will join as we keep going.

But I want to welcome everybody to the first X Force Data Summit webinar. This is building off the X Force Data Summit, which was a virtual conference that we held.

We is X Plenty, we're a company that makes ETL tools and one of our targets and is Salesforce. And essentially, what we're trying to do is is have discussions and other virtual events in this time where a lot of people are locked down where we can talk about all kinds of different Salesforce topics. So today I'm going to start with this agenda, we're going do some introductions, and then we're going to deal with some data integrity content topics.

Best practice for data gathering, data cleanup and deduplication, data enrichment. Unfortunately, the person who was the expert on that Jeremy Boudinay was unable to make it at the last minute today. So maybe I'll say something on data enrichment. I'm sure it'll be much less interesting than anything Jeremy's gonna say.

Then we'll go to back up to recovery and Salesforce in the enterprise. And by that, I mean, basically places people are using Salesforce as a single source truth. So what does it mean to be a good data integrity steward in that environment? So we begin with introductions.

And when you introduce yourself, if you have a hair curling, hopefully hair curling interesting war story to tell, That's welcome. If you don't, that's fine too. Maybe just tell us a little about yourself. I'm a start with Stan Ebnau from a company called Plauti.

Yeah. Thank you, Leonard.

Welcome, everyone.

My name is Stan. I'm the CEO and founder of Plauti, a company based in the Netherlands. We create two applications for Salesforce. They are on the AppExchange. It's called duplicate check for Salesforce and record validation for Salesforce.

And we do, of course, data management and data quality. Our duplicate check is all about finding duplicates and record validation. It's all about validating your existing data if if the address is correct, if the phone number is correct, of the postal address, of course.

And when when I really get excited about data quality was when I was doing some work for Procter and Gamble.

They were having their global customer data center or customer contact center based on Salesforce and their in Service Cloud, and they were giving out coupons for free diapers, promotion packs, basically, or batteries, etcetera.

And people were just so, yeah, how do you call it, creative about how to send those, coupons in with different addresses and, basically, the same address. But that's all about data quality. So the the ROI on return on investment on the data quality tool, but only for that was immense.

And that's when we really want well, data quality was the thing there to basically, you know, stop the the fraud of people, getting a lot of free packages and free promotions. So that's really when I was excited about doing data quality for Salesforce.

I think that's all for my introduction.

Thanks, Dan. We're gonna head to Andrea now tell us a little about yourself and if you have any data quality stories to tell.

Sure, my name is Andrea Hall. I'm the manager of our implementation team at FormAssembly. FormAssembly is a data collection tool, a form building data collection tool. Our biggest integration is with Salesforce.

I'll tell a story that we actually see quite often within our Salesforce connector, we allow for and or logic when you're looking up records to either create or update those records. And every once in a while we'll see a customer that doesn't really realize their lookup is actually using all and logic rather than a combination. So for example, they're trying to look up a contact based on last name and email or last name and mobile phone number or last name and home phone. But what they don't realize when they're setting it up is that they actually have and logic throughout all of that. So the connector being to match on all of those fields, nine times out of ten, that results in no record being found. It's not gonna match on all of that unless you have a contact who's keeping everything up to date.

And every so often this just happens to coincide with a form that is expecting a lot of responses once they release it. So that usually means they're expecting anywhere from a few hundred to a few thousand responses in those first few hours. And that leaves them with a few hundred to a few thousand duplicate records in Salesforce.

Luckily, they're usually able to just remove all those duplicates that get created. And then your data is actually stored in FormAssembly so we can go through and help them get their connector configured correctly and reprocess all of them. But it usually does cause just a little bit of a stirrup right there within the first few hours.

Yeah, duplicates.

Thank you, Andrea.

The final our final panelist is Matt Kennedy from own backup.

Tell us about yourself, Matt.

Yeah, thanks, Leonard. So as you said, Matt, my name is Matt Kennedy, director or partner enablement here at own backup.

I've been in the Salesforce ecosystem since about two thousand and nine. Salesforce Certified Admin, I got a lot of years of developer experience. I'm also a user group leader here in New Jersey and been with Own Backup the last three and a half years. Initially as a sales engineer, now I switched over to the Alliance team.

So technical resource working with a lot of partners working with customers. And I think, you know, we have lots of stories because we're backing up over two thousand Salesforce instances. But the one that I the one that scares me the most is is one of the customers who we were working with, a company called Yadkin Bank. They've since been acquired by another banking company.

But when you think about banks working on the Salesforce platform, right, I know you're going to talk later about system of record source of truth, right? You think about a loan and a loan record within Salesforce is not just one record. Usually there's lots of information that's associated with that loan. You're putting all kinds of application forms and everything associated with that.

They had an integration that was running with Informatica, you know, another ETL tool and integration was supposed to update these records. Well, of updating forty five thousand loan collateral records, it deleted them.

Now just think about that. That's forty five thousand records that were deleted plus all the information associated with them. So fortunately, they were using our tool and able to recover all that. But if they didn't have a backup solution in place, imagine the damage that would inflict on their system.

Agreed.

I'm gonna I'm gonna get to our first first question here. And it's for it's for it's about data gathering best practices.

What are the main gotchas to avoid when gathering data from a web form for use in Salesforce? I'm gonna shoot that to Andrea but everybody else can chime in if you've seen web forms gathering data for Salesforce since that's definitely a common use case.

Awesome. I have a couple points on best practices when you're looking for form tools to send your data into Salesforce. The first one is to make sure that all of your form field validations align with your Salesforce validation. So I'm not just talking about making sure a phone number is formatted in the correct way in the same way throughout all your records. But also, if an opportunity stage moves to closed one, then this field is required and things like that. You wanna make sure that your form tool is able to match all those validations and all those complexities. And then this will ensure that the data that you're actually sending into Salesforce is in the same format and all of your data is collected correctly every single time.

The second one would be to make sure there's a spam prevention solution and that you enable that whenever it's possible. And this will minimize the possibility of sending hundreds of thousands of spam responses into Salesforce. I've also seen some customers that will leave that off of their forms and they have a connector set up to create a new contact every time the form submitted and they wake up the next morning at eight am and have two hundred thousand spam responses inside of their Salesforce environment. So that's never fun. You wanna make sure that's always enabled whenever you can. FormAssembly offers Google reCAPTCHA for on all of our plans to help alleviate some of those issues.

Next would be, go ahead.

I was just gonna ask, it seems like reCAPTCHA is the gold standard. It's the only one I see anymore.

You guys feel that way too?

I do. Yes, I have to fill that out on a lot of websites. Click all the stop signs.

Right, right. Well, they have that magic one where they just click it, it figures you out the truth.

Yeah, mean, I don't know exactly how that works.

Watch us through the webcam maybe, I don't know.

The next one is duplicate management. Just make sure you keep that kind of top of mind, not only when you're choosing your form solution, but when you're building out your web forms as well.

When you're sending your data into Salesforce, you want to make sure you're considering all the audiences that you're going to be collecting that data from.

And then with that, you have to consider if you're going to be creating new records every time updating existing records, or maybe a combination of both. So our connector does allow you to just create new Salesforce records, update Salesforce records, just do a lookup to find something that might be related and things like that. And this will eliminate a lot of possible duplicates that you see with form tools that only offer standard create options.

And then the last one is the ability to pre fill existing information into a form.

If the ability is there, definitely do it. There's a lot higher rate of completion when somebody has a form that's half filled out for them already. The best example of this is a stay in touch form. Your form respondents are way more likely to give you up to date information when everything's filled in and all they have to do is look that over and make sure it's still accurate and hit submit. Your data is a lot more likely to stay clean and up to date.

Somebody in the audience, Iago asked, you know, what your take is on too many versus too few form fields. And you know, I think what he's trying to get at is that is what do you find that the threshold for people just abandoning a form is when they when they fill it out?

I think it depends on the type of form. So like, for example, I've seen bank applications that have, let's say ten pages, but on each of those ten pages, you know, there's maybe a maximum of twenty fields, and ten of those fields are conditional based on whether you said yes or no to a different question. So I think the key is actually to just organize them.

Any fields that go together, put those into groups and kind of visually show that they go together, make sure that any logic is in place. So if someone doesn't have to fill out a field, rather than saying if you answered yes, please explain you can trigger those conditionally behind the scene and things like that. And then another great option is if you have some type of save and resume feature to enable that on longer forms that way if someone does get tired of filling it out in one sitting, they can save it and come back to it the next day.

Are you finding Andrea that the email would be the primary key or using multiple like if you're pre populated in those forms, what are you using as your lookups?

It depends on where how somebody is getting to the form. So we see a lot of people who will send out like stay in touch emails from Salesforce. And in that case, you can actually attach like the contact ID or an account ID to the URL and use that as your main parameter in the lookup.

And then I see other people who do kind of a two form process where they'll have to put in maybe first name, last name, email, and then it will query Salesforce to look for the rest of your information and pull that into the second form.

Awesome.

I have to say I just I just worked with a client that was using WordPress, a WordPress form, you know, just whatever, you know, there's one hundred of them. And you just don't, you know, the ability to reach into Salesforce and populate the form just doesn't exist on a lot of these low end form solutions. And that's a real, to me that's a real impediment to user acceptance and quality data.

Oh, absolutely. It can be very powerful.

All right. Well, else on forum on web gathering or we're gonna watch me screw up the PowerPoint here. Here we go. Let's see what's next.

That was data gathering best practices.

Here's one for Stan, but everybody else can can chip in if you've done this before.

What's your take on Salesforce native native duplicate management versus apps like demand tools and duplicate check?

Yeah. Yeah.

And so there are a lot of Duplicate check is much better.

Is that your take?

Of course.

Now and it really depends on on what your goal is with duplicates and and data management. So if your goal is to if if it's Salesforce, you're a sales organized tool just for meetings, etcetera, so basically sales, then you typically a simple duplicate management system is then okay for you. So preventing, when you're entering new records in the sales or that you have sort of prevention mechanism, and that's about it, then sales or duplicate management is probably the right fit for you because Salesforce duplicate management can can give you that. But if you're working with forms like, FormAssembly or even the standard web forms Salesforce offers or if you have a marketing automation tool behind Salesforce, Pardo, HubSpot, Marketing Cloud, it doesn't really matter which one, then Salesforce is gonna be, the customer three sixty platform, the the one record, the the how do you call it?

Then you need much more than the standard Salesforce duplicate management tools.

Then you need batch batch processing. Then you need API insert protection. Then you need because all those marketing clouds and all those integrations into your Salesforce system, of course, can create records, can update records, can do whatever they want. And in the case of, Andrea, just where you have the email address or even the ID, then that's not an issue. But if you don't have that information, then you're probably gonna create duplicate records. And one example is one of our biggest customers is Education First.

They have, lead generation on the website. They have around ten to twenty thousand new leads each day.

And their goal is to, call each one of them because they have offices around the world, within five minutes.

But one person is gonna, hit that submit button on the website two or three times because they want different brochures, different folders, and they don't want to have a team calling that person two or three times. So within one minute after that submit button, they need to have to be duplicate checked, or you can't do that with standard sales for duplicate management.

That's just impossible. So it's really depending on on the goal you're having with duplicate management, how much records you have, how many influx of records you have. It's it's what the tool you need.

That's interesting. Is anybody else having anything to add about duplicate management?

Would just add to that because I think it's and what Stan's talking about, it's really critical when you think about the amount of data that could be coming in, If you're running, maybe you had a webinar like this, right? And afterwards, there's a series of leads that come out of it and they're all getting loaded in.

We look at it as really you want to make sure that you have a baseline of your data. So having a backup in place before any kind of large integration of new information or any kind of duplication process. And then you want to have a backup during and after so you can compare different points in time. Because if something does go wrong, right, if you bring in a large number of records and the data was formatted incorrectly, you want to be able to undo that without having your production org have a bunch of bad information in it. Right?

Absolutely. Because we have plenty examples Yeah. Fortunately, who have used our tool with an incorrect setup or something and or where the intern is is made responsible for cleaning up the duplicates.

Right.

So instead of that being, yeah, a manual process for an intern to go in and spend hours of time trying to figure out what was changed incorrectly to be able to automate that, yeah, and compare it to all that.

We really have examples that they database of, let's say, ten thousand accounts where an intern hit the wrong button and we they only had two thousand left.

So and then you really need a backup because Yes.

Backup.

So that's absolutely true. And it's all around our app. When you hit a merge or an auto merge, that's and merge cannot be undone. It's really loud everywhere.

Right.

Right.

So absolutely.

Yeah. I mean I mean, one strategy if you don't have a full backup is to, you know, mark whatever's coming in from some third party source, but that doesn't deal with any of the use cases that's been just brought up.

And so let's look at the standards. If you look at standard Salesforce duplicate management, that's not really geared about enterprise usage, data governorship. So you don't have any audit tracking. You don't any logging of what's happening inside your system, who is merging what, which is merge what, etcetera. So so if you have an enterprise environment with a lot of customizations, you need one of our tools, ours, of course, or one of the competitors, But you need an you need a better duplicate management system than the standard Salesforce. And if you look at why Salesforce built the duplicate management system, it's because the competitors already have all that.

So, Microsoft CRM already had something like that. But especially for the GDPR compliant bit, you need a proper duplicate management tool if you want to be GDPR compliant.

No. That's that's definitely true, Stan. I think your story is kinda interesting, right? Because it's not it's not just about, you know, merging of leads and finding things that are getting put together. Like you said, the the same persons on that website maybe hit submit on three different pages right now, if different people are contacting that person, that's going to be a really bad experience. So the fact that your tool can recognize that and kind of merge those on the spot is really going to save you know, that customer a lot of a lot of aggravation, but same thing with GDPR, right? If somebody puts in a request to be forgotten, and you've marked that lead and nobody should be contacting them anymore.

And there was a duplicate and now all of sudden they're being contacted, that's going to create a problem.

And that's a big fine in the European Union.

Those are some interesting cases. Now we're gonna since we touched on backup, we'll get into Matthew's world, Matt's world here and we'll talk about the key factors that kind of Salesforce customers should be thinking about when they're formulating their backup strategy.

That's that's a good question. It's interesting. I mean, obviously, in these times, we're all social distancing, right? I mean, normally, next week would be New York City World Tour.

I haven't missed that event in five years and it's going to be it's going be weird not to be there, right. But when we're out at these events and people are coming out to our booth, that's usually the first thing we get is they're kind of looking at us like, why do I need a backup solution? My data is in Salesforce. It's in the cloud.

It's secure. And we're like, that's completely true. Like you can always log into Salesforce ninety nine point nine nine nine percent of the time you're going be able to log in and access your data as it exists right now.

But to Stan's point, if you're doing a merge to Andrew's point, if you're doing forms and you're bringing in a lot of data, if something goes wrong, how do you roll back to what you had yesterday or the day before? So that's really what we talk about when we talk to Salesforce customers. It's not about the Salesforce platform, the platform secure your data is protected. But as an end user, you have the ability to modify your data, not just your data, but also your metadata.

You think of admins going in, changing profiles, permission sets, workflows. We're doing daily snapshots of all the configuration files as well. So if something goes wrong, they can roll that back. So usually the question I ask people when they come into the booth is kind of like, have you ever suffered a data loss?

And the most common reply we get is, I don't think so. And that's not where you want to be, right? You want to know, you want to be confident that you have a baseline. And you can see on a daily basis what's being added, what's being changed, what's being deleted to be able to roll back, all right?

You don't want to have that unknown about what's in your Salesforce instance.

So I mean, of the key things in any backup strategy is checkpoints, right? That you have, like, you're going to go and do some big data change that you want to be able to take a checkpoint, you're talking about logging, but I assume like own backup and probably the other big competitors probably have the ability to say I'm about to do something really dangerous.

I want to have a checkpoint.

So our solution by default is doing a once automated daily backup. So usually overnight, we're doing complete backup of the whole environment. But we do have the ability either through the user interface or through our API to do on demand backup. So we'll tell people, hey, you're about to run a large deployment or you're running an integration.

Force a backup right before that. So even if you have the backup from last night, you've usually been working all day, force a backup late in the afternoon and have another restore point. If you think about the native Salesforce solutions, the out of the box is a weekly export. So you think about maybe on a Sunday, you're running a full dump of your org, but then you could lose up to seven days worth of information, right?

And there really is no restore capabilities. It's basically just a copy of your data.

Yeah, it's terrible. It's a terrible I mean, I used to do that because we didn't have a backup solution like, well, some disaster strikes. I guess I'll figure out what to do with this. I just got. Yeah, yeah.

And I think that's the key differentiator we try to make with people is it's not just backup, right? Having a copy of your data is important, but the frequency of those backups, right? If you're doing it daily or if you're doing it hourly, But the hard part is the comparison and the restore, right? If something goes wrong, to be able to look at two different points in time and analyze and identify exactly what changed, so then you can selectively recover, right? You don't want to be a time machine and say, hey, something went wrong today on a Thursday. I need to roll my whole org back to my weekly export from Sunday. I want to go in and just fix this merge that I did or maybe this import that I did and undo that but leave everything else intact.

And especially when so the we hit, of course, once a month, basically, we get a customer deleting something on accident.

Right.

And now the Salesforce itself is removing the, I think, the capability for data restore, which they had. So backing up is more and more important because there's no fail safe anymore.

Right. They have something Salesforce has something called the data recovery service that is retiring at the end of July. Yeah.

One of the things not to I know that there are other backup solutions on the market that do this and I don't want to like put you on the spot. But one of the things that one can do with that one might want to do also is you have some data that essentially you want to archive.

You don't want it in Salesforce, but you want it someplace you can get at it. Is that something that own backup? I mean, I think that's a desirable.

I don't know if that's quite the backup tool.

No, it's a great question. I we didn't have a chance to talk about this before the webinar. That's what our core solution is really about backup and restore. But we did release another application last year.

It's on the Salesforce app exchange called own backup archiver. And it does exactly what you described, which is basically for compliance requirements. You know, maybe you have older data, you could have case information, right, that goes back years. And you only need to keep maybe two or three years worth of that history.

You can set up policies on our archiver application that says any closed case older than two years old, pull it out of Salesforce, put it in this off-site storage, reduce your storage in Salesforce, improve performance, but yet have the ability to resurface that data in Salesforce as a related list. So it'd be view only, but But if you went to an account, you could see active cases versus archive cases.

And so where are those archive cases stored in like s three or?

Yeah, we do AWS s three primarily.

That's new. I hadn't seen your product before, but I hadn't seen that.

We see some clients, you know, as you're using Salesforce, storage goes up, right? And if you're getting more and more information, it's a way to cut down some of that storage.

That's also pretty useful if you're looking at duplicates because, comparing things with four years back is really useful, of course. So if if things are more archived, your your duplicate checking will be quicker as well and your validation will be quicker. So archiving is for us as well, it's key there.

Absolutely. Because I could say as you guys are adding more and more information, right, that data grows, your searches or reports, everything can slow down potentially.

Yeah, absolutely. So if you're looking at millions of records and search should still be there within within the second, of course.

Why wouldn't it be?

All right, switching gears a little bit. This is just a general question. Getting to the what we see with our customers is a lot of Salesforce as single source of truth or as source of truth for a certain set of data in the enterprise, often customer data, which makes sense, right? So as a player in the enterprise, you're a producer and a consumer, right?

And so as a consumer, how do you make sure your data starts and stays clean as you import it? And as a producer, how do you how do you be sure the customer understands and uses your data correctly? That's a question as big as I'll I'll outdoors. But if you guys have some insight in that, please chime in.

For us, the the most important thing in this aspect is define, what your data is. Because if you don't define it what it is and what you want to do with it, it's difficult to to basically tell the business or even the end users or what they need to do with it. And and if you define what it is, you can also define the quality rules. And so an email address should also always be this or and phone number should always be formatted like that or, this is, this is mandatory or not and and those kind of things. And, also, define what you don't need because you can store a lot of information which you don't need, of course.

And and only look at the things you need for a data perspective.

So I think that's very important if you start doing some data management, data integrity stuff from from our standpoint. That's the first step. Define what you have, then define the protection rules, and then do the cleanup.

And then monitor monitor, of course, all around the globe, because you need to know if you're if it's still okay or not. Forget you get that enterprise feeling, define in in the definition phase, you always define where is my data coming from, which integrations do I have. Is it form assembly? Is it any other tool? Define what comes in, defines what you want to do with it, and then start acting on it.

But that's it's also the refinement phase is the most important here.

I think it goes back to the question I had for Andrew earlier. It's it's about the uniqueness, right? What is the primary key of that data? And as she said, if you can look that up in Salesforce and pre populate that form with a lot of the information, your quality of data is gonna be so much better going in, right? You're not filling in a bunch of blank fields. You have it pre populated. I think that's really the power of their solution.

Yeah, for sure. I think another big piece too of collecting data is not only making sure that it's clean, but that you're collecting it in a secure way and you're meeting all of your compliances like you're talking about GDPR and HIPAA compliance and things like that.

And we try to make that easy for our customers. All of our plans are compliant with GDPR. They're compliant PCI DSS level one, our compliance cloud is compliant with HIPAA.

And then on top of that, we try to make it flexible so that you can pre fill in any data that you already have existing and things like that, and then push it to any CRM or database, the main one being Salesforce, but we have quite a few customers that push it other places.

And then with a few simple settings in your account, you can wipe that data from FormAssembly. So you can store anything that you want to that's been collected from your forms but you also have the power to remove it so that you remain compliant. If your data should only be held in Salesforce, then you can wipe an entire response, you can wipe just those sensitive fields, things like that. So I think that's another big piece of collecting data as well.

Yeah, I think if you look at the alternative, if it's an Excel spreadsheet or a CSV file, there's no controls, right? It's free text and you're gonna be missing all the validation rules, you're gonna be not hitting the drop downs with the proper values, right? You're going to get all kinds of duplicates that are going have to be cleaned up afterwards.

Yeah.

Change go back a little bit. There's an audience question about you, Matt.

Basically asking how long does it take to implement archiving solution once you've got your data policies in place and a rough idea of the steps involved.

Yeah, it's not too bad. I mean, basically it's a managed package on the AppExchange. So like I said, you just go to Salesforce AppExchange, search for it.

And when it installs, it's basically creating the structure of the archiver. At that point, it's really up to you to define the policies. And policies are pretty straightforward. They can run daily, weekly, monthly, but you pick the object you want the policy to run against.

Like I said, you know, it's tasks or cases or whatever object you're looking to archive, and then you just set up the filtering criteria. So very simply say, you know, like I mentioned earlier, whether it's based on close date or status or whatever it might be, So the cases that meet that criteria will then be archived out. And I saw that the follow-up question was, was the work on the AWS side, the storage is included with the application. So there is no configuration of AWS.

We take care of all that for you.

That's nice.

And then they just Okay, and then the retrieve.

Yeah. So basically, when you do that, we have a component, we have a lightning component that you can drop onto the forum. And like I said, it'll just be a related list.

It knows what objects it's associated with. So if they were tasks on accounts, you could drop that onto the accounts and it would just pull up as a related list.

And the last question was about external objects.

But my understanding of external objects, if they'd be backed up in whatever system the external object lives.

Yeah, I don't I'm not sure exactly what he means, but if he wants to clarify that because we'll we have access to anything through the Salesforce API. So if it's standard custom objects, if it's big objects, we can access all that data.

If it's outside of Salesforce, then yeah, that would be different in terms of a lightning web component used to display the data.

Great. Thanks.

All right. On to the next.

We're gonna have another one for Andrea here.

I think we answered this a bit, but maybe you want to go into a little bit more.

You know, what do you what do I expect? What should I expect it from a good form tool in terms of data validation? I think you've touched on, but also, you know, a classic one is you have picklist that's based on a picklist and Salesforce and you need to keep that in sync. What can tools like FormAssembly offer? And what do you think best practices are there?

Yeah.

So I did touch on validations. I'll just say, you know, one more quick thing. I think we talked about some built in validations, you know, phone numbers, emails, a number validation, things like that. But you also want to look for the ability to be able to define custom validations. So with FormAssembly, we offer a couple of different options here. The most popular one is validating with a regular expression.

And this allows you to actually validate almost anything. I mean, you can get a specific as you want it to with a very specific string or you can require a specific date format within a certain range, things like that. So that's another key feature to look out for with validations.

And then in terms of Salesforce pick list versus form pick list, it's always good if you can find a form tool that can pull your pick list from Salesforce. So having that ability to direct your form pick list over to Salesforce and pull those values in is going to alleviate a lot of errors in Salesforce or like Inform Assembly. If you get an error in Salesforce, it actually comes back to the form as well. And so you'll see that error in both places. Sometimes something as simple as a space or even I've seen capitalizations, maybe a state is capitalized in Salesforce and not capitalized in a form and that will throw it off. So being able to pull those pick list values in is very important and will alleviate a lot of pain points when you're trying to clean up your data and collect it in a very clean way.

And then another thing that FormAssembly can do as well with dynamic pick list is actually query Salesforce to pull in a list of records. So for instance, you can have a form, let's say you have a household account and you send that form over to that family, you can have a pick list that actually shows all the different contacts within that account. And when they click on the contact, then that will actually pre fill their information into the form. So you can like check multiple people in one form and that can be very powerful as well and making sure that all of your contacts they associated to accounts and things like that.

So in the case of a pick list that is updated rarely, does form assembly check that every time or do you have some kind of process where it watches and sees that that pick list metadata to see if that pick list was changed or it does pull that in every single time.

So with our pick list, you authenticate it right on the form over Salesforce and you choose your object and your pick list that you want to associate that to. And then every time the form loads, it pulls in the newest values.

So whether you're changing it once a year or once a week, it's gonna pull in those values every time.

And so on the data validation, usually there's two tiers of data validation. The simple stuff sometimes is done client side, right? You have the JavaScript that it's it's supposed to be a number and somebody put in a letter or whatever.

Do you have that two tiered thing or is all your stuff making a round trip to get validated?

What exactly do you mean by two tier?

Well, what I mean is like in the browser, if you have to put in a phone number and you start typing a letter, it just won't let you do it. It'll automatically say, oh, I want a number here and it doesn't go back to Salesforce or back to the server to do that. It's all in the client on your web browser.

Gotcha. Yeah, we do. We have a couple of different options. So all of our, all of the validations that you set within form assembly will run like when you hit the next page or the submit button and it won't process onto Salesforce or whatever other CRM you might be sending it to until all of your form assembly validations are met. And then we do have a few other ones where you can require you know strictly numbers or something like that. And it will only allow you to type in numbers.

And then once it passes form assembly, if you do get a validation error from Salesforce, you can trigger that to show on your form as well. So then it's submitting to form assembly but it's not submitting to Salesforce until that data is actually the way that it needs to be.

Yeah, that's good. All right, let's see what's next here.

The next one is going to be more on workflow for dedupe.

What this is for Stan.

Knowing that one size doesn't fit all, do you have one or more examples of a good data quality workflow what you would recommend people do that to, you know, for certain application for a certain type of customer, give us an example of going through and you know, first you do this to check your data, then you do that, if that makes sense.

Got it. There's one global, workflow which works for basically everyone, and and that's, prevent first, clean up after.

So that's that's the global one which you can do every that same goes for form form assembly. They prevent first from entering, information you don't want. And then we're we have tools to clean that up if if if there is already dirty data. So that's the most important thing. But if you, look at what I think of data quality so data management is often an administrator task.

A consultant sales administrator is is tasked to clean up our database.

And I think that that's not we as a company think that that's not the way to go, because I think data and especially data quality is a shared responsibility.

So you should be able to ask your sales sales guy or help your sales guy or your marketing guy or women, to create data quality with each other.

So if they are entering new data, they should be helped in that by entering correct data, so validations, a direct prevention pop up. But, also, if they're looking at a record, they need to be they they need to have the tools to directly clean it up. So they don't have to send it over to an administrator where the administrator has to go in again and do the validations, etcetera. It's still salesperson is already already on that record. If he if he do two clicks and he can clean it up, everyone is happy.

So my goal and and I think our company goals is to to make sure that the data quality and the cleaning up process of data is a shared responsibility. And I think if you implement that in your company, that everyone is responsible for their data.

And I think the data quality itself will go up quite easily because it's your responsibility. It's not someone else's down deep in the tech department which you can blame. No. You have to blame yourself if if the email is not delivered.

So think if if you look at sort of broader perspective, that's my advice to companies, on how to implement data quality and data management is make make the team responsible, not make someone else behind the desk responsible.

It's a good point, Stan. A of people think about it like it's an admin's job to go clean up all this data. But to your point, and I think Salesforce has done a much better job with Lightning, is that when salespeople are entering a new lead, it should pop up and say, hey. This looks really similar to a lead you already have. And at that point, they can do that evaluation, right, and prevent that duplicate from ever being created in the first place.

Absolutely. Yeah.

And we also have the tools and so we have that tool, of course, as well, but we also have the tools that if you're and Salesforce has it as well. If you look at a certain record, you can directly see if the email address is correct, phone number is correct, postal address is correct. And you can with one click, you can revalidate it. So if it's incorrect, you can just say click validate and revalidate that information. And then, yeah, then it's clean. So everyone wins there.

It results in much better quality when the person that's familiar with that account can make a correction. Right? Yeah.

So I think that's that's the we call that within the company. We call that data happiness.

So I like that.

Yeah. So we we we are trying to broadcast the message of data happiness across the Salesforce ecosystem.

That sounds like a T shirt coming out soon.

Yeah. Or a plush doll. One of the Exactly.

Alright. We've got one more. I think we're we're getting towards the end of this. And we're gonna ask it's gonna be last but not least is gonna be math. Ask a question here.

And here it is. How do you tell you're gonna love this, Matt. How do you tell a customer with a zero budget? Do you have a better than nothing approach?

Basically, what do you tell a customer has a zero budget? In other words, if you don't have any money, is there something that you can do? And the second one is, given that they have a zero, but nobody has a zero budget for anything. How do you convince management to invest in backup in the cloud to keep their data safe?

It's your wrap on that.

Okay, I do. I actually just threw a link in the chat because I think it's a great question, right? It's and we talked about it earlier. If nothing else, you need to take ownership of your data and use the default solution from the weekly exports, right? So Salesforce does have some tools that are built into the application. As an admin, you can schedule that weekly export to run and download that information in a manual basis every week. There's no cost to that except for obviously the admin's time.

If that's too much, at least do data loader, at least do reports on some kind of a regular basis and extract that information. We talked about it like, you know your system's good right now and you're about to run a big integration.

We'll do an export first. Take the existing data with a report and at least get a copy of it so if something goes wrong. Maybe when you're running that job, keep track of the batch, know what was inserted so you can undo it if you ever needed to. So I think that's the key is even if you have zero budget, it is still your responsibility. And the blog post that I sent just kind of talks about the out of the box solutions, right? And that you as the admin should know what's in your system and just just take that ownership.

And the second question is, how do you what what's your elevator pitch to management to sell them a backup solution when they believe that the cloud keeps everything safe?

So that's great. I mean, we talked about it earlier. It's really about that your instance is safe except from yourself, right? That's the biggest thing that we see is human inflicted data loss, right?

Is that somebody does an account merge and then they realize they made a mistake. How do you undo it? They run a large integration through an ATL tool and it updates thousands of records or potentially deletes information. How do you undo that?

So we always ask, you know, what is your Salesforce data worth? If you're putting in a lot of information, you're running your business out of Salesforce, what would happen if that data went missing? What is that worth? And then, you know, does that correspond to a purchase of a proper solution to protect that data?

Right. It's a great way to put it. Well, I want to Did anybody else want to chip in on that?

Yeah. And for personal experience, I'm I'm the we're not the biggest company, so I'm I'm the administrator of our own Salesforce instance.

And we I think last year, we we we bought a solution for backup backing up because everything which we do is is in Salesforce. So and if if our Salesforce gets corrupted, the data is or if something happens, then our business is is out. It's just like that. So when I realized that, then it was easy to to make the money available to to invest in that.

Right. If it's gonna be a single source of truth, you don't wanna lose your truth.

You're Yeah. Absolutely. So and and especially, we have a lot of customers where where Salesforce is the single source of truth, the only source of truth when Right. Then there's no option to not have a backup, basically.

All right. We're forty eight minutes in here, which I thought we gonna reschedule this for about forty five minutes or so. So I think that's pretty much gonna wrap it up. I wanna thank Stan, Andrea and Matthew for participating and very interesting answers to some possibly interesting questions that I threw together. And I'd like to thank the audience for your questions and your attention.

And we're gonna keep doing these webinars and anybody who attended this, of course, be getting plenty of information from us about what we're doing next. So thanks. Thanks, everybody. And we'll see you next time, hopefully.

And one last thing, following up with everyone with an email with just some more information about the webinar and from our lovely speakers.

So keep your eye on your inbox. Thanks.

Great. That's Casey, by the way. He's the man behind the curtain. He did a great job. Thanks everybody.

Thanks guys.

Thank you.

‍