Ask Me Anything: CRM Sync & Troubleshooting

Okay. Thank you all so much for joining us today. Welcome to the ask me anything on the CRM sync and troubleshooting.

We are excited to get started with you all and share some great insights into how you can troubleshoot between your CRM and SalesLoft.

So we have a number of topics for you guys, and we're looking forward to getting started.

So today, your hosts are myself, Anna Scott. I'm a senior solutions architect on the customer success side, and Savannah Dunn, who is a senior solutions architect on the professional services side.

As we go through this session, our biggest desire is to help you with any kind of burning questions that you have. So please use the q and a box to submit any questions that you have around your CRM sync and troubleshooting, and we'll look forward to answering those. In the meantime, we have some, great topics that we've lined up around common issues that we see. So we'll be happy to walk through those. But please, again, feel free to pop in any questions, and we'll be we'll look forward to answering those as well.

Okay.

Looks like we might have gotten a question.

So okay. We have a question around how can we prevent call recordings from syncing to our CRM.

So by default, call recordings will sync over to your CRM as long as the call is synced over into your CRM. So if you're syncing calls into Salesforce, for example, the call recording, as long as it's done inside of SalesLoft, will push over into Salesforce.

So you have a couple of options around this.

Option one would be to limit the recordings that you're doing if you're not comfortable with them going into Salesforce.

Option two would be to limit, what is actually logged inside of your Salesforce. So you do have the option to turn off call logging inside of your Salesforce if you'd like. And then option three would be creating a Salesforce automation around deleting the comments of any call task that's created from SalesLoft. That would be more on the Salesforce side, and that would require work on your end to do. But that is something that I know some clients have done in the past.

Definitely a good question, though.

Okay. While we wait for more questions to come in, we'll go through some of the most common topics that we get.

And what we wanna start with today is, a topic around, creating leads inside of your CRM from SalesLoft. So I'm gonna go ahead and share my screen and walk through what this looks like and some of the common things that we see.

So, hopefully, everyone can see my screen, and I'm gonna walk through a very common automation role here. So we oftentimes get asked about how we can create of the CRM, whether that's Dynamics, Salesforce, HubSpot.

And the most common way to do that is by using an automation role so that when a person is not found in my CRM, you have the option to either create a lead or create a contact.

There's a lot of different criteria you can layer onto this. So if you only want to create people in Salesforce, if they have an email, first name, last name, or if they're at a certain stage or status, there's a lot of things that you can do around that to limit who's automatically created inside of your CRM. But we what we often find from clients is they get really stuck because they'll create an automation rule that's very broad where their desire would be for everyone who exists in SalesLoft to be automatically created in Salesforce. They'll be able to see that the automation role is firing quite a bit. However, those leads are not ultimately created inside of Salesforce. So I'm gonna walk you through, why that typically happens and how you can kind of uncover that. So the first thing I'm gonna do is show you I have this rule completely saved inside of my instance.

I'm gonna go in and create a person, and I'm gonna do dave at barry strop dot com.

And I'll just put in just Dave here, and I'll create this record. So, typically, when a record is created and it's created inside of your CRM, you would see either the the Dynamics, HubSpot, or Salesforce logo indicating that there's a linked record. This record does not have any indication of that, so I'm gonna start by looking to see if the automation rule fired.

And the way that I'm going to do that is by clicking into the automation rule and then viewing the logs.

When I look at the logs, I can see actually, let's just refresh this.

This is a good example where, we've attempted to create the person inside of the CRM. However, there's an error here, which is simply saying that there's a required field missing, which is last name. So what's really important to remember about an automation rule like this is that although in SalesLoft, we will fire the automation rule to create the person inside of your CRM, we might be able to fire that automation rule successfully. It does not mean that your CRM is able to receive that record.

So that means that if you have any kind of required criteria around email being present or a status being present or a source being present, if that record doesn't have that inside of SalesLoft and that's a required field inside of Salesforce, like you saw with my record, there's no last name, That unfortunately means that we've attempted to create it, but we won't ultimately be able to create that record. You can typically see that in the automation rule logs where you see this required field missing last name.

