nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Record Sync Errors

Adrie_Christiansen

Hi,

I would love if the record sync error feature could be enhanced so that only workflow/record types where Record Sync has been configured are run through and shown in the error log. Right now, our error log is unmanageable because all our repository records are run against the Record sync rules when only a small portion of our Sales agreements are configured to successfully sync back to SFDC. It makes it very difficult to catch actual errors in the process.

Find more posts tagged with

Status: None

Comments

Andrew_Smith

Totally agree! Could you potentially map those records that aren't configured to sync back to dummy records in Salesforce as placeholders? Or better yet, could you map them to your Salesforce data (the real records)?

Angela_Mendenhall

@Adrie_Christian or @Andrew_Smith

We are running into a record sync issues with legacy records that we want to import into Ironclad. Have either of you dealt with this and have advice to avoid the sync errors? We would prefer not to name the imported records something different than our current record types.

Andrew_Smith

Ah record sync fun! I might have seen an error or two before .

It all depends on the error. Have you gone into set up and looked at the error details?

The clue resides in there; for example...

Adrie_Christiansen

@Angela_Mendenhall

The record sync errors I've had are around non-Sales contracts that don't and shouldn 't have related SFDC records to sync back to & a few legacy Sales contracts that were executed prior to our team utilizing SFDC Opptys. So mostly, I can just ignore all the errors but it does make it hard to catch actual errors for new requests.

Angela_Mendenhall

@Andrew_Smith I don't expect or want my 30k legacy contracts to sync back to SFDC. But if I import them with the same record name (as ones that currently originate in SFDC and sync back), then I get errors. Basically I don't want to have record types: MSA and Imported MSA. They should all live under the MSA record type...

@Adrie_Christian I feel like something has to be up with your mapping if you get errors on workflows that don't originate in SFDC. The legacy ones are the thing I am having the issue with.

Andrew_Smith

Simple answer... if you import them under a record type that is set up for sync, they will ATTEMPT to sync back... and fail. Not much you can do about this under the current set up other than introduce a different record type.

Getting creative... maybe try to disconnect salesforce temporarily (you could delete your record sync config) and then import a record. Add the record sync back. That record won't attempt to sync unless you change the record. Not a 100% solution, but might stop the large volume of error noise.

Angela_Mendenhall

@Andrew_Smith **bleep**! I was hoping one of you all had a better solution I hadn't thought of yet. We almost imported with sync off, but as we thought about the many ways we change the records (simply by adding relationships, or incorporating new expiration/renewal date info with upcoming Ironclad capabilities) we knew we were just delaying the inevitable errors. And with 30k records to sync, we were expecting 12k+ errors at least.

Thanks for the gut check.

Angela_Mendenhall

@Andrew_Smith Ironclad bleeped me. That word wasn't even that bad. 🤣

Andrew_Smith

🤣

Zach_McKenzie

Just finding this thread now.

@Adrie_Christiansen , we have run into the same issue, specifically with NDAs. Our solution was to clone our NDA workflow configuration and call it "NDA - Non-Salesforce" and remove our Ironclad Properties relating it to Salesforce.

Some of our NDAs relate back to a Salesforce account, some don't. So the ones that do, we use the "NDA" workflow, and the ones that don't relate to a Salesforce account, we use the other workflow. We have seen a decrease in errors since implementing this.

I'd love to know if there are better ways to handle this without getting errors super regularly.