Performance improvements to initial import. Updated default behavior for syncing parent-child collections

The April 17th release delivers additional performance improvements to the sync service and significantly speeds up the initial import of entities.

However, it also slightly changes the default behavior for syncing parent-child collections. Previously, child relations were silently and automatically synced whenever their parent item was shared – regardless of the ‘auto-push’ or ‘auto-pull’ settings in the routings. Starting with this release, related items will only be imported alongside their parent if the routing for their entity type has either the auto-push or auto-pull option enabled.

We recommend reviewing your current routings and enabling auto-pull to Targetprocess where appropriate.

Example:

If you synced Targetprocess Team Iteration as a Jira Sprint, previously all User Stories assigned to that Team Iteration would automatically sync to Jira even if User Story type wasn’t mapped to push/pull automatically in the routings. Now, without auto-push enabled for User Story, they won’t be pushed to Jira along with the parent feature or iteration. Import becomes fully driven by routing configuration.

Below is an example of manual import configuration. Epics and Features won’t sync automatically. They’ll only appear in Jira if a user manually triggers import from the ‘Synced Work’ tab by clicking the Jira profile name. The only exception used to be child collections, which did sync with the parent – until now.

Fig 1: Routings from Targetprocess to Jira

The same for routing from Jira to Targetprocess. When pulling data from Jira, only issues mapped to entity types with auto-pull enabled will be brought into Targetprocess, and only from the Jira projects specified in your routing configuration.

So, if you import a single Epic from Jira, it will only bring along child items if:

• They are mapped, and
• Their routings include auto-pull.

Fig 2: Routings from Jira to Targetprocess