Freshdesk Dynamics 365 CRM Sync...overwritten by updated information from Freshdesk. Figure 1:...

Version 2.1, 19 March 2019

[email protected]

Freshdesk <-> Dynamics 365

CRM Sync

Seamless template guide

© Recursyv Ltd, client confidential 1

Table of Contents

1. Document overview ..................................................................................................................................................................... 2

2. Freshdesk <-> Dynamics 365 sync using the Seamless service .................................................................................. 2

3. Data mappings ............................................................................................................................................................................... 2

3.1 Company / Account ............................................................................................................................................................ 3

Account record matching .......................................................................................................................................................... 3

Pre-requisites .................................................................................................................................................................................. 3

3.2 Contact..................................................................................................................................................................................... 4

Contact record matching ........................................................................................................................................................... 4

Synchronisation rules .................................................................................................................................................................. 5

3.3 Ticket ........................................................................................................................................................................................ 5

3.4 Freshdesk reference data .................................................................................................................................................. 7

Freshdesk agent ............................................................................................................................................................................ 7

Freshdesk group ............................................................................................................................................................................ 9

4. Service pre-requisites .................................................................................................................................................................. 9

4.1 Freshdesk ................................................................................................................................................................................ 9

4.2 Dynamics 365 ........................................................................................................................................................................ 9

Recursyv Dynamics 365 solution .......................................................................................................................................... 10

5. Known issues ............................................................................................................................................................................... 11

Created date time zones .............................................................................................................................................................. 11

Synchronising closed tickets ...................................................................................................................................................... 11

Freshdesk request limits .............................................................................................................................................................. 12

6. Tenancies ...................................................................................................................................................................................... 13

7. Service fair usage ....................................................................................................................................................................... 13

7.1 Understanding message allowances and message consumption.................................................................. 13

7.2 Message consumption sample scenarios ................................................................................................................ 14

8. Data location and security ...................................................................................................................................................... 14

9. Operational changes ................................................................................................................................................................. 15

9.1 Configuration changes ................................................................................................................................................... 15

9.2 Logging................................................................................................................................................................................. 16

10. Support .......................................................................................................................................................................................... 16

11. Appendix 1: The architecture of the Seamless service ................................................................................................. 18


1. Document overview

Author David Reinhardt

Version 2.1

Publication date 19/02/2019

Version history • 2.1 – Updated with new features (Additional ticket fields)

• 2.0 – Updated with new features (Freshdesk Agents, Freshdesk Groups)

• 1.0 – First published version

This document forms part of a set of 3 documents which will detail our overall contractual relationship:

• Proposal Document: An overview of the services to be provided and the cost thereof

• Service Guide: A detailed description of the regular service provided by Recursyv to you (this

document)

• Standard Terms of Service: Contracting terms and conditions

2. Freshdesk <-> Dynamics 365 sync using the Seamless service

The Seamless service is a cloud-based integration framework allowing you to connect different applications

to one-another by passing data or events through a cloud hosted service built and operated by Recursyv.

The Freshdesk <-> Dynamics 365 Sync is a templated instance of the Seamless service which is designed to

quickly deploy syncing of ticket records from Freshdesk into Dynamics 365.

Ticket records are reflected in Dynamics for visibility purposes, any updates made in Dynamics may be

overwritten by updated information from Freshdesk.

Figure 1: Seamless Overview Diagram

A more detailed breakdown of the Seamless technology is included in the final section of this document.

3. Data mappings

Data mappings are based on a “vanilla” implementation of Freshdesk and Dynamics. If custom fields have

been added, these will need to be mapped as part of the initial configuration.

Freshdesk

Freshdesk

connector

plugin

Microsoft

Dynamics

connector

plugin

Recursyv Seamless Service

Microsoft

Dynamics 365

Tickets,

Agents,

Groups

Customers &

Contacts

Customers &

Contacts

Encrypted

data

messages

Encrypted

data

messagesTickets,

Agents,

Groups


