[DRAFT] BigPicture Synchronization with Jira - lag time causes

Title

Delay (lag) in synchronization between Jira and BigPicture (dates, scheduling, and other fields)

Symptoms

If facing one or more of the following:

• An issue has dates set earlier than its parent; after enabling Auto top‑down on the parent, the child is expected to adjust immediately, but:

  • Jira issue history shows that the date change was applied.

  • The BigPicture box UI still shows the old dates several hours later.

• Jira’s issue history indicates that dates/fields were updated automatically by the system, but:

  • The same values in BigPicture appear unchanged for a noticeable period.

• After some time has passed (without manual intervention), the task in BigPicture eventually “catches up” and displays the expected dates/values.

• The behavior is reproducible with different fields (not only scheduling mode), and seems to be related to sync timing rather than incorrect configuration in a single case.

Cause

This behavior is usually not a bug but the result of how synchronization and scheduling rules work in BigPicture. The underlying causes fall into several categories:

1. Live sync configuration and scheduling frequency

   • BigPicture relies on live synchronization plus scheduled/background jobs.

   • If live sync is configured with a delay or low frequency, there can be a noticeable lag between:

     • When Jira records a change in issue history, and

     • When BigPicture picks up and reflects that change in the UI.

2. Large synchronization queues / many concurrent changes

   • When many tasks or fields are updated in a short time (e.g., bulk updates, large plans):

     • Changes are queued for processing.

     • A large queue can cause a temporary backlog.

     • Some updates may only be applied on the next scheduled synchronization.

3. Interacting scheduling rules (top‑down, bottom‑up, dependencies)

   • Tasks can be influenced by multiple scheduling rules:

     • Auto top‑down (parent drives children).

     • Auto bottom‑up (children drive parent).

     • Dependencies and other constraints.

   • When a task is affected by more than one rule (e.g., a child task is Auto bottom‑up, while its parent is Auto top‑down), they may conflict. In such cases:

     • One rule can override the other (e.g., bottom‑up taking precedence).

     • The final result may differ from the user’s expectation and appear as if the update was “ignored” or delayed.

4. Task status and scope / filter exclusions

   • Certain tasks may be excluded from scheduling or sync‑driven updates:

     • Example: tasks in Done (or equivalent final status) may be excluded from scheduling automations.

     • Filters, scopes, or box/module configurations can hide tasks or prevent some operations from applying.

   • As a result, even though Jira shows a change in history, BigPicture may:

     • Not apply scheduling updates.

     • Or not visibly display the updated task in the current view.

5. UI refresh and cached view effects

   • The synchronization can complete in the background, but the module view (e.g., Gantt) might not refresh immediately.

   • Until the view is reloaded or refreshed, users may see stale values even though the underlying data is already updated.

These mechanisms are part of BigPicture’s architecture and apply generally to all synchronized data (dates, scheduling mode, other mapped fields), not only to the specific parent/child date scenario.

For reference on live synchronization behavior and configuration, see:
https://appfire.atlassian.net/wiki/spaces/DLP/pages/2212236037

Resolution

Use the steps below to verify configuration, clear potential backlogs, and confirm whether the observed delay is expected behavior.

1. Verify the change in Jira

1. Open the affected Jira issue(s).

2. Check the Issue History:

   • Confirm when the field/date changed (timestamp).

   • Confirm what changed (old value → new value).

3. Note the time when the change is visible in BigPicture for comparison.

If Jira history shows an automatic change at 12:00 and BigPicture still shows the old value at 16:00, proceed with the steps below.

2. Check live sync configuration

1. Review your live sync configuration in BigPicture:

   • Frequency or interval of updates.

   • What events/fields are included.

2. Compare your settings against the guidance in the Live sync documentation:
   https://appfire.atlassian.net/wiki/spaces/DLP/pages/2212236037

If live sync is configured with longer intervals or conservative settings, a delay (even a few hours under heavy load) can be expected.

3. Check for synchronization queue / backend load

1. Consider whether there were multiple or bulk changes around the time of the issue:

   • Large plans.

   • Many tasks being edited simultaneously.

2. If so, it’s possible the queue has become temporarily clogged.

Action:

• Use the Resynchronization feature in BigPicture:

  • Trigger it for the relevant box or module/scope that contains the affected tasks.

• After resync completes, verify whether:

  • The BigPicture view now matches Jira.

  • The expected dates/fields are in sync.

