Overview

Objective/Purpose

The purpose of this document is to explain, from a very high level, the integration possibilities with InTouch. Integration will allow data that is entered into one system, to flow into the other. At minimum integration usually consists of data that is entered by users into InTouch flowing into another system. This is because InTouch is primarily a lead tracking tool and leads must be entered into InTouch for it to provide its purpose. The data entered into InTouch then usually flows into another system or systems. This can happen immediately, or once the lead has been won and has become a member. Data can also flow from the other system back into InTouch.

Integration Overview

Integration with InTouch is accomplished via the Connector, which can be thought of as a synchronization hub. The Connector is a central location that each partner system that integrates with InTouch uses. Each system is a ‘spoke in the hub’ (think like a bicycle wheel). The reason for this is that it greatly simplifies integrations where there are more than two systems involved as each system simply has to integrate with the hub, rather than each individual other system. Basically when data is sent from one system to the Connector, the Connector will know where else to push that data. It is important to realize that InTouch itself is just another spoke in the hub, InTouch is not itself the Connector. Communication occurs via standard web services. 

 

Note that not every system implements two-way data flow as indicated in the diagram.  Often data is one-directional and only delivered to a system (e.g. System B above)

Use Cases

Here we will list common integration scenarios. We will use the name ‘Acme’ to represent the name of the partner system

  1. InTouch -> Acme: The most common scenario is when data entered into InTouch must flow to Acme. Normally a business rule is in place that says that all leads must be entered into InTouch. All data entered in InTouch will flow to Acme. Note that sometimes the data isn’t pushed until the lead is won and becomes a member. This is common for systems that don’t have a concept of prospect and only care about members
  2. Acme -> InTouch: It is often desirable to have data that is created or modified in Acme to come back into InTouch. Everybody usually agrees that it is more convenient to be able to update data anywhere, versus only in one system e.g. Telephone number or address contact detail changes. If another system supports prospects then it may be desirable to let them be created in that other system. However, normally InTouch handles prospects and this isn’t required. If a member is created directly in another system then it is vital that this flows to InTouch so member follow-up can be done.

Attributes

Some contact level attributes play a role in integration.

  • User status is obviously important. When a contact is marked as inactive in one system, it must flow to other systems. It is also important that each system can map its statuses to the statuses in other systems.
  • User type is also important in many systems. When a lead is created in InTouch, the contact has a user type of prospect. When the lead is won the type becomes a member and when the membership expired it becomes an ex-member (or former member). Some systems don’t differentiate between these types and can ignore it while others have the exact same concept in their system.

Fields

This section lists all the common fields that are normally used in the integration

User Fields
  • First name
  • Last name
  • User status (active or inactive)
  • User type (prospect, member, ex-member, or staff if that is part of your integration)
  • Birthdate
  • Gender
  • Address 1
  • Address 2 (note: currently InTouch does not have this field)
  • City
  • Zip/Postal Code
  • State/Province
  • Country
  • Email
  • Mobile
  • Home phone
  • Work phone
  • Company
Lead Fields

This section lists all the fields that are part of leads/prospects

  • Trial Start Date
  • Trial End Date
  • Lead Owner (note: getting the lead owner requires additional web service functionality. Please see the developer guide)
  • Lead Source (note: getting the lead owner requires additional web service functionality. Please see the developer guide)

Logging

Once the Connector is activated, a link will appear in InTouch under Admin -> Club to the Connector Logging page.  This logging page shows all the recent activity that has occurred over the Connector for your club including errors and warnings.  If you expected an update such as a new record to appear in one system and it didn’t, you should be able to go to the logging page which may provide a clue.

Some examples of what you will see

  • A lead created in InTouch, that was then sent on to another provider
  • A lead was created in InTouch, but did not arrive as expected in another provider. There is a warning in the Connector which shows that the provider rejected the record because of an invalid value for ‘state’. You should be able to fix the record in InTouch which will send the record to the Connector again.
  • The Internet is down!  You may see errors that a provider is not accessible