Кратко

  • При удалении пользовательского поля Salesforce снимает атрибуты обязательности и уникальности. После восстановления их нужно включить заново, если они необходимы.
  • Восстановленные поля с формулами отключены до редактирования и сохранения. Изменённые макеты страниц и удалённые зависимости тоже могут потребовать ручного восстановления.
  • Поле и данные можно вернуть до окончательного удаления либо до истечения 15 дней — что наступит раньше. Очистка ради свободного лимита способна закончить этот срок досрочно.

Возвращённый столбец удобно предъявлять начальству. Значения видны, время восстановления зафиксировано, заявка закрывается. Гораздо менее нарядная проверка состоит в том, чтобы попытаться ввести то, что раньше было запрещено, и получить ожидаемый отказ.

Для пользовательских полей Salesforce эта проверка имеет прямое основание в документации. В руководстве по ручному восстановлению атрибутов сказано: удаление поля автоматически снимает признаки уникальности и обязательного заполнения. После возврата поля нужные признаки следует настроить снова.

Содержимое вернулось, часть его служебных обязанностей — ещё нет. Именно на этом участке затраты способны незаметно перейти от команды восстановления к людям, которым предстоит работать с новыми записями.

Поле хранило значения и отказывало ошибкам

Возьмём условное поле с идентификатором заказа. Это пример применения опубликованных правил, а не рассказ о происшествии у клиента. Если компания использовала атрибут уникальности, чтобы не допускать повторяющиеся идентификаторы, восстановление прежних значений оставляет отдельную задачу: вернуть этот атрибут. Другие проверки могут существовать, но нужно установить, какую работу выполняла именно снятая настройка.

Для обязательного заполнения логика та же. Старые записи с непустыми значениями не доказывают, что новая пустая запись будет отклонена. Данные прошлого и поведение следующего ввода — два разных предмета приёмки.

Поэтому администратору нужен собеседник со стороны бизнеса. Он может вернуть поле. Специалист, сверяющий заказы, знает цену одинаковым идентификаторам. Владелец процесса знает, отсутствие какой информации остановит следующий шаг. Без этой встречи восстановление рискует закончиться на том, что проще сфотографировать.

Если нужное ограничение осталось выключенным, дальнейшая работа может называться очисткой данных, разбором расхождений или повторной проверкой записей. Первоначальная заявка будет выглядеть успешно закрытой. Операционный отдел будет оплачивать продолжение этой истории своим временем.

Нормальная приёмка проверяет три результата: прежнее значение читается, новое допустимое значение проходит, запрещённое значение отклоняется. Иногда правильное сообщение об ошибке лучше свидетельствует об успехе, чем радостный отчёт о числе возвращённых полей.

Формула на месте, но за работу ещё не взялась

Описание управления удалёнными полями добавляет ещё одну ступень. Поля с формулами восстанавливаются отключёнными. Вместо результата показывается #Error!, пока формулу не отредактируют и не сохранят. Сохранение запускает проверку синтаксиса; обнаруженные ошибки требуется исправить.

Для подразделения, которое ждёт расчёта, наличие определения формулы и получение актуального результата имеют разную ценность. Поэтому статус вычисления должен входить в приёмку, а не теряться за общим словом «восстановлено».

Имя разработчика тоже может сохранить след удаления. К нему добавляется _del, кроме случая, когда удалённое поле с таким именем уже есть. Добавленные символы остаются и после восстановления. Знакомая подпись на экране не заменяет сверку фактического имени с настройками, которые на него опираются.

Поиск живёт по собственному расписанию. Возвращённые поля и данные могут появиться в результатах не сразу: документация предупреждает о небольшой задержке. Найти поле, получить расчёт и проверить отказ в неверном вводе — отдельные действия, каждое доказывает своё.

В ручном списке есть и последствия изменений за время отсутствия. Поле нужно вновь добавить в макеты страниц, которые успели изменить. Если отчёты и макеты не редактировали, восстановленное поле остаётся в них. Удалённые зависимости необходимо определить заново. Для возвращения связи к типу master-detail нужны соответствующие данные в затронутых записях.

Таким образом, поле возвращается в окружение, которое могло продолжить меняться. Сохранённое определение и журнал изменений экономят время на выяснении того, куда раньше крепилась каждая деталь.

Список использований не видит всю компанию

До удаления полезна функция «Where is this used?». Она показывает ссылки из формул, макетов, Apex, действующих правил проверки и отчётов. Salesforce отдельно описывает границы этой видимости.

Некоторые отчёты, использующие поле через связь по внешнему ключу, в список не попадают. Недоступные запрашивающему пользователю отчёты не возвращаются; объединённые отчёты не поддерживаются. В организации-подписчике не показываются существующие ссылки внутри управляемого пакета, хотя новые локальные ссылки после установки могут появиться. Результат ограничен первыми 2 000 записями с сортировкой по типу ссылки.

Пустой список говорит о результате конкретного запроса с конкретными правами и ограничениями. Превращать его в разрешение считать поле никому не нужным — слишком щедрая интерпретация. Невидимые сегодня использования завтра могут потребовать долгого поиска людей, которые помнят, зачем всё было настроено.

При этом действуют собственные ограничения удаления. Нельзя удалить поле, на которое ссылается другое поле, обновление поля или Apex. Текущая фоновая операция обновления также может заблокировать удаление до своего завершения. Эти ограничения останавливают выявленные конфликты. Понимание делового назначения остаётся обязанностью организации.

Свободный лимит покупают за возможность вернуться

Удалённое поле и его данные хранятся до окончательного удаления организацией или до истечения 15 дней, в зависимости от того, что случится раньше. В этот период их можно вернуть. Временное окно сохраняет выбор, но не выполняет ручную настройку правил.

Одновременно удалённое поле учитывается в лимите пользовательских полей и в применимом лимите своего типа, пока окончательная очистка не завершится. Новому проекту может срочно понадобиться место. Для него список удалённых полей выглядит как неразобранный хлам. Для владельца старого процесса это ещё может быть запасным выходом.

Функция Purge отправляет готовые к очистке поля в процесс окончательного удаления. Начало обработки и её окончание различаются. Срок зависит от нагрузки системы; ход работы можно посмотреть в фоновых заданиях. Отказ от восстановления не гарантирует мгновенного появления свободного лимита.

Если после окончательного удаления остаются ошибки доступа или отсутствия свободных столбцов, официальный порядок обращения в поддержку требует ID организации, указания рабочей или тестовой среды и разрешения на физическое удаление. Документ уточняет: эту физическую очистку пользовательских полей нельзя ограничить одним объектом, её область — вся организация. Проблема в одном месте может потребовать согласования более широкого действия.

Чтобы определить, какие защиты отсутствуют в конкретной организации, нужны сохранённые определения, карта зависимостей и результаты деловой приёмки. Критерий можно установить заранее: данные доступны, нужные вычисления выполняются, недопустимый ввод снова отклоняется. Только тогда возвращается работа, ради которой поле когда-то создали.