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 CHOICE | ACCEPTABLE 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 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. | |