3.1 Company / Account Freshdesk table: Company

Dynamics table: Account

Sync is bi-directional.

Freshdesk Field Dynamics Field Description

id rec_freshdeskid Unique reference number added to Dynamics for

Freshdesk Company identifier

dynamics_id accountid Unique reference number added to Freshdesk for

Dynamics Company GUID

name name Company name

description description Company description

note rec_freshdesknotes Custom field added to Dynamics to store Freshdesk

notes information

created_at overriddencreatedon When creating a record in Dynamics, the Created On

Date (createdon) can be overridden with data from an

external system.

Account record matching The integration will look for existing records before creating new ones. If an existing record is found, it will

be updated with any changes.

Account matching will be performed using the following fields:

• Company ID / Dynamics ID

• Company name

Pre-requisites A custom field named dynamics_id must be created in Freshdesk against the Company table/entity before

the integration can be activated. This attribute is used to keep Freshdesk Companies and Dynamics 365

Accounts in-sync, and prevents duplicate records being created.


3.2 Contact Freshdesk table(s): Contact and Agent

Dynamics table: Contact

Sync is bi-directional.


id rec_freshdeskid Unique reference number added to Dynamics for

Freshdesk Contact identifier

dynamics_id contactid Unique reference number added to Freshdesk for

Dynamics Contact GUID

name firstname & lastname Freshdesk holds the requester’s name as one field

whereas Dynamics splits it into two. The integration

will split the name using the first space, period or

underscore in the name as the delimiter between first

and last names.

email emailaddress1 Email address

phone telephone1 Contact business phone number

mobile mobilephone Contact mobile phone number

title jobtitle Contact job title

description (labelled

About on the front-

end)

description Contact description

company_id parentcustomerid Resolves to the parent Company / Account in either

system


date (createdon) can be overridden with data from an

external system.

Contact record matching The integration will look for existing records before creating new ones. If an existing record is found, it will

be updated with any changes.

A custom field named dynamics_id must be created in Freshdesk against the Contact table/entity before the

integration can be activated. This attribute is used to keep Freshdesk contacts and Dynamics 365 contacts

in-sync, and prevents duplicate records being created.

Contact matching will be performed using the following fields:

1. Contact ID / Dynamics ID

2. Email address


If a record cannot be identified, a new Contact will be created (which will contain the Freshdesk ID to ensure

duplicates are not created).

Synchronisation rules Contact sync

• Contacts can only be created in Freshdesk if they have one of an email address, phone number or

social media handle populated. If none of these data attributes are populated, then the creation will

fail.

• In Dynamics 365, contacts can be created with these three attributes left blank. Seamless will not

attempt to synchronise an empty contact to Freshdesk until at least one of these attributes are

populated.

Freshdesk Agents

• Freshdesk Agents are synchronised from Freshdesk to Dynamics 365 as contacts flagged as

Freshdesk Agent, so that cases can be synchronised from Freshdesk tickets where the requester is an

agent.

• These agent contacts will be created as read-only in Dynamics 365.

3.3 Ticket Tickets will be mapped to Dynamics Case records. The mapping will be based upon the unique Freshdesk ID

which will be held against the Case record in CRM.

Freshdesk table: Ticket

Dynamics table: Incident (identified as Case on the front-end)

Sync is one-way from Freshdesk into Dynamics.


id rec_freshdeskid Unique reference number for Freshdesk ticket

This field has been set a searchable field in the

Dynamics Quick Search view so the user can search

by Freskdesk ID in a Dynamics Case view.

requester_id or

company_id

customerid When the Freshdesk Requester has a parent

company, this is resolved to the parent company.

When the Freshdesk Requester does not have a

parent company, this is resolved to the contact or

agent that requested the ticket.

requester_id primarycontactid If the company_id/customerid has been synced to a

parent company, then this field in Dynamics will be

synced to contain the contact that requested the

ticket.


If the company_id/customerid has been synced to a

contact, then this is left blank in Dynamics.

