Workspace operations

Workspace operations are maintenance jobs that act on many records at once, rather than a single one. You reach them from Graph sync in the Admin part of the sidebar.

Every job on this page reaches further than your own workspace: each one runs across every workspace on the deployment. That is why they all carry an All workspaces label. It is safe — none of them delete or overwrite anyone’s records — but it does mean the numbers you get back cover more than your projects.

Use them rarely — after a system change, or when something looks out of step. They don’t use any AI, so they cost nothing to run, and every job is idempotent: running it twice does no harm.

Every job runs in the background. You press the button, it comes back straight away, and a live progress log appears underneath showing what it’s doing. You can leave the page or close the browser — the job keeps going on the server, because nothing about it depends on your browser staying connected.

Note

These jobs need write access, so the buttons only work for accounts with the right permissions. For jobs that affect only one project, use that project’s own Jobs & queues page instead.

Graph jobs

ddx PMO keeps a knowledge graph of how everything connects. Two jobs keep it in step with the underlying records.

Re-project into the graph

Rebuilds the graph from scratch out of the underlying records. It replays projects, organisations, ingested items, attachments, register entries, evidence links, themes, topics (including merged ones), the links between topics and records, and the links between related records. It rebuilds links rather than duplicating them, and removes nothing, so it’s safe to repeat.

Run this after the graph store is replaced or reset, or if you suspect the graph has drifted out of step. You have to click twice to confirm before it starts.

It takes several minutes — usually five to ten. Watch the live log, or come back later; when it finishes, a summary appears with a count for each kind of record. If any records failed to go in, the summary turns amber and says how many: those are missing from the graph, and the log names them.

Caution

This one is the heaviest job on the page. It rebuilds the graph for every workspace on the deployment, not just yours.

Reconcile graph

A lighter check than a full re-projection. It compares record counts between the two stores and, where they differ, replays anything missing from the graph and removes anything left over. This runs automatically once an hour, so you only need the button if you want to reconcile straight away. (See Backfill vs reconcile in the glossary for the distinction.)

Identity jobs

These two repair the links between people and their accounts. Run them in the order below.

Backfill user emails

Re-syncs every team member’s email addresses from your sign-in provider. Run this once after a deployment that adds the address store, or if a member’s address seems to be missing.

Backfill stakeholder links

Re-matches every stakeholder to the workspace user who is the same person, using current names and email addresses. Run it after the email backfill so the freshly-synced addresses are taken into account.

Tip

Order matters: addresses first, then matching. Run Backfill user emails, wait for it to finish, then run Backfill stakeholder links.

If the progress log stops updating

The log is only a view of the job — it is not the job itself. If it turns amber and says the progress feed dropped, that means this page briefly couldn’t reach the server. The job carries on regardless. Leave it a moment and it reconnects on its own; refreshing the page is also fine.

The one thing that genuinely means “it didn’t work” is a red message saying the job couldn’t start. Anything else — a dropped connection, a closed browser, a laptop that went to sleep — leaves the job running on the server.