Whether you add data to Totango via the UI, a data file, or a data source, every account, user, and collection in Totango must have a unique ID (also referred to as binding ID). 

Account IDs are yours to manage; no IDs will be provided by Totango. 

Here are recommendations for choosing the design pattern for unique identifiers for account objects:

1. Ensure every Account ID is unique, including accounts within a hierarchy structure. 
2. Use alpha-numeric characters, except special characters. Underscore (_) and hyphen (-) are allowed. 
3. Use a consistent format. If using product accounts in your hierarchy structure, we recommend concatenating Account ID (e.g., 819332) and Product ID (e.g., ABC) with an underscore to generate the product account ID (e.g., 819332_ABC). This virtual ID can be derived on the fly when enabling product accounts.
4. Ensure that the ID format and/or value aligns with other data sources from which you may be bringing data into Totango (e.g., your internal application and CRM system) in order to "bind" data into a single account or user entity.

Refer to attribute limitations for more information.

Totango's Javascript collector will perform this concatenation for you automatically when you define the product object.

Account design patterns for integration

The following design patterns are common practices when integrating account data between your own web application, Totango, and another system (e.g., Salesforce). The objective is to match a Totango account with the record counterpart in the other system, however that is represented.

Pattern 1: Totango account ID = Internal application ID

This is the most common integration pattern. It assumes your web application internal ID propagates into Salesforce (usually as part of your account provision subsystem).

In this approach, your internal ID (often called a tenant or system ID) is used to as the Totango Account ID. For Totango to then correctly bind data for an account with Salesforce, the internal ID should be present in a custom field in Salesforce.

Totango requires the case safe 18 character SFDC ID. 

Pattern 2: Totango account ID = Salesforce account ID

In this approach, the unique Salesforce ID (an 18-char value that can look something like 0000012000000qAhBp) is used as the common ID. The unique SFDC ID associated with every customer should be available for use in your internal web application, so you can properly reference it when making API calls.

Pattern 3: Totango account ID = Internal application ID + secondary ID (Salesforce)

In this hybrid approach, the internal application ID is the unique Totango account identifier. Additionally, you can use the Salesforce ID for binding purposes via a secondary ID in your calls to the Totango API. This approach is often used if the internal application ID is best suited to integrate Totango with additional data sources, such as an internal data warehouse, but that data is not readily available in Salesforce.

To provide a secondary ID, use the foreign key attribute feature, which is a generic implementation for similar use cases. The foreign key attribute feature is not limited to only the Salesforce connector and can be used with different systems.

Totango legacy Salesforce connectors use a dedicated "ofid" field (sdr_ofid parameter if using the HTTP API) in place of a foreign key attribute. 

window.totango_options = {
  service_id: "SP-0000-00", 
  account: {
    id: “123456” 
    
    // SFDC ID for the Account
    foreignkeyid: "0012000000msDD0BDU", 
   }
  ...
}

Refer to contract status for additional considerations when managing free trials in your internal web application and Totango.

User design patterns for integration

The following design pattern is recommended when integrating user data between your own web application, Totango, and another system (e.g., Salesforce).

Pattern 1: Totango user ID = Email address

We recommend using the email for the user/contact as the User ID in Totango. This approach makes it easy to associate the user between a variety of applications, such support and marketing automation tools.

Alternatively, you can use a different value as the unique identifier in Totango. If you will be integrating with Salesforce contacts, you need to provide the name of the custom field in Salesforce containing that value. Similarly, if you will be integrating Totango with your support system or other third-party application, you need to associate this value with the user in the third-party application.