subject title Ticket subject / title

description_text description Ticket descriptive notes

This field has been set a searchable field in the

Dynamics Quick Search view so the user can search

by for terms in the descriptive notes in the Dynamics

Case view.

priority prioritycode Priority rating

The options in the field in Dynamics will be

configured to match those in Freshdesk.

source caseorigincode The source of the ticket

The options in the field in Dynamics will be

configured to match those in Freshdesk.

status statecode and statuscode

Dynamics stores statues in a two-level hierarchy. The first level, statecode, is either Open,

Closed or Resolved. Closed and Resolved will be Inactive statuses within Dynamics.

The second level, statuscode, adds a status reason.

Freshdesk value Dynamics Status Dynamics Status Reason

Open Active Open

Pending Active Pending

Waiting on Customer Active Waiting on Customer

Waiting on Third Party Active Waiting on Third Party

Closed Canceled Closed

Resolved Resolved Resolved

type rec_freshdesktype The type of the Ticket in Freshdesk, e.g. Question,

Problem etc.

responder_id rec_freshdeskagentid The Freshdesk Agent field will be mapped to a

lookup to a custom entity within Dynamics rather

than using the Owner field. This is specifically to

avoid the need to acquire Dynamics licenses for each

Freshdesk user.

group_id rec_freshdeskgroupid The Freshdesk Agent field will be mapped to a

lookup to a custom entity within Dynamics.

This ensures that the changes to the group structure

in Freshdesk can be reflected in Dynamics.


responder_id or

group_id

ownerid When an Agent is marked as the Responder on a

Freshdesk Ticket, then the Dynamics Case is assigned

to the Dynamics User related to that Agent.

When an Agent is not provided as the Responder,

but a Group is on a Freshdesk Ticket, then the

Dynamics Case is assigned to the Dynamics Team

related to that Freshdesk Group.

Otherwise, the Case is assigned to the integration

user.

fr_due_dy responseby First response due by

due_by resolveby Resolve ticket by

tags rec_tags Tags

The Tags field has been set in the Dynamics Quick

Search view so the user can search by tags in a

Dynamics Case view.


date (createdon) can be overridden with data from an

external system.

updated_at rec_freshdeskclosedon Added to Dynamics solution

Using a custom field allows the integration to reflect

the close date as it was closed in Freshdesk rather

than when Dynamics resolves the record. This

attribute will only be set in Dynamics once the Ticket

in Freshdesk has a status of Closed or Resolved.

3.4 Freshdesk reference data Freshdesk agents and Freshdesk groups need to be synced into Dynamics to act as reference data for

tickets.

Freshdesk agent Freshdesk table: Agent

Dynamics table: Freshdesk Agent rec_freshdeskagent



id rec_freshdeskid Freshdesk’s unique reference number for Freshdesk

agent


contact.name rec_name Freshdesk agent’s name

contact.email emailaddress Freshdesk agent’s email address

The Recursyv Dynamics solution provides the ability to associated Freshdesk agents with a Dynamics user.

This allows the owner of the record to be replicated across both systems.

Associating Freshdesk Agents with Dynamics Users needs to be performed in Dynamics 365 by an

administrator, via the Freshdesk Agent form.


Freshdesk group Freshdesk table: Agent

Dynamics table: Freshdesk Agent rec_freshdeskagent



id rec_freshdeskid Freshdesk’s unique reference number for Freshdesk

group

name rec_name Freshdesk group name

description rec_description Freshdesk group description

Associating Freshdesk Groups with Dynamics Teams needs to be performed in Dynamics 365 by an

administrator, via the Freshdesk Group form.

4. Service pre-requisites

In order to successfully deploy this integration, the following pre-requisites will be required.

4.1 Freshdesk • A Freshdesk user account needs to be nominated and the API key provided for connection to Freshdesk.

It is important that once this is implemented, the API key is not refreshed

o When the tickets are read from Freshdesk, a user account is used to do this. Each Freshdesk