And you can use this to kind of go in and correct any kind of missing pieces of information. But what's really important to note about this automation rule in particular is if you're familiar with an automation rule around when a person changes inside of SalesLoft, that automation rule is firing constantly.

The automation rule around when a person is not found in my CRM only fires underneath four different circumstances. The first would be if the person is created for the first time, we will look to see if they exist in Salesforce. If they do not, we will fire this automation rule. When an activity is run, we would fire this automation rule. If a failed activity is retried, we would fire this in automation rule. Or if you went into a person and you attempted to manually link them, we would fire this automation rule. So let's look for Dave here.

My required field that I was missing, last name, so we'll add in Dave Ferry.

We'll save this. And just making this change again so that it's updated to meet that criteria that's needed inside of my Salesforce is not sufficient enough to get this automation rule of creating this lead inside of sales Salesforce to occur. So, again, it's when a person's first created, when activity is done, when activity is retried, or you can manually go in and hit link to CRM.

So you'll get this message that says we for Dave Barry.

And when we go to our automation rules, this will take about a minute or so, we would be able to see that this automation will fired. So, again, this would take about a minute, but that would trigger this automation rule to fire. And because we now have that critical piece of information of last name, it would be able to be pushed through and retried.

So feel free to drop questions around that, and we'll just give this a second, and we'll pass it over to Savannah. Okay. Yeah. So we could create lead is now in progress. If I click on the person, we can see I've got my little Salesforce icon, and I was able to successfully create this person as a lead. So, hopefully, that makes sense. Let us know any questions that you have around this or if you've encountered this yourself, and I'll pass it over to Savannah for our next topic.

Thanks, Anna.

Very helpful information.

K. It looks like I can share my screen now. Give it just a second to see if any other questions come through about that automation rule before we start our next topic, which is account management.

Go ahead and start sharing my screen.

It's like I'm having issues getting it to share. One second.

K.

I do see we have a question.

Oh, Mimi, that's you. Great.

K. Here we go. Get my screens worked out now. Okay. So my topic is account management. So we're going to talk about how people can be linked to accounts and what you need to do inside of SalesLoft to ensure that they are linked to accounts correctly.

So first, we will go to a person. So I'll show you here inside of SalesLoft. You can see that this is a person inside of SalesLoft. A person can either be a lead or a contact. You'll always see if they're a lead or a contact based off this button here, that exists under that person record.

When you scroll down to the person, you can see the person fields that a person has here.

So whatever field you have mapped within field configuration in SalesLoft or any custom fields that you have just directly inside of SalesLoft, those would show here. And then at the bottom, we have account details. So this is one of the reasons that it's helpful to make sure that people are linked to accounts correctly. It's because when you're looking at a person, you can see those account fields when you're looking at that record, and then you can also use those account fields for that linked person in an email, such as a a dynamic tag.

So if you go to email and you're looking for a dynamic tag, that person is linked to an account, then you can pull in account fields too. So having accounts brought into SalesLoft can be very beneficial. Our goal when we're creating accounts in SalesLoft is to create parity between SalesLoft and your CRM. So however your CRM records are linked to accounts in your CRM, that's what we'd like to mirror inside of SalesLoft.

So if a contact is linked to an account, a contact is linked to an account inside of SalesLoft as well. I'll show you some settings that, are critical for that to happen. So if we go into settings and then look at field configuration here, you can see under person fields that there is a field mapping for account CRM ID.

This account CRM ID is where you can determine how contacts or even leads are linked to an account. So by default, SalesLoft has, account CRM ID or sorry. Salesforce has account CRM ID on contacts, contacts, you know, or child records of an account. So all of those contacts can be linked to an account in Salesforce, and that's just a standard account ID field. So when you're importing a contact into SalesLoft, we're looking at that account ID on that contact, and then we're bringing over that account as well.

