Integrate Third Party Systems With Natero

Natero supports a variety of third party system integrations that enable a 360 degree view of your customers. In this article, we explore how account ID’s are typically synchronized between third party integrations.

All objects synchronized with Natero shall include an account_id, so they can be successfully tied to an account upon insertion. Here’s how to choose an effective account_id:

Create it programmatically: account_id's are compared upon object insertion and must be an exact (case sensitive) match. Extra spaces can also be a problem. Manually entered account_id’s should be avoided at all costs, because they invariably lead to mismatches.

Numbers are better: If manual entry is the only resort, account_id’s that contain only numbers and no spaces are better, because they are case insensitive.

Store it as Text:To ensure proper ID matching across systems, all ID’s are processed as Strings/Text by Natero. It is important to store all of your ID’s as either String (preferred) or Integer/Long (acceptable). Problems can arise if ID’s are stored as Decimals/Float because “12345.0” will not match “12345”.

Is it accessible in your product?Product usage events and metadata must contain user ID’s, and optionally account ID’s.If account_id’s are not present in product usage events, a mapping table must exist in Natero containing the association between user ID’s and account ID’s.Choosing an account_id that is already present in your product and can easily be sent with product usage events will help reduce engineering costs.

Propagate new account_id’s automatically:New account_id’s will need to be propagated across all of your systems. When picking an account_id, 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 before running any other integration consists of “loading” the accounts into Natero.

To automate the loading of accounts into Natero, we ask that one system become the “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.

Here are some criteria to keep in mind when choosing the SOR:

Will it include all of your accounts?Pick an SOR that includes all of your accounts, and will stay up-to-date in the future.

Does it include mandatory fields?Natero accounts have 3 mandatory fields:

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

Name: The SOR must include the account names, as you want them to appear in Natero. Think about how you call your customers internally, you should be able to search for these 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 most likely want to filter the accounts so that only revenue generating and/or active accounts appear in Natero.The SOR must include a way to filter the accounts in the desired fashion. This is typically achieved via a field value check. The SOR must either include this field, or a path must exist from the SOR to the system that has the field, e.g. you could choose Salesforce as SOR and only import SFDC Accounts that exist in Zuora (i.e. have billing activity). In this example, a map between Zuora and Salesforce account_id’s must exist in either system.

MUST READ: Where to store Account ID?

Best Choice

Acceptable Choice

Sales and Marketing

Salesforce

custom field in Account Object

The custom field value is typically comingfrom your product. Store it as Text.

Account.Id or Opportunity.Id

Choosing a native Salesforce ID as account_id mandates that the SFDC ID

is propagated to your other systems, or vice versa (i.e. the other systems’ ID’s are propagated to SFDC and mapped)

Infusionsoft

CompanyID field in Company Object

CompanyID is typically coming 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.

CRM

Capsule

Custom field in Party/Organisation Object

Typically coming from your product.

Contacts.website.webaddress field in Organisation Object

This is a manually entered field = sub-optimal.

CustomerSupport

Freshdesk

Custom field in Companies Object

Typically coming 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, i.e. sub-optimal.

Desk

Custom field in Companies Object

Typically coming 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, i.e. sub-optimal.

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

Zendesk

External_id field in Organizations Object

Typically coming 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, i.e. sub-optimal.

JIRA

Custom field in Issues Object

Typically coming 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 (System of Record) then create recurly accountsautomatically after that, 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, i.e. sub-optimal.

Zuora

Custom field in Account Object

Typically coming 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/Meta Data in Customers Object

Typically coming from your product.

id field in Customers Object

Choosing a native Chargebee Id as account ID mandates that this IDis propagated to your other systems.

Chargify

Reference field in Customers Object

Typically coming 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, i.e. sub-optimal.

Braintree

Custom field in Customer Object

Typically coming 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, i.e. sub-optimal.

Stripe

Custom field/Meta Data in Customers Object

Typically coming 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, i.e. sub-optimal.

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, i.e. sub-optimal.

Customer Communication

Intercom

Company_id field in Companies Object

Typically coming from your product.

Custom_attributes field in users Object

Typically coming 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.