user is assigned an API key by Freshdesk, and this key is independent from their password,

so as they change their password over time, as long as they do not refresh their API key the

service will still be able to connect.

o The user account used will need full access to read all tickets and both read and write access

to all companies and contacts.

o Recursyv’s recommendation is that an integration account is setup but, bearing in mind the

potential licensing implications of this, it is noted that it is not technically necessary.

o In the absence of an integration account, Recursyv recommend that the system

administrator’s account is used.

• Cross reference fields will need to be added to Company and Contact.

4.2 Dynamics 365 • A Microsoft Dynamics user with one of the following licenses will need to be provisioned:

o Dynamics 365 Enterprise Edition Plan 1 – Tier 1 to 5

o Dynamics 365 for Customer Service, Enterprise Edition

o Dynamics 365 for Sales and Customer Service, Enterprise Editions (SMB Offer)


• It is recommended that this is a dedicated user with an identifiable name (e.g. Integration) as this will

allow creation of views filtered by this user and identification of amendments made by the integration

service.

• When Cases, Customers and Contacts are created, they will be assigned to the user account being used

by Seamless.

• The Dynamics 365 solution file provided by Recursyv will need to be deployed.

Recursyv Dynamics 365 solution The contents of the solution file are as follows:

• On the account entity

o Attributes

▪ rec_freshdeskid: used for cross-reference between Freshdesk and Dynamics 365.

▪ rec_freshdesknotes

o Forms

▪ Freshdesk Company: configured to just display attributes that are synchronised

between Dynamics 365 and Freshdesk.

o Views

▪ Freshdesk Companies: A view of accounts that have been synchronised from

Freshdesk Companies.

▪ Unsynchronised Companies: A view of accounts that are awaiting synchronisation to

Freshdesk Companies.

o Key: A restraint has been configured to prevent duplicate accounts with the same Freshdesk

ID (rec_freshdeskid) being created.

• On the contact entity

o Attributes


o Forms

▪ Freshdesk Contact: configured to just display attributes that are synchronised

between Dynamics 365 and Freshdesk.

o Views

▪ Freshdesk Contacts: A view of contacts that have been synchronised from Freshdesk

Contacts.

▪ Freshdesk Related Contacts: A view of Freshdesk Contacts to use when relating to a

Freshdesk Company.

▪ Unsynchronised Contacts: A view of contacts that are awaiting synchronisation to

Freshdesk Contacts.

▪ Freshdesk Agents: A view of contacts that have been synchronised from Freshdesk

Agents.

o Key: A restraint has been configured to prevent duplicate contacts with the same Freshdesk

ID (rec_freshdeskid) being created.

• On the case entity

o Attributes



▪ rec_freshdeskagentid: a lookup to the Freshdesk Agent entity.

▪ rec_freshdeskgroupid: a lookup to the Freshdesk Group entity.

▪ rec_freshdesktype: the type of the ticket.

▪ rec_freshdeskclosedon: a date and time attribute used to store when a ticket was

closed in Freshdesk.

▪ caseorigincode: configured to include options from the Freshdesk ticket source field.

▪ prioritycode: configured to include options from the Freshdesk ticket priority field.

▪ statuscode: configured to include options from the Freshdesk status priority field.

o Forms

Freshdesk Ticket: a read-only form configured to just display attributes that are

synchronised from Freshdesk to Dynamics 365.

o Views

▪ Open Freshdesk Tickets: A view of Cases that have been synchronised from Freshdesk

Tickets and are still open.

▪ Closed Freshdesk Tickets: A view of Cases that have been synchronised from

Freshdesk Tickets and have been closed.

o Key: A restraint has been configured to prevent duplicate cases with the same Freshdesk ID

(rec_freshdeskid) being created.

• Custom entities

o rec_freshdeskagent and rec_freshdeskgroup, have been created and configured (attributes,

forms, views, icons and keys) as detailed in the data mapping.

• Dashboards

