Keep project codes stable across exports
Maintain identifiers through renames, archived work and downstream mappings.
Use stable project identifiers and keep display names separate. Renaming a project should not make historical exports look like a different project or merge unrelated work.
Create a small mapping register
For each project, store an internal code, current display name, owner, active/archive state and any receiving-system code. Use the mapping consistently in templates and exports. If the merchant does not expose your required identifier, test whether an approved custom field or documented mapping can preserve it. Do not assume matching labels establish identity.
Work through a rename before it happens
In a fictional example, project PR-04 changes its name from “Launch” to “Autumn rollout.” PR-09 is a different client’s “Launch.” Joining on the word Launch would mix records. Keep PR-04 stable and retain the earlier name as context. If a downstream system requires a new code, record an effective date and the explicit old-to-new relationship instead of overwriting the old file.
Protect codes during spreadsheet work
Codes such as 00042 are identifiers, not quantities. Import them as text when using a spreadsheet and inspect the resulting values before joining records. Microsoft documents explicit text/CSV import controls; the correct choice depends on the receiving file. A custom display format can make zeros visible without restoring an identifier that was already altered, so validate the underlying text against the original.
Decide how archived work is represented
Close a code to new entries without losing the ability to interpret historical records. Test a late correction against an archived project in your actual product and plan. If it cannot be edited safely, use a separately controlled adjustment process accepted by the recipient. Do not reactivate broad access or reuse an old code simply to force an import through.
Continue this work-record check
Use the linked guide for the next decision in this workflow. Keep your original records separate from experiments and record any unresolved requirement before changing a live process.
Sources and boundaries
Primary documentation supports the dated product facts. Proposed checks and fictional examples are our editorial method, not observed product results.
- Time Doctor — export · checked September 23, 2026
- Microsoft — import · checked September 23, 2026