Requirements for unique IDs

Every account and user object in Totango must have a unique ID. 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). 
  4. Ensure that the ID format and/or value aligns with other dats 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).

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).

mceclip3.png

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.

mceclip4.png

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.

mceclip6.pngTo provide a secondary ID, use the ofid field (sdr_ofid parameter if using the HTTP API) as shown in the example below.

window.totango_options = {
  service_id: "SP-0000-00", 
  account: {
    id: “123456” 
    
    // SFDC ID for the Account
    ofid: "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.

mceclip5.png

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.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request