o Freshdesk Customer Service: an example dashboard is provided to display ticket data graphs

that segment data based on priority, type, ownership etc.

• Apps

o Freshdesk: an example Dynamics 365 App has been configured to provide access to just the

entities that are synchronised by Seamless between Freshdesk and Dynamics 365.

5. Known issues

Created date time zones When companies, contacts and tickets are synchronised from Freshdesk to Dynamics 365 for the first time,

the created on date attribute is set as the date and time that the Freshdesk record was originally created.

Issues can arise in the synchronisation if the dates and times stored in Freshdesk use a different time zone

than the Dynamics 365 user that is setup within Seamless. If an error message is raised in Seamless that

states “the date cannot be in the future” then the time zone of the Dynamics 365 user needs to be checked

and re-configured.

Synchronising closed tickets Once a ticket is marked as closed or resolved in Freshdesk, it will be synchronised to Dynamics 365 and the

linked case will have its status changed to canceled or resolved. A canceled or resolved case in Dynamics


365 cannot be updated without re-opening it. Freshdesk users need to ensure that they don’t update

tickets once they are no longer open.

Freshdesk request limits Limits for data requests are placed on the Freshdesk API that is used to read data from and write data to

Freshdesk. Once the call limit has been met, then no further reads or writes can be executed until the retry-

after period has passed.

The number call per hour is linked to your Freshdesk Plan, and will be either 1000, 3000 or 5000 calls per

hour.

For more information on rate limits, please review the following details on the Freshdesk developer portal:

https://developers.freshdesk.com/api/#ratelimit

https://developers.freshdesk.com/api/#ratelimit


6. Tenancies

The Freshdesk <-> Dynamics ticket sync pricing is based on multi-tenant service which means that your

instance shares infrastructure with other instances. This enables Recursyv to provide scale and resilience. It

is important to note that Recursyv use both strict data boundaries and data encryption to ensure no overlap

between instances.

It is possible to subscribe to a dedicated environment enabling you to have your instance of the service

hosted in a dedicated cloud environment. These are available at additional cost but have greater

processing power and higher message limits. If you subscribe to a dedicated environment, you may still

provision multiple tenants within that environment (e.g. if you have a need to create a number of interfaces

between pairs of different systems).

Each tenant must be subscribed to for a minimum of 12 months.

Recursyv are also able to provision test tenants to allow you to carry out development and testing of

plugins and of the service as a whole. These are provisioned as required and are charged on a month by

month basis, with the minimum term of each tenant being one month. Test tenants do not have as much

processing power available and have lower base message allowances.

7. Service fair usage

Your fair usage limits will be determined by the subscription tier you have subscribed to ranging from

300k/month to 5m/month.

Additional messages above the base allowance are used in blocks of 1 million messages and will be

charged as consumed over and above the base allowance.

7.1 Understanding message allowances and message consumption A single message is consumed when a piece of data (either a new record or an updated existing record) is

transmitted from one system to another.

The Seamless architecture is designed with a “fail safe” mechanism to ensure that data changes are always

sync’ed, even if errors occur in the source, target system or the service itself during any individual sync

cycle.

In order to achieve this, the Seamless architecture transmits data in two circumstances:

• When there is a change (i.e. a new record is created or an existing record is updated). Each individual

data change is only transmitted once because Seamless performs data compares.

• Periodically, a data sweep is performed and all records which match a particular criteria are sync’ed.

Within Seamless, the size of this sweep can be controlled, typically by date range, if the source

system API supports this. Additionally, the frequency of this sweep is configurable.

With this in mind, the variables which drive message consumption are:


• Volume of data records in each system as well as volume of change to data records (new records &

edits).

• The size of the data sweep (i.e. what percentage of total records will be covered by the date range

applied to the data sweep).

• The frequency of the data sweep.

All of these variables can be set in Seamless configuration and can be updated in real-time. For the

Freshdesk <-> Dynamics sync, the standard config settings for the data sweep are to pick up records which

