There are two different types of data syncs associated with ClientTrack: Configuration Syncs and Replication Syncs1. This section will cover Configuration Syncs, a process that is initiated on demand.

Mechanically, a Configuration Sync (referred to as “Sync”) is the process of deleting all Forms, Workflows, Queries, etc., with an ID between 1000000000 and 1999999999 in the Destination environment and then copying any Forms, Workflows, Queries, etc., in that same ID range from the Source environment.

Not overwriting these items allows for a deleted element in the Source environment to be completely removed in the Destination environment after a Sync.

Most implementations will have two or three environments, but an implementation’s Production (PROD) environment will always play the role of the Destination environment when involved in a Sync. Syncs will normally take about thirty minutes but can take longer depending on an implementation’s database size.

The Destination database is backed up prior to the configuration changes being moved from the Source. The database backup remains in place for a period of 30 days to provide recoverability options to configuration changes for any unexpected behaviors encountered following the Sync process.

For all of the following items, all configuration objects are removed from the Destination environment and replaced with the configurations that are maintained in the Source environment.

Forms including associated Data Elements, Buttons, Help Text, and Rules/Actions.

Workgroups (new and existing) updated in non-production environments will sync associated Workspaces, Menu Groups, Menu Options, Calendar options, Entity configurations, and Form/Workflow assignments. Workgroups are synced based on their name rather than the ID and must use the same name in non-production and production environments.

Dashboards. However, personalized User Dashboards (changes made by individual users) not Sync.

Drop Down Lists including Definitions, Baseline Lists, and List Items.

Workflows including associated Steps, Conditions, and Actions.

Case Note Templates. However, the assignment of a template to specific categories for a specific Organization do not Sync.

Data Explorer Domains including the setup of a Domain, its relationship with other Domains, and the assignment of that Domain to specific Workgroups.

Reports designed in ClientTrack Report Designer, and Report Files create externally with Microsoft Report Builder and uploaded into the Source environment.

Extended ClientTrack Database Objects including:

• Table structures and/or columns prefaced with “CT_” or “CUSTOM_”
• Store procedures prefaced with “C_” or “dnn_” or “aspnet_”
• Database functions prefaced with “C_”
• Database views that start with “CUSTOM_” or “qview_”, with “qview_” only being used for views created from a query (i.e. qview_1000000123)

XML and CSV Import and Export Definitions

Scheduled Asynchronous Task configurations

ClientTrack Portal configurations including the setup of a particular Blog or Forum (blog entries and forum posts are not transferred in a Sync).

