# Rebuild folder and file names retroactively

A one-time workflow recipe that re-applies folder and file building to documents already on the shelf — how it works, the version-history cost per document, and when the support-assisted Refile is the better tool.

Product: content-central · Versions: 7.x · Audience: catalog-administrator · Time: 45 minutes, plus unattended processing · Last verified: 2026-09-05

Canonical: https://help.ademero.com/content-central/workflow/rebuild-folder-and-file-names-retroactively

**At the end of this recipe, documents filed under the *old* naming pattern move themselves under the *new* one — using a property of workflow worth knowing in general: any workflow action that updates a field re-runs folder and file building on that document, and moves it if the result changed.**

That's the whole trick. [Folder and file building](/content-central/administration/folder-and-file-building) normally applies only at capture; a workflow field update makes the engine look again.

## Know the cost before you run it

This recipe touches every document it matches. Per document: a minor version entry (**Properties Updated**) in its history, a re-index, and — the point — a possible move and rename. Which means:

- **Back up first.** Database and documents.
- **Test on a handful** before the catalog-wide pass.
- **Off-hours.** Moving and re-indexing thousands of documents is real server work.
- If the field update could trip *other* rules (field-change triggers), disable those for the duration or scope your rule tightly.

## The recipe

1. **Set the pattern you want** on the document type's **Folder & File Building** page — the recipe re-applies whatever's configured, so configure first.

2. **Create the trigger** (**Administration** > **Workflow** > **Triggers**): a **Content Query**-family trigger scoped to the documents to refile — the catalog or document type, narrowed further by field values if only part of the shelf moves.

3. **Create the action**: **Content - Update Field**, writing to a field the pattern *doesn't* use — a spare text field works; set it to a marker value like `refiled-2026-09`. The write is what re-runs building; using a non-pattern field keeps the update from changing the outcome it triggers. (Bonus: the marker tells you which documents the pass has processed.)

4. **Create the rule** joining them, **Enabled** — and let the Workflow Service work through the matches. Documents whose built path or name differs from where they sit get moved and renamed; documents already in the right place are left in place.

5. **When the pass completes, disable the rule.** This is a one-time migration wearing workflow's clothes — a rule like this left enabled keeps firing on whatever matches next.

**Success check:** spot-check moved documents — new path, new name, a **Properties Updated** and **Moved** trail in Version History — and confirm your marker field reads back on them. A document that *didn't* move either already complied or didn't match the trigger; the marker field tells you which.

## When to use the other tool instead

Content Central also has a purpose-built **Refile** operation — run from Catalog Manager with the system stopped, backups taken, and an authorization code from Ademero support. Reach for it instead when the job is *everything in the catalog*, when you can't afford per-document history entries, or when you'd rather have support in the loop for a high-stakes reorganization. This recipe's niche is the scoped, self-service case: one document type, one pattern change, no downtime.

## What's next

- [Folder and file building](https://help.ademero.com/content-central/administration/folder-and-file-building)
- [Build workflow rules: triggers and actions](https://help.ademero.com/content-central/workflow/workflow-rules-triggers-and-actions)