FAQ — Can I delete a custom field that’s been populated?

Short answer: yes, but the data goes with it. Atender shows the affected record count first so you can make an informed decision; the deletion itself is irreversible.

What deletion does

When you delete a custom field, Atender:

• Removes the field from every record (contact, conversation, or case) it was attached to
• Drops the values that were stored
• Removes references from any Automation condition or action — those rules continue to exist but the lines that referenced this field become empty (your rule is now subtly broken)
• Removes references from saved searches, analytics views, and Sidekick detection rules

The field’s machine key is freed; you can re-create a new field with the same key later, but old records won’t recover their old values.

When you should NOT delete

If the data has been actively populated and might still be useful for reporting, audit trails, or context, deletion is the wrong move. Better options:

• Stop populating it. Disable any Sidekick detection rule that writes to it. Disable any automation action that updates it. The field stays in place but stops accumulating new data.
• Hide it from agents. Move the field to a section labeled Deprecated or Archive. Agents stop seeing it as a primary field; the historical data stays queryable.
• Migrate to a new field. Create the replacement field, write a script (or use Manual run) to copy values from the old field to the new, then delete the old. Preserves historical data while moving forward with a cleaner schema.

When you should delete

A field genuinely earns deletion when:

• It was created by mistake (typo, test) and has very few records populated
• It’s a duplicate of another field — and the data has already been migrated to the canonical one
• It’s been deprecated for a long time, every consumer (automations, analytics, Sidekick) has been updated to ignore it, and removing it cleans up the schema

In all three cases, the data loss is either zero or accepted.

How to migrate before deleting

The clean path:

1. Create the new (replacement) field.
2. Use Manual run on a temporary automation that copies the old field’s value to the new field for every record matching old_field is not empty.
3. Verify a sample of records — the new field should match the old.
4. Update all rules, saved searches, and analytics views to reference the new field key.
5. Now delete the old field. Its usage count should be near zero by this point (only direct record references remain, which the deletion will handle).

This is the standard rename-a-field pattern. Atender doesn’t support in-place renaming of a field’s key (the machine identifier) — only the display name. If the key needs to change, migrate.

What about analytics history?

Analytics history backed by the deleted field is also lost. If you need historical reports to keep working, migrate the data to the new field before deleting the old, and update the report definitions to point at the new key.

See also

• Create a custom field
• Use a custom field in an automation