have changed in the past 4 days and to perform a complete data sweep every 12 hours. As a reminder, the

data sweep is the fail-safe mechanism, this does not mean that changes will take 12 hours sync.

If this configuration does not prove suitable, Recursyv will work with you to adjust these settings until they

meet your business requirements. There is no services charge for configuration changes within the first

month of operational use.

7.2 Message consumption sample scenarios With the default settings in place, the table below gives an indication of the number of messages

transmitted in a month for scenarios with different data volumes and assumed numbers of data changes

(i.e. new records and record updates).

Account /

Client records

Contact records % records within

the data sweep

New/changed

records per

month (total)

Messages

transmitted per

month

1 000 3 000 25% 300 121 600

5 000 15 000 25% 1 000 609 000

10 000 30 000 25% 2 000 1 218 000

• Record volumes (the first two columns) are assumed to be the same in both systems as they are

being synchronised using Seamless.

• The % of records within the data sweep is driven by the data range setting, the 25% value used for

this calculation implies that ¼ of all records will have had some edit applied to them in the previous

4 days.

If you would like to model your specific scenario, Recursyv can work with you to populate the Seamless data

volume modelling tool.

8. Data location and security

Clients can specify in which Azure region their integration is hosted. Unless otherwise specified, Recursyv

will locate the integration in the UK region.

Seamless does not retain data beyond the time when it is in transit from source system to target system.

This time is governed by the configuration in respect of how often Seamless polls the source system and


posts data to the target system. In the configuration used for the Autotask <-> Dynamics 365 sync, data

should typically be in transit for up to 60 seconds. While the data is in transit, it is encrypted.

The following outlines the scenarios where Seamless holds data.

• Messages are published onto a private service bus in Azure when they have been read from the

source system by the service, and then routinely retrieved from the same bus for writing to the

target system. In this intervening period the messages on the service bus are considered at rest.

Within each tenant, messages are encrypted using an algorithm specific to that tenant rendering the

messages readable by only your instance(s) of the Seamless service.

• In order to identify whether source data has changed, Seamless typically holds a key value and a

hashed checksum value for each record as read from the source system. The key value is sufficient

to uniquely identify a record from the source, usually a primary key value and the checksum is a 16

byte value that is calculated from the data record itself. The checksum is irreversible meaning that it

is not possible to reconstruct the data from the checksum.

• As part of the provisioning of a tenant, Seamless will require details of how to connect to source and

target software interfaces/APIs. Seamless encrypts these details and stores them in its configuration

database.

• Occasionally customers request logging output from Seamless in order to understand the flow of

messages and data. These activity logs are captured in Seamless’ database but are not encrypted. By

default, logging is disabled so this data is only captured at your request (e.g. for troubleshooting

purposes). Logging information does not include data.

Seamless does not hold any other subscriber data.

Bearing in mind the need to ensure the security of client and Recursyv data, the following measures have

been taken to secure the service.

• Data in transit is encrypted using a 128-bit Rijndael based encryption algorithm, with the encryption

keys being unique to each integration tenant.

• Recursyv’s Seamless service sits behind an OV type SSL certificate, sitting in an Azure key vault.

• Recursyv’s databases sit behind a firewall which only allows access from a restricted set of external

IP addresses.

o Recursyv databases store service config details and logging. No client data is stored in these

databases.

o Any connectivity details held in Recursyv’s databases are encrypted using a 128-bit Rijndael

based encryption algorithm, with different encryption keys to those mentioned above.

9. Operational changes

9.1 Configuration changes It is quite likely that over time, you may have a need to change configuration of your use of the service.

Configuration changes include:

• Changes to connectivity details

• Changes to refresh frequency


• Changes to processing capacity

• Redeployment of custom plugins (in the event that you’ve updated the plugin)

• Changes to logging settings (level of detail and data location)

Reasonable configuration changes are not charged during the first month of service usage in order to

ensure that the service is fine-tuned to your needs. After the first month, configuration changes may be

