thinking about it, please hold on..

Design Consideration: Account & User ID


Probably the single most important design decision when integrating Totango into your application infrastructure is identifying the right IDs to represent accounts and users, which are the two main objects in the Totango data-model.

  • An Account in Totango should map to a tenant of your application and represent YOUR end-customer. This is the entity your customer-success team managers towards success.
  • A User represents end-users of your application. They login and use your app in the context of an account.

When you make a call to Totango, you will need to supply an account-id and/or user-id to uniquely distinguish the account/user.

Because  your Totango will also need to bring in data from additional sources, most notably your Salesforce CRM platform, these unique IDs should also be available in your CRM (as a custom field). Totango uses them to “bind” data from multiple sources into a single Account or User entity.

Typical SaaS implementation follow one of the following design patterns for account-ids.


Account ID: Design Pattern #1 - Using your internal application-ID as the Totango account-id

In this approach you internal ID (often called a tenant or system ID) is used to as the account-id in Totango. For Totango to then correctly bind data for this account with Salesforce, this internal ID should be present in a custom-field in Salesforce.  (Important note: Totango REQUIRES the case safe 18 character SFDC ID.  More info.)


This is the most common integration pattern, but it does assume your web-app internal ID propagates into SFDC (usually as part of your account provision subsystem).

Account ID: Design Pattern #2 - Using  the SFDC Account-ID as the Totango account-id

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

Pattern #3 - Hybrid (using both SFDC and your internal Application-ID)

If you would like to use your internal application-ID as the unique Totango account-identifier, but still use the SFDC ID for binding purposes with the CRM platform, you can supply a secondary ID in your calls to the Totango API.  This may make sense if the internal application-ID is best used to integration Totango with additional data-sources (e.g. your internal data-warehouse) but is not readily available within SFDC.  

To provide a secondary ID for SFDC binding purposes, 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", 

Account Expiration

Totango uses an expiration mechanism designed to clear Totango resources for  accounts that were created in error or are no longer in use.

This is particularly relevant for web-applications with free trials managed by Totango. In those cases, the majority of accounts may be active for a few weeks during the trial, and then permanently abandoned once the trial has ended.

Totango automatically detects this condition and expires the inactive trial accounts, to a number of benefits:

  • Lists and searches  ignore irrelevant past accounts, making the data in Totango cleaner and simpler to navigate. For example, when generating a list of “all trial accounts that have not logged in recently” it will ignore inactive trials from many moons ago
  • Expired accounts are not counted against your Totango usage quota, resulting in less cost
  • Smaller data sets which improve overall performance and information clarity

Note that statistical information about old accounts is not deleted, so when creating a trend report on past data, past behaviors of expired accounts are still taken into consideration.

For example, if you create a report on a Segment [Trial accounts that have not used Feature-X], the trend line in the report will count trials matching this segment that have since expired.  

By default, Totango will automatically expire any “Free” or "Unknown" account that has been inactive for 60 days. You can modify this default behavior using the Accounts | Settings options. Recommended values below: 

  • For Trial programs of 14days or less: Set expiration to 14days
  • For Freemium services (unlimited free use of reduced functionality): Set expiration to 90days
  • For all others: Set expiration to 60 days

NOTE: If you want certain accounts to never expire, simply move them to the Paying status. If they are not generating any revenue, set their Contract Value to zero.

NOTE: Accounts in a cancelled status never expire. 

User ID: Design Patterns
For end-users, Totango recommends using the user's email as the unique-id on Totango. This makes it easy to associate with the user on support and marketing automation tools that use similar defaults.

Alternatively, you can use a different value as the unique user-id on Totango (for example: the user's login on your web-app).

If you will be integrating with Contacts, you will 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 3rd party application, you will need to be have this value associated with the user  in the 3rd party application. Refer to the relevant application's documentation in our Integration section. 

Have more questions? Submit a request


Powered by Zendesk