Natero supports a variety of third-party system integrations to provide a 360 degree view of your customers. In this article, we explore how accounts are synchronized between third-party systems.



Our complete list of supported integrations can be found here.


Requests for new integrations can be sent to support@natero.com.



MUST READ: Choosing an effective account_id


All objects synchronized with Natero require an account_id, so they can be successfully tied to an account upon insertion.


Create programmatically


Avoid manually created account_ids at all costs because they invariably lead to mismatches. An account_id must be an exact (case sensitive) match across multiple systems. Whenever possible, create account_id through a consistent, automated, programmatic approach.


Numbers are better


If manual entry is your only option, account_id containing only numbers and no spaces are best, because they are not case sensitive.


Store it as text


Natero processes all account_id as String/Text.


It is important to store all account_id as either String/Text (preferred) or Integer/Long (acceptable).


Problems can arise if account_ids are stored as Decimals/Float (e.g. “12345.0” will not match “12345”).


Is it accessible in your product?



  • Product usage events and metadata must contain user_ids, and optionally account_ids.

  • If account_ids are not present in product usage events, a mapping table must exist in Natero containing the association between user_ids and account_ids.

  • Using an account_id that is already present in your product will help reduce engineering effort.


Propagate new account_ids automatically



  • New account_ids will need to be propagated across all of your systems.

  • Ensure that new account creation can be fully automated across all systems, as it will help reduce operational costs, and also make new accounts appear in Natero without delay.



MUST READ: Choosing the Accounts System of Record


In order for any object other than an account to be successfully inserted into Natero, the supplied account_id must exist in Natero, otherwise that object is rejected.


The first step for data integration consists of "loading" your accounts into Natero.


To automate the loading of accounts into Natero, we ask that one system become your “System of Record” (SOR) which contains the complete list of your accounts.  Automating this step via a Natero integration is important, so that new accounts are loaded without delay in the future.


Will it include all of your accounts?


Pick a SOR that includes all of your accounts, and will stay up-to-date in the future.


Does it include mandatory fields?


Natero accounts require 3 fields:




  • account_id: as discussed in the previous section, the SOR must include the account_id you have chosen


  • Name: The SOR must include account names as you want them to appear in Natero. Think about how you reference your customers internally, you should be able to search for these same names within Natero.


  • Join Date: this is the date Natero uses to start looking for account activity and revenue.


Can it be filtered?


You will likely want to filter the accounts so that only revenue generating and/or active accounts appear in Natero.


To do this, the SOR must include a way for Natero to filter your accounts, usually by checking the value of a field. The SOR must either include this field, or a path must exist from the SOR to the system that has the field.


For example, you could choose Salesforce as your SOR and only import Salesforce Accounts that also exist in Zuora. In this case, a mapping between Zuora and Salesforce account_id’s must exist in either system.



MUST READ: Where to store the account_id?


 BEST CHOICEACCEPTABLE CHOICE
CRM
Salesforce

Custom field in Account Object


A custom field value, typically from your product.


Store it as Text.



Account.Id or Opportunity.Id


Choosing a native Salesforce ID as account_id mandates that the Salesforce ID is propagated to your other systems, or vice versa.


Infusionsoft

CompanyID field in Company Object


CompanyID is typically sent from your product.



ContactID field in Contact Object


This approach may lead to problems as multiple contacts could match the same company, it's best when only one object maps to an account.


Capsule

Custom field in Party/Organisation Object


Typically sent from your product.



Contacts.website.webaddress field in Organisation Object


This is a manually entered field.


CUSTOMER SUPPORT
Freshdesk

Custom field in Companies Object


Typically sent from your product.



Email field in Contacts Object


If all emails exist under Natero account users or contacts, it can potentially be used to map support tickets to an account.


Note that this is a manually entered field.


Desk (legacy)

Custom field in Companies Object


Typically sent from your product.



Email in Customers object, Domain in Companies object


If all emails exist under Natero account users or contacts, it can potentially be used to map support tickets to an account.


Note that this is a manually entered field.


If using Domain, a mapping to account_id must exist somewhere else.


Zendesk

External_id field in Organizations Object


Typically sent from your product.



Email field in Users Object


If all emails exist under Natero account users or contacts, it can potentially be used to map support tickets to an account.


Note that this is a manually entered field.


JIRA

Custom field in Issues Object


Typically sent from your product



Store existing Id field in Jira Issues as account_support_id in Natero Accounts


If Jira Issues object has an Id referring to an account, you can add that Id within Natero Accounts as account_support_id and we can use that field to link support tickets to your accounts.


FINANCIAL
Recurly

Store and map Recurly Account.account_code into an external system.


Recurly support for custom fields is non existent.


Best practice is to create your new accounts in your SOR then create Recurly accounts automatically, and store the Recurly account_code in your SOR.



Email field in Account Object


If all emails exist under Natero account users or contacts, it can potentially be used to map Recurly accounts to Natero accounts.


Note that this is a manually entered field.


Zuora

Custom field in Account Object


Typically sent from your product.



Store and Map Zuora Account.Id into an external system


For example using the Zuora plug-in for Salesforce.


Chargebee

Custom field/metadata in Customers Object


Typically sent from your product.



ID field in Customers Object


Choosing a native Chargebee ID as account_id mandates that this ID is propagated to your other systems.


Chargify

Reference field in Customers Object


Typically sent from your product.



Email field in Customers Object


If all emails exist under Natero account users or contacts, it can potentially be used to map Chargify accounts to Natero accounts.


Note that this is a manually entered field.


Braintree

Custom field in Customer Object


Typically sent from your product.



Email field in Customer Object


If all emails exist under Natero account users or contacts, it can potentially be used to map Braintree accounts to Natero accounts.


Note that this is a manually entered field.


Stripe

Custom field/Meta Data in Customers Object


Typically sent from your product.



Email field in Customers Object
If all emails exist under Natero account users or contacts, it can potentially be used to map Stripe accounts to Natero accounts.


Note that this is a manually entered field.


Xero

AccountNumber field in Contacts object


Populate it with your own product account ID.



Email field in Contacts Object


If all emails exist under Natero account users or contacts, it can potentially be used to map Xero accounts to Natero accounts.


Note that this is a manually entered field.


INTERACTIONS
Intercom

Company_id field in Companies Object


Typically sent from your product.



Custom_attributes field in users Object


Typically sent from your product.


NPS
Delighted 

Person.email field in SurveyResponse Object


If all emails exist under Natero account users or contacts, it can potentially be used to map Delighted contacts to Natero accounts.


Note that this is a manually entered field.