Question
Mapping Error: Jira Align Connector Skips Unrecognized Jira Field Types
Cig Dey
0 reputation · 19 Oct 2023, 03:51 UTC
35.9K views1
Loading…
0 reputation · 19 Oct 2023, 03:51 UTC
Jira Align's Jira Software connector is documented to skip records when it encounters an unrecognized Jira issue type or custom field type, logging a mapping error rather than failing the entire sync batch. Because unsupported fields are silently ignored rather than raising a hard error, excluded data may not be immediately apparent.
The unresolved behavior concerns concurrent modifications. When a story's story points are updated in Jira Software and its scope is adjusted in Jira Align within the same sync window, the platform relies on a last-write-wins strategy. The product does not expose a deterministic conflict-resolution policy; instead, which value becomes authoritative depends on sync timing and connector configuration.
Version-sensitive behavior adds further uncertainty. Different Jira project types expose different field models, so the connector may behave differently depending on the target project configuration. Administrators can configure field mappings to reduce conflicts, but mapping alone does not resolve the underlying ambiguity when both systems modify the same record simultaneously. Specific connector versions and sync intervals may alter observed behavior.
Given these constraints, how should teams determine which system's estimation value persists after a concurrent update? Does the connector's skip behavior for unrecognized fields interact with conflict resolution in a way that amplifies data loss? What verification approach can confirm whether a specific Jira Align release applies last-write-wins deterministically or leaves the outcome dependent on connector scheduling?
35275 reputation · 19 Oct 2023, 14:42 UTC
Teams cannot reliably determine which system’s estimation persists after a concurrent update without project-specific verification. The connector is documented to skip records with unrecognized Jira issue types or custom field types and log a mapping error instead of failing the batch. Conflict resolution for the same record updated in Jira Software and Jira Align in the same sync window is described as last-write-wins with no exposed deterministic policy. Which value becomes authoritative depends on sync timing, connector configuration, and the target Jira project’s field model.
The skip behavior for unrecognized fields can amplify data loss in concurrent updates. If the estimation field is unrecognized in the mapping, the connector omits it from the sync entirely. A concurrent change in the other system can then appear to win by default, while the skipped field’s value is silently lost rather than conflicted.
Last-write-wins is likely implemented at the sync job level based on the timestamp the connector observes when it reads Jira Software and when it writes to Jira Align. Because the policy is not exposed, the outcome is likely dependent on connector scheduling and sync interval rather than a deterministic merge rule. Version-sensitive behavior is likely: older connector releases may handle unrecognized types with varying degrees of silence versus error propagation, and sync interval changes can shift which write is seen last.
Current verification is required. Behavior is version and project-configuration dependent, and without explicit audit logging of which system’s value prevailed, teams risk decisions based on stale or missing data.
One missing diagnostic detail that changes the recommendation: the exact Jira Align release and connector version in use, plus the configured sync interval. With that, the verification can be scoped to documented changes for that release.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
jiraalign