The Calculated Field That Ate the Budget Code
Brightline Manufacturing has 2,400 active projects. A project custom form includes a text field 'Budget Code' with 18 months of data. Finance wants to replace it with a calculated field that concatenates region, department, and year, because manual entry causes errors. The field appears on six custom forms, 14 reports, three dashboards, and a request queue. It is also used in two API integrations that read and write it. A junior admin suggests changing the existing field type to 'Calculated' and letting Workfront recalculate. Finance wants the change in two weeks. The instance has no sandbox refresh available until next month, and the integrations cannot be updated before the change.
1. Advise whether to change the existing field type to Calculated. Explain the data, reporting, and integration consequences.
Read the worked answer
Do not change the existing field type in place. A text field that people and integrations write to is not interchangeable with a calculated field. Calculated fields are derived by formula and are not manually editable, so changing the type risks losing or invalidating the 18 months of stored values. The two integrations that write to the field will fail or have their writes ignored, and the request queue may stop capturing the value entirely. Any report or dashboard that expects user-entered values will show different results once the formula evaluates.
The safer path is to create a new calculated field, keep the original text field during transition, and treat the change as a migration rather than a settings toggle. The absence of a sandbox refresh until next month is a strong argument against a rushed in-place change. If Finance cannot wait, build and test the formula in a limited form on a small set of projects, but do not repurpose the production field.
2. Design a migration sequence that protects reporting and the two integrations while Finance gets the calculated value.
Read the worked answer
- Inventory dependencies: document the six forms, 14 reports, three dashboards, request queue, and both integrations, including whether each integration reads, writes, or both.
- Create a new calculated field such as 'Budget Code (Calc)' with the region-department-year formula. Add it to the project form first, not the request queue, so requests are unaffected.
- Validate against a sample of existing projects. Recalculate or resave where needed, and compare the formula output with the legacy field.
- Update reports and dashboards to display the new field. Keep the old field visible but read-only or clearly labeled as legacy.
- Change integrations in order: first have them read the new field, then stop writing to the old field. Do not let both integrations write to the calculated field, because calculated values are not accept-write targets.
- Freeze the old field after reconciliation, then remove it from forms only when no report or integration depends on it.
3. What tradeoffs should you explain to Finance about a calculated Budget Code versus the existing text field?
Read the worked answer
A calculated field gives consistency and removes manual entry errors, but it also removes human override. If a project needs an exception code that does not fit the region-department-year pattern, the formula must handle it or the project cannot store it. The formula also depends on the referenced fields being present and populated; a missing department produces a blank or malformed code. Changes to the formula affect all 2,400 projects at once, so governance is essential.
The existing text field is flexible and integration-friendly, but it allows bad data. A hybrid approach is often best: keep a text field for exceptions and external writes, add the calculated field for the standard code, and define which one is authoritative in reporting. Finance should also accept that the calculated value may not update on every historical project until the record is resaved or a recalculation is run, so a one-time reconciliation step is part of the project.