charged on a time and materials basis.

9.2 Logging During the course of standard operations, the logging service monitors and logs exceptions only. Logging

detail can be increased as required, e.g. for troubleshooting purposes. Reasonable volume of logging is not

charged during the first month of service usage. After the first month, more detailed logging may incur

additional charges. If necessary, custom plugin logging can be routed to an alternative location.

10. Support

Support is provided by email during UK office hours and is limited to support for Recursyv product related

matters.

When you raise a new support case with us, we will endeavour to respond to that case within 4 working

hours. Upon response, your issue will be given a priority rating in accordance with the situation. The priority

rating determines the target resolution time as detailed in the table below. Your support case will also be

issued with a unique case reference number for reference purposes.

Priority

rating

Severity Situation Resolution time

1 Business

critical

A business critical standard function is not

operational (e.g. complete system unavailability).

Users unable to work. Serious immediate impact

on day to day business activities. No workaround

available.

8 working hours

2 Major Issues occur such that a business critical standard

function is not operational and is causing user

inconvenience.

Some users unable to work. Potential impact on

day to day business activities. No workaround

available.

12 working hours

3 Material Issues occur but are not causing any immediate

impact on day-to-day business activities. Small

number of users affected. Workaround available

24 working hours

4 Minor Minor or cosmetic software issues occur but are

not causing any immediate impact on the day-to-

day business activities.

36 working hours


In order to provide effective support, Recursyv may request remote access to the source, target or other

systems as deemed relevant.

It may be that there is an issue with the software/service of an underlying vendor. In this case, subject to the

nature of licensing agreements, Recursyv will either raise the relevant support issue or support you in

raising the relevant issue with the vendor.

Support response and resolution target times are on a reasonable endeavours basis and may be subject to

response/resolution times of a 3rd party.


11. Appendix 1: The architecture of the Seamless service

The Seamless service is a cloud-based integration framework allowing you to connect different pieces of

software to one-another by passing data or events through a cloud hosted service built and operated by

Recursyv.

System 1

connector

plugin

System 2

connector

plugin

The Recursyv Seamless Service

Encrypted data

messagesApplication 1 Application 2

Data to be

synced

Encrypted data

messagesData to be

synced

Figure 2: Generic Seamless overview diagram

The Seamless service is built using a micro-service architecture platform and is deployed within Azure to

utilise a number of its integrated services. This also ensures that it takes advantage of the security and

resilience of Azure, as well as providing the ability to specifically geolocate instances of Seamless as

required.

The service is characterised by five key components:

• Recursyv Seamless Service: this is the control framework which governs the flow of data, serialised into

data messages, including the process of looking for data or events in the source system, using the

plugins to perform their roles, encrypting, compressing, decrypting and decompressing data messages

and pushing data into the target systems. It also manages security, load distribution and system

monitoring, etc.

• Messages: these are individual pieces of data that are processed by the service, typically from source to

target. A message could contain raw data extracted from the source system that needs to be replicated

to the target system(s), or it could represent an event that has occurred in the source system that the

target system(s) might need to know about.

• Source System Plugin: this component retrieves data or events from the source system and converts

them into messages so that the Seamless service can publish them onto the Azure service bus. This is

specific to any scenario as there will be variations for each source system and business use.

• Target System Plugin: this component assesses, identifies and converts messages provided by the

Seamless service into data for the target system to use. Like the source system plugin, this will typically

be tailored to a particular scenario.

• Azure Service Bus: This acts as a staging medium for the messages, and eliminates any real-time

dependency between the source and target systems and plugins. It can also be used as an aggregator

to allow information from multiple sources to be brought together or as a disseminator to allow a single

data source to be used multiple times.

Freshdesk Dynamics 365 CRM Sync...overwritten by updated information from Freshdesk. Figure 1:...

Documents

Transcript of Freshdesk Dynamics 365 CRM Sync...overwritten by updated information from Freshdesk. Figure 1:...