We have a lot of customers who also have a custom setup in Salesforce where a lead may link be linked to an account as well.

If that's the case for your team, then this is also a field you can map under the lead object.

So you can map your leads to accounts. That way when you're importing leads into Salesloft, we bring over that associated account into Salesloft as well.

When you're importing contacts and leads into SalesLoft, the way that that account gets created is by importing that lead to that contact. So every time you're importing a lead or a contact their associated account and creating them. The information that we bring over for that account is based off of your account field configuration.

So there are two fields that we always have to have for your account field configuration. That's account name, which is pretty standard in Salesforce to have an account name. So that account name will sync over. But then account domain is something that we need as well. A lot of customers will map this to account website, and that works really well. It does have to be a unique value inside of SalesLoft.

But just as of, this summer, we had a product release where if you do not have website as a u unique value, SalesLoft will do some back end work to make sure that it is a unique value by using that account CRM ID. That way your accounts can all be created. So just something to be aware of. You may have talked with someone at SalesLoft in the past where this always had to be a unique value. That is still the case. But in case it's not a unique value for you in Salesforce, we are doing that back end work to ensure it's a unique value inside of SalesLoft.

So as long as you have account name and account domain, that account is going to be created inside of Salesforce SalesLoft.

That's how you create parity between SalesLoft and Salesforce to ensure that every record that has an account in Salesforce also has an account in SalesLoft.

The next piece of that is if you go to the account management tab, sometimes customers would like to have accounts created directly in SalesLoft that are not always present in Sales Force. So maybe you're just using a third party to create records inside of SalesLoft, and you want an account created directly in SalesLoft, but may maybe not necessarily inside of Salesforce.

This is where you can use some fallback account linking logic. So if if you click edit here, you can see there are fallbacks of criteria to link people with accounts for when standard CRM data isn't available.

So if we say if account CRM ID is unavailable, link people to accounts by And this use case for this would maybe be if leads are leads do not have an account in Salesforce, the native setup, but you want them to have an account inside of SalesLoft.

So if there's no account CRM ID on that lead, let's select a fallback. You could choose that fallback to be the company name from the person record. So we're going to take the company name from that record, that lead that exists, and we're going to assume that the company name is also the account name and create that account for that lead.

You could also use another fallback here. So if company website there is no company name on that record. So maybe you're just creating a record directly inside of SalesLoft.

We could choose to take that company website from the person record and create, an account based off of that company website.

And then lastly, we have here person email domain from the person record. So if there is no company name, company website, or person email domain or sorry. Company name, company website, we could use that person's email domain to create an account and use that information there.

One thing to note is when we are doing that, we if you use person email domain, we will not do that for records that have a free domain. So if their email is at Gmail or at Yahoo or at MSN, we will not use that to create accounts because their account name would be Gmail, and we don't want to, group records together based off of free domains.

The last setting here is creating accounts for people. So when there is no count to link upon import, this is where you're indicating that you want SalesLoft to create an account for those people. This is where you can choose again the fallback logic. This is what determines if they if they have an account created.

If you're ever seeing issues, so you think that, maybe your accounts in SalesLoft don't exactly align with your accounts inside of Salesforce, I would take a look at this page and see what settings you have enabled, and then feel free to reach out to your contact person at SalesLoft. And we can take a look and make sure that all the settings are correct, and we can help you, make sure that those are aligned according to your needs, if that would be helpful.

Alright. I'll stop sharing, see if there are any questions.

I think we're okay. And I'm I'm gonna, pop back over into SalesLoft, and I'm gonna talk about, a really common case that we hear about around aligning ownership between SalesLoft and Salesforce and some important technical aspects that I think are very good to know about.

So aligning ownership between SalesLoft and Salesforce is very helpful because it allows us to mirror what's happening in Salesforce. It allows for the automatic team cadences and assignee to be correct based off of Salesforce owner. There's just a lot of benefits to doing it.

