How KORE products fit into your CRM

Applies to:

• KORE Ticketing & Fan Engagement
• KORE Sponsorship & Partner Engagement
• KORE Suites & Premium

Overview

KORE offers three products which integrate and embed into CRM software: KORE Ticketing & Fan Engagement, KORE Sponsorship & Partner Engagement, and KORE Suites & Premium. Each one adds extensive new features to your Microsoft Dynamics or Salesforce CRM. You can subscribe to these products as a bundle, or individually with the option to add additional products later. This document describes how these products are installed, how data is kept in sync, and how your data is secured.

For a list of supported CRM environments, see Software requirements.

Components

No matter which of these KORE products you use, there are three essential components that are wrapped into an "Organization": CRM customization package(s), KORE's Web Application, and a KORE Database. If you use more than one of these products, they can share the same Organization or be separate instancse.

CRM customization packages

When you subscribe to a product, KORE will install customization packages into your CRM. These packages include:

• managed entities (Dynamics) or custom objects (Salesforce)
• web resources (Dynamics) or apex components (Salesforce)
• plug-ins (Dynamics) or triggers (Salesforce)
• navigation components

Most of the new embedded features will be displayed as part of a CRM page (using an IFRAME), though a few will be shown in a new browser tab.

KORE's Web Application

A web app serves the content displayed in an IFRAME or new tab. It runs on a web server specific to your business (client_name.pss.koresoftware.com). The web server runs on AWS (Amazon Web Services) in the region closest to you out of:

• us-west-2 (Oregon)

• eu-west-1 (Ireland)

• ap-southeast-1 (Singapore)

Database

The web server relies on a SQL Server database running in the same AWS region. This database contains tables that power web pages, and entities which are synchronized from your CRM.

Authentication

KORE Platform

The KORE Platform integrates all KORE products together and manages user authentication. See https://help.koresoftware.com/hc/en-us/articles/22543920363799-KORE-Platform-Overview 

Legacy Authentication

Accounts

KORE will ask you to create three CRM accounts during the setup process:

• Service—allows KORE products to access your CRM via its API. Required for Salesforce.
• Admin—allows KORE to make configuration changes on your behalf.
• Test—allows KORE Support to sign in to your CRM environment without admin privileges for troubleshooting.

The Service account is required for KORE products to function (unless your organization uses Dynamics and sets up application registration and users). KORE employees are prohibited from using the Service account for any other purpose. If you use two-factor authentication with your CRM, you must take steps to allow automated sign ins.

The other accounts are optional but strongly encouraged—if you choose not to create the Admin or Test accounts for us, it will severely limit our ability to support your system.

Synchronizing data

Customer data exists in two places: the SQL Server database and your CRM’s data store. KORE products synchronize data between these two locations.

KORE’s products only interact with your CRM by using its API. They do not use a direct connection to your CRM’s data store, and there’s nothing extra for you to run on your network even if you have an on-premises CRM.

For some entities or objects, KORE treats the CRM data store as the “source of truth” and copies them to the SQL Server database. For others, KORE treats the SQL Server database as “source of truth” and copies them to the CRM data store. The entity dictionary lists the “source of truth” for each one.

Syncing from CRM to the SQL Server database

The plug-ins (or triggers) added to your CRM connect to particular entities. When one of these entities is updated, the plug-in creates a “queue object”–a piece of data that identifies the change and what order it happened in relative to other updates.

On a regular basis, KORE’s Change Processor ask your CRM (using its API) for any queue objects it has. If a Change Processor receives a queue object, it sends the record’s ID number and the type (like “account” or “activity”) to Amazon SQS (Simple Queue Service).

KORE’s Queue Processor examines the queue object, looks up the change associated with the ID number, and reads the latest version of the record from your CRM. (This ensures that if a change was immediately reverted, we don’t copy the unwanted change.) The Queue Processor writes the update into the SQL Server database, then deletes the queue object from SQS.

Syncing from the SQL Server database to CRM

A record in the SQL Server database can be updated in a variety of ways, including:

• Ticketing module integration (such as Archtics)
• Ticketing Data Manager (TDM)
• Do Not Call list ingestion

When a change is written into the SQL Server database, KORE creates a Queue object for the update. The Change Processors check for any Queue objects, send the ID number and data type to Amazon SQS, and then delete the original Queue objects from the SQL Server database. The Queue Processors take the Queue objects from SQS, write the changes to your CRM, and then delete the Queue objects.

Pushing updates (KORE Ticketing only)

KORE Ticketing also uses a separate push procedure to copy changes from your ticketing system to the “source of truth”. For example, suppose you use the Archtics integration. If the address associated with an Archtics account is updated, KORE Ticketing detects this and copies the update from Archtics to the CRM, since the CRM—not the SQL Server—is the “source of truth” for address information. The update then propagates from your CRM to the SQL Server database through the sync process.

Data handling

This section has been moved to a separate page.