- KORE Ticketing & Fan Engagement
- KORE Sponsorship & Partner Engagement
- KORE Suites & Premium
KORE offers three products which integrate with 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.
No matter which of these KORE products you use, there are three essential components: a CRM customization package, a web server, and a database. If you use more than one of these products, they share the same web server and database.
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 features will be displayed as part of a CRM page (using an iframe), though a few will be shown in a new browser tab.
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:
Note: KORE plans to migrate servers from Singapore to Sydney (
ap-southeast-2) later in 2020. No action is required from KORE customers.
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. Each KORE customer has a separate database—your data is not commingled with that of other customers.
KOREAuth is an identity provider used by KORE products. It can federate with your existing single sign-on (SSO) system so that users won’t need to sign into KORE separately. When a KORE product needs to verify a user’s identity, it sends a request to KOREAuth. If federation is enabled, KOREAuth then becomes a relying party and relays the request to your identity provider. KOREAuth offers federation with Active Directory Federation Services (AD FS) and OAuth.
Note: This section only applies to existing deployments which don’t use KOREAuth yet. KORE plans to migrate these deployments to KOREAuth in the future.
Each of KORE’s products integrate with your CRM’s authentication flow. Once a user authenticates in your CRM environment, loading a page containing any KORE element activates the KORE Authentication Module. This requests authorization from the CRM system without interrupting the user. Once the authorization is granted, the user’s token is used to access pages served by the KORE web server.
If you use Dynamics, this is handled through a query string and security token. For Salesforce, it is handled via OAuth. Salesforce also requires each individual user to click an “Authorize KORE” button; this generates a unique token which allows KORE to make API calls as the user.
Important: Microsoft is making changes to their authentication process. For organizations new to KORE and using Dynamics, use application registration and application users instead of the Service account.
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.
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 Processors 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 (like “account” or “activity”) to RabbitMQ. RabbitMQ creates its own queue object using this information, and the Change Processor deletes the original queue object from your CRM.
KORE’s Queue Processors request ordered queue objects from RabbitMQ. (RabbitMQ ensures that the same queue object isn’t sent to multiple Queue Processors.) A 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 RabbitMQ.
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 RabbitMQ, and then delete the original Queue objects from the SQL Server database. The Queue Processors take the Queue objects from RabbitMQ, 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.