It all starts with, the data point of the owner CRM ID being mapped inside of Salesforce through SalesLoft.

Now I have mine bidirectionally synced. If you can see this field, this is the owner CRM ID. This is how we would ingest who the owner is from the CRM.

And as I mentioned, I have it bidirectionally synced. I wanna take a moment to talk about the significance of this and when you would use this and when you might not wanna use this.

Typically, what we see is most teams would have this mapped strictly from the CRM into SalesLoft.

The reason for that is they want to be really conservative and ensure that there isn't any kind of ownership changes that occur in SalesLoft that could then be mirrored back in Salesforce.

And because of that hesitation, they map the CRM to SalesLoft as the owner CRM ID source of truth. And that's totally fine. We can certainly do that. The reason why I choose to have mine bidirectionally synced is because when we use an automation rule like the one I created before where we create the lead or we create a contact inside of the CRM, If we have this field bidirectionally mapped, what it allows us to do is pass over who that owner is inside of SalesLoft to the CRM, therefore, creating the record with the SalesLoft owner as the CRM record owner.

We will not actually be able to update who the owner is in Salesforce on an existing record based off of this field being bidirectionally mapped unless you have this field owner sync on, but I highly recommend turning it off because this is the field that would allow changes in ownership in SalesLoft to occur back inside of Salesforce.

We oftentimes see people turn on owner sync because they think that this is the best way for us to be able to copy ownership from Salesforce or HubSpot or Dynamics inside of SalesLoft when that is not necessarily the case. The way that we would actually recommend doing that is via an automation rule. And so I'm gonna start by making, the most basic automation rule that we recommend, and then I will, show you some iterations around that.

So the trigger that I'm going to start with is when a person changes in SalesLoft, which would constitute a person being created or any kind of record updates.

I am going to add in some criteria. Now sometimes we see this rule completely blank without any additional criteria. And what this is essentially saying is anytime a person changes, let's make sure that the SalesLoft owner is set to the CRM owner. The danger with adding in no criteria is that this rule is going to fire any time the record changes, which which in turn causes looping. It could prevent any automation rules that are lower down in the list of automation rules from firing. So you wanna add in criteria so that it's firing and staying relevant with any kind of owner changes, but it's not looping. So that's why the most common criteria that we see is when owner CRM ID is set or owner CRM ID has changed.

Oops. Has changed.

And what this is essentially saying is we want this automation rule to fire, but only if owner CRM ID is set for the first time, I. E. The record has been imported, or if the owner CRM ID has changed, I. E. It's gone from one value to another. At that point in time, do we want to set the sales left owner to the CRM owner? And sometimes we get questions because people will create this rule, but they will still see that there are a number of records that have ownership out of parity.

What this typically indicates, is that this rule was created after there were any kind of owner CRM ID sets or changes. So this rule is only kind of a good going forward rule. So it would address any kind of new records where the owner CRM ID is being set or any kind of records where the owner CRM ID has changed from one value to another. But if they're already sitting inside of your SalesLoft completely out of parity, that might be one of the rare cases where you want to remove any criteria around this, consider doing a data getting that SalesSoft owner and Salesforce owner aligned and then adding back in that criteria.

The next kind of question that we often get is, like, we want this rule to fire, but only if the owner is a SalesLoft owner. So this is how you would do that. You go owner CRM ID is SalesLoft user, which is a really great feature. And then you would add in a group so that owner CRM ID is set.

Owner CRM ID has changed, and I'm just going to change the operators here. So what this role is saying is if the owner CRM ID is a SalesLoft user, we want this role to fire, and we want it to fire anytime the owner CRM ID is set or anytime the owner CRM ID has changed.

Other variations on this that I think are nice, and I was actually just asked about this at a client call fifteen minutes before hopping on this, is I have a team where they do import a number of records, and those records are not always, owned by people who are SalesLoft users.