If a manual resynchronization resolves the mismatch, the root cause was most likely a heavy synchronization queue.

4. Review scheduling rules and constraints (especially for dates)

For cases involving dates and scheduling (e.g., Auto top‑down behavior):

1. For each affected task and its parent:

   • Check the scheduling mode:

     • Auto top‑down

     • Auto bottom‑up

     • Manual or other modes

2. Verify whether multiple rules apply to the same task:

   • Example:

     • The child task itself is in Auto bottom‑up, so its dates are driven by its children.

     • The parent is in Auto top‑down, attempting to constrain the child within its own dates.

3. Check for dependencies and other constraints:

   • Links or rules that prevent the child from moving earlier/later as expected.

If conflicting rules are in place, the effective behavior may differ from a simple “parent pushes child dates immediately” assumption, and may give the impression of inconsistent or delayed updates.

5. Confirm task status and filters

1. Verify that the affected tasks are not in a status excluded from scheduling, such as:

   • Done

   • Closed

   • Custom final statuses configured to be ignored by automations.

2. Check box/module filters and scope:

   • Ensure the tasks are included in the planning scope.

   • Make sure no filters are hiding or partially excluding them.

If tasks are excluded, BigPicture may not apply the scheduling changes, even though Jira history shows field updates.

6. Refresh the BigPicture UI

1. After confirming synchronization and configuration:

   • Refresh the browser tab.

   • Or close and reopen the BigPicture box/module (e.g., Gantt view).

2. Check whether the dates/fields now match Jira.

Sometimes the change is already persisted, but the view needs a manual refresh to display the latest state.

7. When to contact Support

If, after following all the steps above, you still observe:

• Persistent discrepancies between Jira history and BigPicture views, or

• Very long delays that cannot be explained by your live sync configuration or known heavy load,

collect the following information and share it with Support:

• Jira issue keys.

• Screenshots from Jira issue history, showing:

  • Timestamps and values before/after the change.

• Screenshots from BigPicture (relevant box/module) showing:

  • The same tasks and fields/dates in the UI.

• Approximate:

  • Time when the change was made.

  • Time when you expected to see it in BigPicture.

  • Time when it actually appeared (if it eventually did).

• Any recent configurations or bulk operations that might influence synchronization (e.g., changing live sync settings, large imports, bulk edits).

This will allow Support to review synchronization logs and verify whether there is an underlying issue beyond expected architectural behavior.

FAQ

Is this synchronization lag expected behavior?

A short delay can be expected, depending on:

• Live sync settings (frequency and scope).

• Current synchronization queue size and system load.

• Specific scheduling rules and constraints applied to the tasks.

Delays of a few minutes are common under heavier usage. Longer delays (e.g., hours) often indicate either heavy synchronization load, conservative sync intervals, or complex scheduling constraints. If such delays are frequent and unexplained, contact Support with diagnostics.

Does this behavior affect only scheduling mode and dates?

No. The same synchronization principles apply to all fields synchronized between Jira and BigPicture, including but not limited to:

• Start/end dates.

• Status fields.

• Other custom fields mapped for synchronization.

The described rules and potential lag sources are general, not limited to Auto top‑down scenarios.

Why does Jira show the change in history earlier than BigPicture?

Jira logs changes immediately when fields are updated. BigPicture:

• Detects those changes through synchronization processes.

• Applies them according to live sync settings and background jobs.

This architectural difference means Jira history can show a timestamp earlier than when BigPicture finishes processing and displaying the new values.

How can I reduce the delay?

• Review and, if appropriate, increase the frequency of live sync.

• Avoid unnecessary bulk changes during peak times, or plan them with the understanding that they may temporarily load the synchronization queue.

• Regularly monitor and optimize:

  • Box/module configurations.

  • Filters and scopes.

  • Scheduling rules to avoid conflicting setups.

What if my parent is Auto top‑down and child is Auto bottom‑up?

In such a configuration:

• The parent attempts to constrain the child’s dates.

• The child, in Auto bottom‑up mode, is also influenced by its own children.

• In case of conflict, one rule may effectively “win”, often resulting in behavior different from a simple “child immediately matches parent” expectation.

This can look like a synchronization delay or a missed update but is in fact the outcome of rule precedence.

If you’d like, I can now adapt this template for an internal‑only KB (with more technical details/log hints) or a public‑facing article with more user‑friendly wording.