Развертывание пакетов Salesforce - будут ли настраиваемые поля, включенные в пакет, перезаписывать поля целевых организаций с таким же именем?

Question

Я относительно новичок в Salesforce, поэтому мне не хватает чего-то простого здесь:

Существует корпоративный сайт. У него есть несколько настраиваемых полей (например, Account.MyCustomField__c), страниц и, конечно же, множество данных о клиентах. Насколько я могу судить, все было настроено из самого экземпляра Salesforce (без специального кода Apex или специальных пакетов)

Я хочу добавить к этому класс Apex - крошечный класс Schedulable с несколькими строками кода для выбора и обновления одного из этих полей MyCustomField_ c в нескольких записях каждый день. Для этого я зарегистрировался, создал сайт разработчика и вручную заново создал MyCustomField _c (то же имя, имя API, метка, тип и т. Д.), А затем создал класс и его методы тестирования.

Теперь вот мое беспокойство:

Когда я собираюсь создать пакет, чтобы я мог скопировать этот класс на сайт Enterprise, настраиваемое поле отображается как зависимость, которая будет автоматически включена в пакет. Что произойдет, если я установлю этот пакет - будет ли дублированное поле добавлено / перезаписано существующее или возникнет ошибка? В конечном счете, я хочу, чтобы мой класс Apex использовал поле уже на сайте Enterprise, конечно.

В качестве альтернативы, есть ли способ экспортировать настраиваемые поля / настройки из корпоративного сайта в сайт разработчика, чтобы в результирующих пакетах с сайта разработчика уже учитывались зависимости, присутствующие в корпоративной версии?

Answer 1

Вы перемещаете код как упакованное приложение (с пространством имен) или через наборы изменений? Обычно мы выполняем развертывания с использованием Eclipse - мы не упаковываем вещи, поэтому не используем пространства имен.

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