So they set up an automation role, and this is the second automation role that they have, in tandem with their just typical owner CRM ID is set. Owner CRM ID has changed. But they wanted to see anytime this owner owner CRM ID is not a SalesLoft user. Instead of setting the SalesLoft owner to a CRM owner, they want to set the SalesLoft owner to be a specific person. So this is another way that you can do this.

Last thing before I, move off of this topic is I did this based off of when a person changes in SalesLoft.

You would also need a separate rule for when an account changes in SalesLoft where you would use similar criteria if you'd like to align ownership on the account object between SalesLoft and your CRM as well. This is also one where you would need to make sure that owner CRM ID is mapped to your owner field that you'd like to reference inside of your CRM as well.

K.

So we'll take a second for any questions on that, and I'll pass it back over to Savannah.

Thanks, Anna. Appreciate the details. We'll move on to the next topic. So one of the common questions that we get when we are working with customers is when they have people that already exist inside of SalesLoft, but they are mapping a new field and field configuration, and the value is not coming over to SalesLoft. So I wanna spend a minute talking about that.

Let me pull up my screen share.

Keep having issues with this.

K. Let's see if this works.

K. So, again, as I mentioned, if one of the common questions we get is people already exist inside of SalesLoft, but I'm going in a field configuration. I'm mapping a new field, and I'm not seeing that value get synced to that record inside of SalesLoft. So let's take a look at this record here, Edna Frank as an example. You You can see here we show the title of a person underneath their person record. So, here you can see there is no title for Edna. If I go into edit the person details, I can see we have a field for title, but there is no value there.

The use case that I'm referencing here is let's say that I go in and I map title within Salesforce. So the person already exists inside of SalesLoft. I'm going to go ahead and map that as a field.

So let's just make that bidirectional since that's an open text field in Salesforce. We'll do it for leads as well.

So now I've mapped that field.

I'll click save.

I then go to that record inside of Salesforce.

Let's click back on this.

And I click into that contact, it takes me to this contact here. And you can see this contact here does actually have a title inside of Salesforce.

So I would expect that that question we get often is they would expect for that value to come over into SalesLoft immediately once that field has been mapped, but that's not the way that our CRM sync works today.

The way that our CRM sync works today is we are constantly pulling Salesforce for any changes that have been made on records.

So So because this Edna Frank has not actually had a change in Salesforce yet, our interval our polling intervals are not going to pick up that a new field has been mapped.

If we refresh the page here, you can see the field has been synced, but there is no value there.

What you'll then see is if I go into Aetna and if I were to make a change on this record in Salesforce so I'll take out, the comma there on the the title. If I click save, what I can then do is go into this record, Aetna, and we would expect to see this then sync over into SalesLoft. So if I go look at the CRM sync logs, we'll open up another tab so we can see.

Now you can see Edna Frank does have a title of VP technology, which is the value that was reflected inside of Salesforce.

If I refresh this page, you can see at eleven thirty one eastern, Salesforce sent over the value of VP technology.

So what this is showing us is that when you map a new field inside of SalesLoft, it's not automatically going to bring over all of those values for that new field that you map inside of SalesLoft.

What you're then going to have to do is force a change on that record inside of Salesforce.

The way there are several different ways you can force a change on a record. One of those is you can do what we did. We went and we edited a field, and, once we edited that field, that means that the last modified date and time on that record change in Salesforce, which means SalesLoft was able to see that value and bring that over into SalesLoft and update the field. Now that can be very hard to do at scale because that means going into each individual record and updating a field, on each individual record that you want the record that you want to sync into SalesLoft, which if you're mapping a field and you want all of your records to sync over, all of those fields to sync over, that can, be quite time consuming. So one of the things that we recommend is something that Anna mentioned, a data bump. So that may be a process that you're familiar with in your CRM.

What that entails is just doing an update on all of your records that need to sync over into SalesLoft inside of your CRM. So one of the ways that you can do that through Salesforce is if you actually use data loader and upload records through data loader or update records through data loader. You don't even actually have to change a field when you're using data loader. If you just upload records, or excuse me, update records, that will force a change on those records inside of Salesforce so then all of those fields could sync over.

