Ultimately, only Salesforce can explain exactly what that specific gack message means. However, it appears to have to do with a misunderstanding about attaching the ContentNote records to parent files.
The OwnerId
field is the User who owns the Note, not the record to which it is attached. You're not required to populate this field. In fact, it's often ideal to allow Salesforce to populate the field based on your data load user, if you use an "Integration User"- or "System User"-type model. This can be helpful because of the unique permission structure on Content objects, which can result in you being unable to access or modify the inserted records immediately after you assign ownership to another user.
Rather than populating a parent object Id in the OwnerId
field, in order to attach the Note to a record, you need to perform a second Data Loader pass to insert ContentDocumentLink
records.
ContentDocumentLink
acts as a junction object between the ContentNote
and the various locations where it may be shared. (When working with Content objects, you can generally treat ContentNote
and ContentDocument
as equivalent. ContentNote
abstracts away some of the complexity around adding versions and extracting their document Ids to add links).
Salesforce has detailed instructions on how to perform these two data-load passes. Basically, you'll get your success file back from Data Loader after inserting the Notes (which, after the first step, are not linked to anything) and then use it to construct the second load file (for ContentDocumentLink
).
You treat the output Id
column of the inserted Notes as the ContentDocumentId
field of the ContentDocumentLink
. You then have to populate a couple of other fields to define the share type - see the documentation for more (sometimes confusing) details, but I've found that the appropriate solution is to set ShareType
= "I"
and Visibility
= "AllUsers"
. Lastly, you put the parent Id in the LinkedEntityId
field.
One way to simplify your process here will be to include all of these columns (ShareType
, Visibility
, and LinkedEntityId
) in your original import file. You'd simply not map them in the first load pass. Then, when you open your success file, each inserted ContentNote
Id would still be clearly associated with its desired LinkedEntityId
. By simply changing the Id
column that Data Loader outputs to ContentDocumentId
, you could feed that success file straight into Data Loader's column auto-match for a ContentDocumentLink
import.
I have written an open source package to support bulk imports of Content Notes, which might be useful or an example.