Summary

  • Deleting a Salesforce custom field removes its unique and required attributes. After restoration, those attributes must be reapplied where needed.
  • Restored formula fields remain disabled until edited and saved. Changed page layouts and removed dependencies can also require manual repair.
  • A field and its data remain recoverable until permanent deletion or the passage of 15 days, whichever comes first. Cleaning up to free field capacity can end that option early.

The most reassuring result of a recovery exercise can be an error message. Try a value the business was supposed to forbid. If the system rejects it for the intended reason, something more useful than a column has come back to work.

Salesforce gives buyers a concrete reason to run that test. Its manual field-attribute restoration guide says deleting a custom field automatically removes its unique and required attributes. After restoring the field, the administrator must put those attributes back if they are needed.

The values can return before the rules that made them dependable. That small gap in a recovery procedure can become a larger gap between the team closing the ticket and the team paying for the subsequent data repair.

A field also has a job saying no

Consider a hypothetical order-reference field. If a business relied on its unique attribute to prevent duplicate references, restoring the old references leaves that attribute to be re-established. Other validation may exist; the question is what this particular setting was responsible for preventing.

The required attribute presents the same problem. A screen full of complete historical records says little about whether the next incomplete record will be accepted. Looking backwards and testing the next transaction examine different behaviours.

This is why business acceptance needs a business owner. The administrator knows how to restore the field. The colleague matching orders knows what an ambiguous reference costs in investigation. The process owner knows which missing piece of information stalls the next task. None of that knowledge is automatically included in the button.

If a necessary rule stays absent, the resulting work may arrive under an ordinary label: resolve a duplicate, investigate a mismatch, chase a missing value. The recovery ticket can look clean while operations absorbs the unfinished recovery. One team's turnaround time improves; another team's queue lengthens.

A useful acceptance exercise therefore asks for three results. Read the previous value. Save a valid new value. Confirm that an input the agreed rule forbids is rejected. A form that has become less argumentative may simply have lost part of its job description.

The formula is back, but it has not clocked in

The deleted-field management documentation describes a second piece of unfinished work. Restored formula fields are disabled and display #Error! until they are edited and saved. Saving prompts a syntax check; any errors need resolving.

For a team waiting on a calculated result, the presence of the formula definition is an intermediate achievement. The calculation's actual behaviour belongs in acceptance, alongside the recovered contents.

Names also carry a trace of deletion. Salesforce appends _del to the developer name unless a deleted field already has that developer name. Those characters remain after restoration. A familiar display label should not substitute for checking the actual developer name against the configuration that uses it.

Search has a separate delay. A restored field and its data do not appear in search results immediately; Salesforce says it can take a short time. Finding a value, calculating a result and enforcing an input rule are different states. One successful screen cannot certify them all.

The manual repair list also depends on what happened while the field was absent. It must be added back to page layouts changed during deletion. If reports and layouts were not edited, the restored field remains on them. Removed field dependencies need redefining. Returning a relationship to master-detail requires the applicable records to contain the appropriate data.

Recovery is consequently a meeting between an old definition and an environment that may have kept moving. Saving the definition and recording intervening changes is cheaper than asking a departing project team to remember where every attachment used to go.

The dependency list has a limited view

Before deletion, Where is this used? can identify references in layouts, formulas, Apex, active validation rules and reports. It is a useful place to begin finding the work a field supports. Salesforce also documents the places that view does not reach.

Certain report references through foreign-key relationships are absent. Reports inaccessible to the querying user are not returned, and joined reports are unsupported. Existing references inside a managed package are excluded in a subscriber organisation, although new references created locally after installation can appear. The list stops at the first 2,000 entries, sorted by reference type.

An empty result is therefore an answer from that query, within its permissions and coverage. Promoting it into a company-wide declaration of non-use gives the list a very ambitious new job. The least visible uses may be the most expensive to reconstruct once somebody complains that their work has changed.

Salesforce also has deletion restrictions. A field referenced by another field, a field update or Apex cannot be deleted. A background job updating it can also prevent deletion until the job finishes. Those controls stop identified conflicts. The business still needs to understand the uses and rules it intends to abandon or restore.

The new project wants the old field's room

A deleted field and its data remain recoverable until the organisation permanently deletes them or 15 days elapse, whichever happens first. That interval preserves a choice. It does not perform the manual reconstruction of business rules.

Meanwhile, the deleted field continues to count against the custom-field allowance, and its applicable field-type limit, until hard deletion finishes. A project that needs new fields may want to accelerate the cleanup. To that team, the deleted-field list looks like space waiting to be released. To the owner of the previous process, it may contain the last way back.

The Purge procedure moves fields ready for hard deletion into the hard-delete process. Starting that process and completing it are separate events. Completion time depends on system demand and can be monitored through Background Jobs. Giving up recovery does not make capacity instantly available.

If access or clean-data-column errors persist after permanent deletion, the documented support procedure asks for the organisation ID, production-or-sandbox identification and authorisation for physical deletion. It explicitly says that this custom-field physical deletion cannot be limited to a particular object: its scope is the entire organisation. A problem reported in one object can therefore lead to a request for a broader cleanup decision.

Determining which protections are missing in a particular organisation requires its saved definitions, dependency inventory and business acceptance results. The destination can be specified now: old values are readable, necessary calculations work, valid new inputs pass and forbidden inputs fail. That is a recovery with a useful first working day, rather than a merely photogenic conclusion.