That's a common thing that we recommend. Your organization, Mary, have a process for doing a data bump. A lot of organizations have an overnight process. It's constantly modifying records so that way, any integration synced with Salesforce can pull over those values. But something that we recommend is when you do map a new field, make sure you do a data bump inside of Salesforce so that field can come over into Salesloft.

Otherwise, it's not going to come over into Salesloft, until that record changes in Salesforce, which could take some time.

Hopefully, that gives you some more details about mapping a field.

See if there's any questions, and then, Anna, I'll get back to you.

Okay. So I'm gonna be taking us through, one of the most common activity failures.

Now this is something that we get questions about all of the time. So if you're not familiar with activity failures, if you go into, your SalesLoft and you look at the sync in this top right corner underneath this kind of l shape, what you'll see is any activity that was done inside of SalesLoft that did not make it over into your CRM. This is a really important section because, essentially, what it highlights is any kind of data that you might assume that you're getting inside of your CRM that you're actually not. Now there's a number of common errors that we see. I would say the most common error that we see is cannot find person inside of the CRM.

What that usually or what that does indicate is that the person exists as a record inside of SalesLoft, but there is no corresponding record with that email address inside of the CRM. So the activity is done in SalesLoft. There's no record to anchor that activity to the CRM. That one's pretty self explanatory.

This one is probably the next most common error that we see, and it's a little bit more complex. So I wanted to take some of this troubleshooting time to show you what it means and how you can fix it.

So looking at these error logs, you can see that, I'm getting this error, and it's saying invalid field, no such column, alt SalesLoft Cadence on the task object.

What this indicates is that the person who is doing the activity, in this case, Gray Poupon, does not have access to this field. Now that field might have been deleted and is still mapped in SalesLoft, but most commonly, it exists inside of the CRM, but there are not the proper permission sets for the user in order to be able to successfully push this activity over.

We see this error crop up in a couple of different contexts.

Typically, when a new field is mapped underneath our activity fields in field configuration, sometimes an admin will create a field, but they'll forget to assign the proper access to the profile or permission sets of the SalesLoft users. That's one context.

We also have our managed package, the SalesLoft insights dashboard that exists, for Salesforce users specifically.

Oftentimes, people will install that package, but depending on how conservative they are with their users inside of Salesforce, Again, this is a Salesforce specific package.

They might not have assigned out a proper permission set to give them access to those fields. So the end result of that is, typically again, this is results after mapping a new field, so people are excited because they assume that they'll be getting extra data inside of their Salesforce or their CRM.

But in reality, they are getting less. So the good news is with an activity failure, with an activity failure, once you correct the issue, you're able to push over that failed activity inside of your CRM.

I do wanna note that the date of the activity will reflect the date and time that the activity was done. However, the created date of that activity will be the date that it was retried inside of your CRM. So that's something important to know. So, again, looking here, it's saying the invalid field, the alt SalesLoft Cadence field name is not one where GreyBluePon has access. So the way that I'm going to fix this is I'm gonna head into Salesforce, which is the CRM that I am using, today, and I'm gonna go to my fields and relationships. Although, I will say this applies for all CRMs.

I'm gonna go into the alt sales loft cadence, and I'm gonna look at the field level security here.

And for my user profiles and generally just to keep it easy, you could see that this field is not visible. So I'm making it visible. I am saving it. And what that's going to allow me to do is retry these activities and get them pushed successfully into the CRM.

Now I did this on a field level depending on, the different profiles, permission sets that you are using inside of your CRM. You might need to address this in different places depending on the complexity. But the general principle of this field applies, which is you see that there is an invalid field. You know that the person doesn't have access.

You consider where they might need to have that access applied. So I'm going to go ahead, and I'm going to retry the sync of these twenty items.

It notes that one API call will be used as we push those through.

