Rebuild employee projections
Recomputes per-employee projections from scratch. Use this when what a page shows looks out of step with the recorded history.
What is a projection?
The app calculates several summaries per employee in advance — the data a page reads when you open it. Each of these projections is built from the recorded history (time off requests, timesheet submissions, terms changes…) and kept up to date as new changes arrive. If a projection ever gets out of step (after a failed migration, a manual data fix, or an update that introduced a bug), rebuilding it from the history restores it to a known good state.
Projections this job rebuilds
| Projection | What it backs |
|---|---|
| Employee search | The employee directory and search bar |
| Employment periods | Each employee’s current and historical employment terms |
| Time off employee projection | Planned, active, and used time off per employee |
| Time-bank balance | Account balances per employee |
| Accrual forecast | Forecasted upcoming accruals |
| Timesheet weekly projection | Per-week timesheet aggregates |
| Timesheet statements | Each employee’s pending/ready/submitted statements |
| Policy activity | The activity each time off policy uses, per employee |
| Approvals inbox | The manager’s “to approve” list |
| Notification user view | The notifications feed per user |
How it works
- Loads the scope — by default, every employee in the workspace
- For each employee, rebuilds each projection in turn — most are rebuilt by processing the employee’s history again, exactly as when it was first recorded
- For some projections, a second pass runs after every employee is rebuilt — e.g. whether someone is a manager, which depends on every employee’s manager being known
Parameters
| Parameter | Description |
|---|---|
| Projection | The projection to rebuild. Defaults to all. Picking a single projection narrows the work — useful when you know which one is wrong |
| Employee (optional, rebuild a single employee) | Rebuild only this employee’s projections |
| Org Unit (optional, rebuild employees in this org unit and its descendants) | Rebuild every employee in this org unit and the units below it. Ignored when an employee is set |
When the run is limited to one employee or org unit, the second pass is skipped — it assumes every employee was just rebuilt.
Job results
| Metric | Description |
|---|---|
projection | The target that was rebuilt (all or a specific key) |
scope | all, employee:<id>, or org_unit:<id> |
success_count | Employees rebuilt without error |
error_count | Employees the rebuild failed on (see the run details for the per-employee errors) |
When to run
- After importing data from another system
- After fixing invalid data with a migration
- When the pages look wrong for a single employee (pick that Employee to limit the run)
- After an incident report that mentions one of the projections by name
Auto-trigger on backfill
When the job runner starts and finds a projection completely empty although there are employees, it schedules this job automatically. That is a safety net for new installations and restored backups.
Troubleshooting
| Issue | Solution |
|---|---|
| Run takes a long time | Rebuilding all projections for every employee is the most expensive option. Scope down to a single projection or a single org unit when you know what you’re trying to fix |
| Errors on a few employees | Open the job run details to see the per-employee errors. Often it is a reference to something that was deleted, which can be fixed with an edit — then rebuild that single employee again |
| Projection still looks wrong after rebuild | The rebuild processes the history with the same logic as the live app. If that logic has a bug, rebuilding won’t fix it — contact support |