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
Record matching
Company / Companies
Compare whether HubSpot Company and Nimble Companies describe the same company in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- HubSpot
- Documented record · ✅ Supported
- Nimble
- Object support to establish
- Record identity
- Retain the source company ID and the destination customer/company ID. Separate legal entities, subsidiaries, and business units; a shared name or web domain is insufficient.
- Field ownership
- Assign ownership separately for relationship details and finance-controlled billing details.
Fields to include
- Source record ID
- Legal or display name
- Business-unit reference
- Lifecycle status
- Record dependencies
- Resolve parent organizations, business units, and currency references before dependent transactions.
- Validation
- Use two organizations with similar names and one with multiple business units. Verify that an update reaches the intended entity only.
- Recovery
- Repair the cross-system ID relationship before retrying dependent records; do not merge companies solely to remove a sync error.
References: HubSpot: Company documentation
Record matching
Contact / Contacts
Compare whether HubSpot Contact and Nimble Contacts describe the same contact in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- HubSpot
- Documented record · ✅ Supported
- Nimble
- 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: HubSpot: Contact documentation
Record matching
Deal / Deals
Compare whether HubSpot Deal and Nimble Deals describe the same deal or opportunity in your business.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- HubSpot
- Documented record · ✅ Supported
- Nimble
- Object support to establish
- Record identity
- Keep the opportunity/deal ID separate from any later order or invoice ID.
- Field ownership
- The sales process owns qualification and stage changes; downstream financial records have their own state and approval rules.
Fields to include
- Source deal ID
- Stage
- Amount and currency
- Expected close date
- Company reference
- Record dependencies
- Map the customer and sales pipeline before the opportunity; map stage values deliberately.
- Validation
- Test a reopened won deal, a stage with no destination equivalent, and an amount using a different currency.
- Recovery
- Suspend downstream creation for a rejected deal and review whether an order already exists before retrying.
References: HubSpot: Deal documentation
Business process
Ticket / Tasks
Support-to-work-item handoff: HubSpot Ticket provides context for Nimble Tasks. These are related records, not equivalent entities.
Planning example. Stacksync support for the required connection and record operations needs a technical review.
- HubSpot
- Documented record · ✅ Supported
- Nimble
- 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: HubSpot: Ticket documentation
Record matching
Tasks / Tasks
Compare whether HubSpot Tasks and Nimble 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.
- HubSpot
- Documented record · ✅ Supported
- Nimble
- 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: HubSpot: Tasks documentation