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.

Third Party Integrations

Our complete list of supported integrations can be found here.

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

 

Preparing to perform 3rd Party Integrations

MUST READ: Choosing an effective account_id

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 coming
from 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.
Customer Support    
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.
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 accounts
automatically 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 ID
is 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.

Note that this is a manually entered field, i.e. sub-optimal.

 

Have more questions? Submit a request

Comments