I'm gonna refresh it, and you can see all of those those twenty cleared out. I still have significantly more. I just selected twenty at a time. You can select by error theme. There's a number of ways that you can retry.

But was one where we weren't able to get, an activity over, and we can see that we were able to successfully once that, once we retried it. So that is, again, a really common acne error. Let us know if you have any questions around it.

Thanks, Anna.

K. I'm going to share my screen now, and we'll move on to our next topic.

Touched on this a little bit, so this will be a a quicker one. But, this is looking at our CRM sync settings and what our polling intervals look like. So once you're in CRM sync settings, there are several things here that you can adjust with your settings. We've talked about a few of them today.

If you go under sync management, there is a CRM sync connector organization and when your connection was established. We also have a CRM sync alert contact and then an inbound sync frequency. So just wanna walk through these settings today. So, enable using main CRM connector.

What this is showing me is who the main CRM connector is. So you can see here I've got a drop down of user SalesLoft users I can choose from. I'm choosing myself today, so this is, my main CRM connector.

What you will see here when you're looking at the main CRM connector is you are personally connected to CRM as savanna dot dun plus one at sales loft dot com.

What you have the option of doing is you can choose a SalesLoft user that then connects to an integration user that may connect between SalesLoft and Salesforce. So a lot of customers will have a a Salesforce user that's called, like, integrations at your organization dot com or something of that nature. What you can do is select a SalesLoft user who then will use the login credentials of that Salesforce username to establish that connection.

This connection is what allows data to sync bidirectionally between SalesLoft and your CRM. So, when you're choosing this, this applies for Dynamics as well if you're using Dynamics as your CRM. Once you're connected, you'll also see your organization's domain here. So if you have a my domain enabled or if you've got a custom domain, you would see that here once you are connected.

If you have this disabled, then we are not going to pull in changes that happen from Salesforce or Dynamics into SalesLoft.

So if a field were to get updated on a record in your CRM, that is not going to come into SalesLoft.

If you do have fields that are mapped bidirectional, those would still sync outbound to your CRM, but we would we would not be pulling in any inbound changes. We do recommend enabling this so that way as fields get changed inside of your CRM, they get changed inside of SalesLoft as well.

You then have the option to choose a CRM sync alert contact. So who do you want to which SalesLoft user do you want to receive an email notification whenever there is an issue with the CRM connection? So sometimes it could be that the connection was, broken, maybe credentials change or something of that nature, and we were no longer able to connect to your CRM, or maybe there's an issue with a specific field. That contact would get, a notification whenever that happened.

And then here we have inbound sync frequency. So this is showing us how often are we checking your CRM for updates on records. So you can choose this for each object, your account, contact, lead, and opportunity, every minute, every five minutes, or every ten minutes.

For opportunities, you actually have the option to say, we don't want to sync opportunities into SalesLoft at all. So if you choose that, you would no longer see opportunities within SalesLoft.

In terms of recommendations here, what we typically recommend is for your leads and contacts, you choose an interval here that's every minute. Usually, the changes that are happening in leads or contacts need to be seen inside of SalesLoft a bit more quickly because it can change the way that users are reaching out to records. So, like, if a status changes in, your CRM from open to close, we would want to sync that into SalesLoft pretty quickly so that way users could see that change within SalesLoft.

In terms of API calls here, sometimes customers ask about that. The way that we bring in API calls here is we batch two thousand changes in your CRM into one API call inside of SalesLoft.

So two thousand fields could get updated in your CRM, and then those would come in as one API call into SalesLoft. So, it's not usually a huge lift whenever we're changing this to every minute. If you are seeing that you're coming close to your API limit within your CRM, which is not something that, SalesLoft has control over, but if you want to, you can decrease the time that we are check checking, your CRM for updates. So you could change that to every five minutes or every ten minutes.

Where this is applicable is, again, changes that happen in your CRM coming into SalesLoft. So if a first name was changed in your CRM, we would bring that in every five, one minute, five minutes, or ten minutes. This does not apply to outbound changes happening to your CRM. So if a user goes in and changes the first name inside of SalesLoft and that field is mapped bidirectionally with your CRM, then that would be pushed immediately to your CRM. So outbound changes are immediate. Inbound changes are based off of your pulling intervals here.