Additional System Access options from User Management (Individual User's Permissions that Additional System Access will not Sync).

For all of the following items, none of the configuration objects are removed/replaced from the Destination environment during a Sync.

Client Data

Transactional Data including Services, Assessments, Client Files, Family Members, and all other data related to specific Clients.

Setup Data including Organizations, Programs/Projects, Service Codes, Grants/Funding Sources, Housing Facilities, Providers, Employers, Document Checklists, Items, Evaluation Codes, and Surveys (if applicable). See Configurations that Conditionally Sync for Setup Data Code Lists (not Evaluation Codes).

• If the setup data is not consistent between the Source and Destination environment it will prohibit effective end-to-end testing. Following strict adherence to the setup data creation in Source and then Destination will guarantee the configuration behaviors in the Source environment will persist ahead of the sync process to the Destination.

Issues from Issue Tracking

Data Explorer Questions

Organizational News

User Accounts

Series, Events, and Occurrences

Other System Codes (Financial/Country Codes)

Three configurations in ClientTrack Sync conditionally depending on the environment they were created in:

1.  The Codes Table

The Codes table (not to be confused with Evaluation Codes) will Sync, including each Codes' OrgGroupID.

If you create a Code in the Source environment marked as "All Organizations", it saves in the OrgGroupID table with the value of "-1" and will Sync as expected.

If Users only have specific Organizations selected to have access to a specific Code, after the Syn, the Code will not retain those Organization Access configurations due to the OrgGroupIDs being associated with different values in different environments.

If a User needs to have a Code be accessed by specific Organizations, create it in the Destination environment only or change the configurations post-Sync. Records in the Codes table that had been created in the Destination environment will not be removed by a Sync.

2.  Eligibility Rule Sets

3.  Queries designed in ClientTrack Query Designer

If the query logic is no longer valid due to changes in your database schema the sync process will communicate a warning to the Engineer conducting the sync. The Engineer will communicate any queries that are no longer valid at the close of the configuration sync. The query will still be visible within ClientTrack but will not query against the database until the query logic has been updated.

A similar process is happening with the tables associated with Query Designer and the Eligibility Rule-Sets. When a User creates a Query in the Production (PROD) environment, those Queries will all start with a 2000000000 number and because it is not in initial Sync ID number range, will be left alone during a Sync.

When Workgroups need to be deleted or have a name change, it should be done only in the Source environment and those Workgroups will still need to be mapped to a Workgroup in the Destination environment during the next Sync.

When requesting a Sync, these mappings will need to be provided to your Eccovia contact at the same time as the Sync is requested. This is due to a built-in functionality in the Syncs designed to not to have User Accounts accidentally be caught in limbo with no Workgroup (and therefore unable to login) after a Sync.

When deleting a Workgroup, ensure all users are removed from the deleted Workgroup. When scheduling your configuration sync your Client Success Manager will verify there are no unmapped workgroups. It is important to note that if you make any workgroup changes once the configuration sync has been scheduled you will need to inform your Client Success Manager to allow another validation of workgroups between Source and Destination.

The ClientTrack Sync process includes special provisions for user mappings that aims to reconcile differences in user IDs when synchronizing queries and other configuration items that reference users.

As an example, if a user creates a new query in an implementation / training environment and marks the query as Runnable or Editable by only themselves, the ClientTrack Sync process will identify whether the same user exists in the production database based upon the user’s user name.

If the user does exist in the production database, the query will be appropriately associated with that user. If the user does not exist in the production database, the query will be assigned to a generic, system-generated user called “Missing Training User.”

A ClientTrack Sync also syncs checkout histories related to configuration items such as forms, workflows, and dashboards. User reconciliation during ClientTrack Sync applies to users associated with queries, form checkout histories, dashboard checkout histories, workflow checkout histories, and users associated with eligibility rulesets.

At times, Configuration Syncs to production interfere with Change Data Capture (CDC) and Replication Sync services. Specific steps need to be taken to manage CDC services in conjunction with a Configuration Sync to ensure CDC services continue to run successfully following the sync. Similarly, Configuration Syncs can also interfere with Replication Syncs.

After a Configuration Sync completes, certain tables associated with Replication Syncs may need to be both re-created and repopulated with historical data. For these reasons, Configuration Syncs to production must be performed by Eccovia’s Engineering Department and scheduled according to Eccovia’s Change Management Policy.

Under special circumstances, non-Production databases will be overwritten by a copy of Production. This is generally done for testing purposes only. This is not a sync operation, but it is covered in this document to differentiate this process from a sync. Overwriting a non-Production database with a copy of Production will harmonize the setup data between environments but there are other important implications to consider.

• Any development in process in the overwritten destination inclusive of optional Portal configurations will be removed
• Support issues will be lost in the overwritten destination
• Misalignment of the support numbering system in overwritten destination
• Increased database size of the overwritten destination
• Live Client data is now in a training environment. Extra caution needs to be taken to ensure Client data is not being shared or discussed during the training process
• Client transactional data should be removed but will vacate any testing data.
• The Eccovia Support team may log into your training environment for issue resolution
• Users with access to a training environment can have different user permissions than in production. Ensure the users do not have additional security settings giving them access to data they would not have in Production
• Generated test/sample data will be lost