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.
Download the mapping worksheet · CSV, no email required
Customer identity
Customer / Companies
Before linking NetSuite Customer to Twenty CRM Companies, 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.
- Twenty CRM
- 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
Customer identity
Customer / People
Before linking NetSuite Customer to Twenty CRM People, 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.
- Twenty CRM
- 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
Record matching
Contact / People
Compare whether NetSuite Contact and Twenty CRM People 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.
- Twenty CRM
- 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
Business process
Sales Order / Opportunities
Approved sales handoff: Twenty CRM Opportunities provides context for NetSuite Sales Order. These are related records, not equivalent entities.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · ✅ Supported
- Twenty CRM
- Object support to establish
- Record identity
- Link the originating deal ID to a newly assigned order ID; do not reuse the deal ID as an order number.
- Field ownership
- Define the approval event and the customer/product data required to create an order. A sales stage alone must not authorize every order.
Fields to include
- Source record reference
- Destination record reference
- Approved handoff state
- Duplicate-detection key
- Record dependencies
- Map the customer and sales pipeline before the opportunity; map stage values deliberately.
- Validation
- Repeat the approved handoff and verify that it locates the existing order; test a reopened deal without silently cancelling fulfillment.
- Recovery
- Suspend downstream creation for a rejected deal and review whether an order already exists before retrying.
References: NetSuite: Sales Order documentation
Business process
Case / Tasks
Support-to-work-item handoff: NetSuite Case provides context for Twenty CRM Tasks. These are related records, not equivalent entities.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- NetSuite
- Documented record · Read: 🔓 Request Access. Write: 🔓 Request Access.
- Twenty CRM
- Object support to establish
- Record identity
- Retain separate ticket and task IDs with an explicit relationship; several tasks may resolve one ticket.
- Field ownership
- Choose which ticket conditions create a work item and which task outcomes may update the support case.
Fields to include
- Source record reference
- Destination record reference
- Approved handoff state
- Duplicate-detection key
- Record dependencies
- Resolve requester, organization, team, and status references before ticket updates.
- Validation
- Escalate the same ticket twice, close one of several tasks, and verify that private ticket content is not copied into a public work item.
- Recovery
- Check whether a reply or notification was already sent before replaying ticket actions.
References: NetSuite: Case documentation
Record matching
Project Task / Tasks
Compare whether NetSuite Project Task and Twenty CRM Tasks describe the same task or work item 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.
- Twenty CRM
- Object support to establish
- Record identity
- Use a stable task/work-item ID and preserve its project or parent-ticket reference.
- Field ownership
- Choose the owner of task status and assignment; destination workflow states may require an explicit transition.
Fields to include
- Source task ID
- Parent reference
- Assignee
- Status
- Due date
- Record dependencies
- Resolve project, user, and parent-item references before the task.
- Validation
- Test a reassignment, an unsupported status transition, a deleted parent, and a due date across time zones.
- Recovery
- Reconcile the destination state before retrying a transition to avoid reopening completed work.
References: NetSuite: Project Task documentation