One other callout is we do have an automation rule that can bring in records from your CRM. So we have, the trigger that says when a lead or when a contact is not found in SalesLoft.

This is also going to be based off of your polling interval. So if you say when a lead is not found in SalesLoft, what we are then going to do is check your CRM every one, five, or ten minutes to see if there is a record that, meets the criteria in your CRM, and then we will pull that in to SalesLoft.

This is very similar to how we've talked about, the field not not showing into SalesLoft. Again, those records have to have changed in your CRM within the last one, five, or ten minutes in order for that to come into SalesLoft. So what we're not doing every one, five, or ten minutes is we're not just saying, show me their entire CRM database and bring all those records into SalesLoft.

What we are doing is we're saying, show me the records that have been modified or created in the last one, five, or ten minutes, And then we'll either create those records in SalesLoft. If you have a automation rule that is, the purpose is to create records in SalesLoft, or we will bring in those fields that change on the records that already exist inside of SalesLoft.

So, again, if you're seeing, something that's not necessarily aligned between SalesLoft and Salesforce or your CRM, what you can do is make sure that that record has changed in the last one, five, or ten minutes in your CRM. Look at your polling interval, see if that aligns with that record coming into SalesLoft.

Again, if that record if you have a change that has happened on your record in your CRM and that's not coming into SalesLoft, and it's outside of that polling interval, then what you would need to do do a data bump in your CRM just to make it that force that change on that record in your CRM so then those fields or the records could come over into SalesLoft.

Alright. Hopefully, that gives details on our polling intervals and how you can utilize those to make sure that data is coming into SalesLoft. I'll stop sharing here. I think we've got one more topic, and then we're gonna pause for questions.

Yeah. The last topic is really quick. And I just wanted to kind of spend a little bit of time clarifying what you should be looking at if you are coming in from a troubleshooting perspective to see what is issue and what is no longer an issue.

So on my last topic, we talked about activity failures.

Activity failures will always clear from the interface once they have been successfully retried back into your CRM. So that means that if this is able to go into your Salesforce, this one to Missy Dime, if I refresh it, it would be gone. It would be completely cleared out. This is a really easy way for you to know.

Okay. We have three hundred and sixty six activity failures. Let's work through those. There is a possibility that will be to net zero activity failures.

The same does not apply for the CRM sync. So when we look at the CRM sync, and this is what Savannah was just talking about. This is the transfer of field data between SalesLoft and we're able to see anytime there was an error.

But even if we went in and tried the particular error, so let's say we retried the sync, the error would not clear out. So anytime you looked at this page, this error would still be present. The reason why that is important is because we are able to see at this moment in time these different pieces of information. We're not able to make it over into. So it's a really important troubleshooting snapshot.

Unlike the activity errors, it will not clear out. So there is an impossibility of getting it to that, like, net zero, net zero, error log perspective. You'll always have a history of that error occurring on the CRM sync.

One trick that I think is kind of nice, though, is if you were going through and you see that there are a bunch of errors, you can always come in and filter by that person. So you can see, oh, yep. There was this issue, but we were able to successfully resolve it. And since that point, the person is successfully syncing to the lead.

The lead's syncing to the person. We're getting all of this great data in both directions. So this is a great place for you to come and gut check and make sure that, the sync is working, still understanding that CRM sync blogs will not clear out any fillings. And, again, the way that I did that is I'll just grab a random person here, filter.

I can see all of the syncs between CRM and SalesLoft.

So with that, those are our prepared topics for the day. So what we're going to do is leave the chat open for any kind of questions for around three minutes. We'll hang on the line. Please feel free to drop in any other questions. Otherwise, we really appreciate your time today, and we look forward to assisting you all on another session.

Okay. Thanks, everyone.