Use these data-model references to describe the records your connection needs. They are planning examples; connector availability and supported operations must be established before implementation.
Record matching
Contact / Contacts / Subscribers
Compare whether NetSuite Contact and Salesforce Marketing Cloud Contacts / Subscribers describe the same contact in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · Read: ✅ Supported. Write: ✅ Supported.
- Salesforce Marketing Cloud
- Object support to establish
- Record identity
- Use a stable person/contact ID and an explicit cross-system lookup. Email can change and can be shared, so treat it as a matching clue rather than a universal key.
- Field ownership
- Keep consent and communication preferences under an agreed authority; a general contact update must not silently resubscribe someone.
Fields to include
- Source person ID
- Display name
- Email address
- Organization reference
- Consent state
- Record dependencies
- Resolve the organization relationship and any owner or consent references required by the destination.
- Validation
- Test an email change, two records sharing an email, and a person associated with multiple organizations.
- Recovery
- Hold ambiguous matches for review and reconcile the person ID before retrying; preserve the consent decision already recorded by its owner.
References: NetSuite: Contact documentation
Customer identity
Customer / Contacts / Subscribers
Before linking NetSuite Customer to Salesforce Marketing Cloud Contacts / Subscribers, check whether the customer is an individual or a company. Match the correct record type in each system.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · Read: ✅ Supported. Write: ✅ Supported.
- Salesforce Marketing Cloud
- Object support to establish
- Record identity
- Determine whether each customer represents an individual, a company, or a business-unit relationship before matching it to a contact or organization. Retain the source customer ID and destination ID; names and email alone are insufficient.
- Field ownership
- Separate the customer relationship from contact details, billing authority, and consent. Choose an owner for each field after identifying whether the customer is a person or company.
Fields to include
- Source customer ID
- Person/company classification
- Legal entity or business unit
- Destination identity reference
- Record dependencies
- Resolve person or company type, legal entity, business role, and any billing account before transactions.
- Validation
- Test an individual buyer, a company buyer, and one company with multiple billing relationships. Do not merge these into a single generic contact.
- Recovery
- Hold ambiguous customer matches for review and resolve customer type before retrying dependent records.
References: NetSuite: Customer documentation