This guide helps support engineers respond to cases where customers report that issue dates or schedules were changed by the System user or app user in BigPicture Cloud. It summarizes what happened in a resolved case and turns it into a repeatable support approach for similar incidents.

• Customer says task dates changed “without consent”

• Jira history shows updates by System user or the app’s technical user

• BigPicture autoscheduling appears to have updated start dates, end dates, or due dates

• Customer asks who made the change and whether it was a human or the app

• Customer wants to pause scheduling, undo changes, or roll back affected issues

If the change was performed by BigPicture automation, explain clearly that the update was made by the app, not necessarily by a named human user. In Cloud, BigPicture uses a technical user for certain operations, so changes may appear in Jira history as coming from the System user.

1. Acknowledge impact

   Recognize that unexpected schedule changes can affect planning accuracy, dependencies, and team trust in the plan.

2. Explain the actor

   Tell the customer that BigPicture can update Jira issues through its technical user in Cloud, so Jira history may show the System user for scheduling-driven changes.

3. Link the behavior to scheduling

   If applicable, explain that automatic scheduling can recalculate and push updated dates to issues based on plan logic, dependencies, or timeline changes.

4. Set expectations about rollback

   Clarify that BigPicture does not provide a built-in global pause for scheduling without changing mode, and there is no direct undo or rollback for task-level issue date changes.

5. Offer practical recovery options

   Provide the available paths: restore from backup, bulk update issues manually, or use exported history/audit information to rebuild previous values.

6. Recommend prevention steps

   Suggest switching to manual scheduling when customers need to stop autoscheduling from changing dates during remediation work.

This is the most complete rollback path if a backup exists from before the change event. It is also the most disruptive because it can affect other data changed afterward.

• Best when a large number of issues were changed

• Best when original dates are not available elsewhere

• Requires customer awareness that all post-backup changes may be affected

If the customer can identify the affected issues and knows the correct target dates, Jira bulk edit is often the most practical remediation path.

• Suitable when the affected set is known

• Works well for medium-sized incidents

• Depends on having the correct replacement values

If audit logs, issue history, or prior exports exist, the customer may be able to reconstruct previous values and semi-automate corrections.

• Useful when many issues were affected

• May require customer-side scripting or analysis

• Support should avoid committing to custom script creation

• Before major schedule changes, export issue data or capture a checkpoint

• Review whether the Box should remain in automatic scheduling mode

• Use manual scheduling during controlled remediation periods if automatic recalculation must stop

• Encourage customers to test schedule changes in a limited scope before broad plan updates

• Ask customers to document the exact time and circumstances if the behavior recurs

The changes visible in Jira history as coming from the System user were most likely performed by BigPicture’s technical user. In Cloud, the app uses this technical user for certain operations, including scheduling-related updates. At the moment, BigPicture does not offer a built-in pause mechanism for all scheduling changes without changing scheduling mode, and it also does not provide a direct undo for issue date changes. The available recovery options are restoring from a backup taken before the change, manually correcting affected issues with Jira bulk edit, or reconstructing previous dates from history or exports.

• Do not promise identification of a specific human user if the history shows the technical user

• Do not promise an in-product undo feature

• Do not promise rollback to a previous state without backup implications

• Do not promise custom scripts or engineering investigation unless there is evidence of product malfunction beyond expected scheduling behavior

Escalate beyond standard support only if the customer provides signs that the behavior was not expected scheduling behavior, for example:

• Date changes occurred while scheduling settings did not support that outcome

• The customer can reproduce unexplained updates consistently

• The scope or pattern suggests a defect rather than normal autoscheduling

• There is evidence that issue history and plan behavior are inconsistent

• Technical user documentation

• BigPicture security and permissions in Jira

• Manual scheduling mode

• Clean install and rollback reference

• Installation and updates guidance