Freshsuccess 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 [email protected].
MUST READ: Choosing an effective account_id
All objects synchronized with Freshsuccess requires 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
Freshsuccess 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 FDCS 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 Freshsuccess without delay.
MUST READ: Choosing the Accounts System of Record
For any object other than an account to be successfully inserted into Freshsuccess, the supplied account_id must exist in FDCS, otherwise, that object is rejected.
The first step for data integration consists of "loading" your accounts into Freshsuccess.
To automate the loading of accounts into Freshsuccess, we ask that one system become your “System of Record” (SOR) which contains the complete list of your accounts. Automating this step via an FDCS 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?
Freshsuccess 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 Freshsuccess. Think about how you reference your customers internally, you should be able to search for these same names within Freshsuccess.
Join Date: this is the date Freshsuccess 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 Freshsuccess.
To do this, the SOR must include a way for FDCS 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 with 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?