Skip to main content

Applying Reporting Fields Retroactively

Learn how to retroactively apply logging field tracking into data fields from projects.

Written by Andrew Flowers
Updated over a week ago

Overview

This feature lets you apply reporting updates retroactively across historical project and task data, not just during normal day-to-day task completion. It is designed for teams that add or adjust reporting mappings after projects are already active or completed and need a safe way to bring past records in line with current reporting rules.
​

Instead of opening projects one by one, you can run a guided retroactive update flow that previews what is already aligned versus what still needs updates, then apply changes in one controlled action.'

Key Benefits

  • Backfill historical reporting at scale - Apply updates across many existing projects and tasks without manual record-by-record edits.

  • Improve reporting consistency - Align older data with current reporting configuration so dashboards, exports, and audits are more accurate.

  • Reduce risk with preview-first workflow - Review counts/status before applying changes so you know what will be affected.

  • Keep future behavior intact - Retroactive updates align historical records while preserving normal forward task completion reporting behavior.

How To

Use this workflow when reporting mappings were added or changed after projects had already launched.

1. Open the project template where you want to update log fields.

Confirm each relevant task has reporting configured (resource target and date field key where required).

2. Open the retroactive update action.

In the options menu for the template/workflow, click the retroactive reporting action (for example, "Report completions retroactively" or equivalent feature label in your environment).

3. Run the preview (dry run / scan).

What you should see:

  • Counts for records already aligned (reported/synced)

  • Counts for records that still need updates (not reported/not synced)

  • Status split by project state where applicable (active vs completed)

4. Review scope before applying.

Confirm the counts match your expectations and that the update should include the intended resource targets:

  • Project

  • Client

  • Plan

  • Plan Year

5. Apply retroactive updates.

Click the confirm action (for example, "Yes, Report") to execute updates for records that are not yet aligned.

6. Verify the result.

What you should see:

  • Success feedback after processing completes

  • Updated counts showing fewer or zero remaining unreported/unsynced records

  • New task completions continue reporting correctly going forward

7. Re-run preview if needed.

If mappings changed again (new field key, resource target changes, task updates), re-run the preview before applying another retroactive update.

Best Practices

  • Use date fields for completion-time reporting to avoid mismatched field-type behavior.

  • Start with preview and validate counts before every apply run.

  • Run during lower-activity windows if processing a large historical dataset.

  • Keep a note of before/after counts for audit tracking.

Troubleshooting

  1. I do not see the retroactive update option.

    1. Make sure at least one task has valid reporting configuration (resource target plus date field key where required). Refresh and reopen the options menu.

  2. Preview shows no records to update, but I expected some.

    1. Confirm you are in the correct template/workflow and that task names/mappings match the projects/tasks you expect to update.
      ​

  3. The update completed, but some records still show not synced.

    1. Re-run preview and review which resource target(s) are missing mappings. Update configuration, then run again.
      ​

  4. Future task completions are not reporting correctly after retroactive run.

    1. Validate the underlying task reporting mapping (resource target + field key type) and test by completing a new task. If the issue persists, log it as a separate follow-up bug with example project/task IDs.

This feature is intended to safely align historical reporting with your current configuration. Use preview-first execution and clear mapping validation to keep retroactive updates predictable and reliable.

Did this answer your question?