Sync overview

Overview

Automate provides several features for keeping the system in sync with underlying UC applications. This allows for the configuration and management of the UC apps outside of Automate, when required.

Sync feature	Description
Cache control policy	This Automate mechanism provides the ability to pull in the latest live data from the UC application(s) for the entity you’re viewing, or at the time that it’s needed - for example, before executing a change on that entity, to prevent any overwrite or setting conflict. Find out more about cache control policy behavior and configuration in the Data Sync chapter in the Core Feature Guide.
Data sync	This workflow pulls the latest data from the UC apps and updates the Automate cache when ran adhoc, or via a schedule. This is typically used for processes such as overbuild, to pull in the existing configuration from the UC applications or to pull in other changes made in the UC apps outside of Automate. For more information on the sync behavior and configuration see the Data Sync chapter in the Core Feature Guide.

Note

With the cache control policy in place, the need to setup and schedule sync regular syncs should aim to address any gaps that the cache control policy won’t handle.

When to use data syncs vs cache control policy

This section describes some prime use cases and guidelines for determining when a regular or scheduled sync might be required for an entity, instead of using the cache control policy.

Note

These scenarios assume some level of regular configuration being done to the UC apps directly, outside of Automate.

Adding/removing entities in the UC applications directly

If you’re adding or removing entitles, such as users or phones, in the UC applications directly, then a sync is required to pull in new entities or to remove existing entities.

Modifying key values that appear in the list views in Automate via the UC applications directly

If you’re modifying key values that appear in the list views in Automate via the applications directly, such as changing a user’s name, then an update sync may be required.

List view data is driven only from the Automate cache; thus, any updates made in the UC applications will not display in Automate until the entity is viewed in Automate (for example, opening that user), or when an update sync is run.

Extracts run from Automate

Any type of extract that might be run from Automate, such as file dump, Automate Analytics, or billing feed, are based on cached data in Automate. Thus, a sync may be required if those capabilities are in use and any of the critical settings in those extracts are being managed outside of Automate.

External clients accessing Automate via the API

External clients accessing Automate via the API have the cached flag available to request Automate cached data (cached = true), or to have Automate retrieve the latest data from the UC applications before responding (cached = false). Thus, the presence of this external client does not require a regular sync to be run as it can (and likely should) request the latest data in any case depending on the use case.

Any other mods made on the entity

Any other mods made on an entity, such as call forward on a line via the CFwdALL softkey, will be pulled in when the record is viewed, and so won’t necessarily require a sync. For example, if the only concern is that when executing an update to an entity, that the latest current settings are shown, then the cache control policy handles this without the need for a regularly scheduled update sync.

Consider the Sync Hierarchy

When running a sync, manually or via schedule, the hierarchy (customer or site) at which you’re running the sync determines where the items are pulled into. For example:

• A sync at the customer level pulls data in at customer level

• A sync at a site pulls data in at the site

For this reason, when setting up the sync, consider its purpose. If the items being pulled in need to be in a site, it may be more efficient to set the sync up at the site level, and run the sync at the site rather than syncing in at the customer level, and then having to move the various elements. This can even be done as a once-off sync, and using model type lists and model instance filters to grab the data relevant for the site.