Поля — это тоже архитектура

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 6 из 10 главы Архитектура данных Salesforce, глава 3 курса Data Architect. Каждый модуль самостоятелен. Назад: Выберите правильный объект · Далее: У связей есть последствия

Вопрос, на который отвечает этот модуль: как Salesforce должен физически представлять каждый элемент данных?

Создание поля занимает примерно минуту. New Field, выбрать тип, дать имя, Next, Next, Save. Именно поэтому к полям не относятся как к архитектуре.

Зайдите в org, которому десять лет, и откройте Account. Пятьсот полей. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Три разных номера клиента. Чекбокс, который никто не удалит, потому что никто не знает, какая интеграция до сих пор его использует. Создать поле заняло минуту. Жить с ним — годы. Поэтому идея этого модуля проста: поле — это архитектурное решение. Не всегда большое, но каждое поле кодирует что-то о смысле, поведении, идентификации или качестве данных, и, как и объекты, поля легко добавить и на удивление трудно убрать.

Что на самом деле означают эти данные?

В главе 2 мы дали нашим сущностям атрибуты: у доставки есть запланированное окно, у грузовика — VIN. Теперь мы их реализуем, и здесь люди сразу прыгают к «текстовому полю». Подождите. Прежде чем выбирать тип, я хочу знать, что данные означают. Это число или идентификатор, в котором случайно есть цифры? Дата или момент времени? Свободный текст или одно из утвержденных значений? Вводится человеком или принадлежит другой системе? Может ли меняться? Должно ли быть уникальным? Может ли отсутствовать? Нужно ли вообще его хранить или его можно вычислять? Это не вопросы Setup. Это вопросы архитектуры данных, и тип поля идет после того, как мы на них ответим.

Число — не всегда число

Steve Trucking дает каждому грузовику номер в автопарке, скажем 001247. Поле Number? Скорее всего, нет. Мы складываем номера в автопарке? Грузовик 1247 минус грузовик 1246 — это один грузовик? Это идентификатор, в котором случайно есть цифры, и поле Number еще и отбросит ведущие нули. То же касается почтовых индексов, кодов продуктов, номеров счетов и трек-номеров. То, как выглядит значение, не говорит, что оно означает. Выбирайте тип по нужному поведению, а не по тому, как выглядят примеры данных.

Нужно ли человеку это опознавать?

Каждый пользовательский объект получает поле Name, и первое решение — текст или Auto Number. Я спрашиваю: нужно ли человеку опознавать эту штуку? Люди знают розничного партнера по названию, а грузовик — по номеру в автопарке. Но манифест, который система генерирует каждую ночь? Никто не должен вводить «Манифест 10-02 номер 3» только потому, что Salesforce потребовал Name. Дайте ему Auto Number. Только не путайте это сгенерированное Name с тем, что идентифицирует запись: Auto Number помогает пользователям, ID Salesforce идентифицирует запись, а собственный номер манифеста у розничного партнера может идентифицировать ту же вещь во всех системах. Три разные задачи.

Экран деталей

Выберите тип, нажмите Next, и Setup спросит детали. Именно на этом экране на самом деле принимается большинство решений этого модуля — обычно в спешке.

New Custom Field, шаг 2: детали (скриншот, 2026-10-12). Полный размер

Два поля выглядят похоже, но делают разную работу. Description — для людей, которые поддерживают org, а теперь и для ИИ-инструментов, которые его читают: что поле означает, кто им владеет, откуда оно берется. Help Text — для пользователя на экране: что сюда вводить. Заполняйте оба. Потом идут Required, Unique и External ID, и каждое из них заслуживает своего раздела. Под ними Default Value может быть формулой, так что новая запись может начинаться с разумного значения вместо пустоты.

Required — решение крупнее, чем кажется

В мастере создания поля есть маленький чекбокс Required (обязательное), и, как мы видели в главе 1, он может оказаться бомбой замедленного действия. У вас объект пять лет и два миллиона записей, и теперь кто-то решает, что у нового поля всегда должно быть значение. А как же два миллиона записей, созданных раньше? Интеграции, которые его не передают? Автоматизация, которая создает запись раньше, чем значение известно? Процесс, в котором значение появляется только через три шага?

«Обязательное» звучит как решение о качестве данных, и иногда так и есть. Но когда значение становится известным — это часть бизнес-процесса. Поэтому не ставьте Required только потому, что кто-то говорит «мы всегда хотим это видеть». Спросите, когда оно известно, кто его дает и что происходит, когда его нет. Мы поставим это на полную лестницу согласованности в модуле 7.

Unique тоже кое-что значит

Если я помечаю поле как уникальное, я делаю заявление о бизнесе: не «обычно не повторяется», а «у двух записей никогда не может быть этого значения». Это сильно. И экран заставляет вас решить еще одно: «ABC» и «abc» — это одно значение или разные? Без учета регистра — более безопасный вариант по умолчанию для всего, что вводит человек. Здесь действует правило ключей из главы 2: уникальный, неизменный, лишенный смысла, никогда не PII. Если мне говорят, что адрес электронной почты сотрудника уникален, я начинаю спрашивать: может ли он измениться, может ли человек уйти и вернуться, могут ли адреса использоваться повторно, что будет после поглощения? Электронная почта может быть полезной, даже уникальной сегодня. Это не делает ее хорошим идентификатором.

External ID: идентификация через границу систем

Вот где External ID отрабатывают свое. Экран хорошо это описывает: поле становится «уникальным идентификатором записи из внешней системы». В ERP есть клиент 873492; в Salesforce — свой ID записи. Когда ERP присылает обновление, как понять, к какой записи оно относится? Пометьте поле как External ID, и интеграция сможет делать по нему upsert: создать запись, если ее нет, и обновить, если есть (Upsert a Record Using an External ID (opens in a new tab)). А когда вы загружаете дочерние записи, можно указывать на родителя по его External ID, не запрашивая сначала ID Salesforce. Я люблю говорить, что вы позволяете Salesforce сделать поиск за вас. Очень мощно.

Обратите внимание: номер из ERP не становится ID записи Salesforce. Это атрибут, и у записи их может быть несколько: ID клиента в ERP, ID из старой системы, ID партнера. Это нормально. Одну бизнес-сущность разные системы могут знать по-разному. Архитектурный вопрос — какая система владеет каждым идентификатором и что она обещает: помечайте его уникальным, только если бизнес действительно это гарантирует.

Тип за типом

Теперь сами типы. Откройте New Field на любом объекте, и Setup покажет весь список, сгруппированный так, как я буду его проходить: поля, которые Salesforce вычисляет за вас, поля связей, а затем типы данных.

Setup, New Custom Field, шаг 1: типы данных (скриншот, 2026-10-12). Полный размер

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

Группа	Тип	Запомните
Вычисляемые	Auto Number	До 30 символов, из них 20 на префикс или суффикс; метка для людей, а не идентификатор записи
	Formula	Вычисляется при чтении, не хранится; 3 900 символов
	Roll-Up Summary	Количество, сумма, минимум или максимум по подчиненным записям; только master-detail
Связи	Lookup, Master-Detail, External Lookup	Модуль 7
Данные	Checkbox	Истина или ложь, со значением по умолчанию на ваш выбор; во flow все равно может появиться null
	Number, Percent, Currency	Правила округления; ведущие нули отбрасываются; 15 знаков после запятой
	Date, Date/Time, Time	День, момент или время суток; моменты хранятся в UTC
	Email, Phone, URL	Форматируются и проверяются при сохранении: 80, 40 и 255 символов
	Geolocation, Address	Составные поля, которые стоят больше одного поля: 3 и 9
	Picklist, Multi-Select	Контролируемый словарь, которым владеет администратор
	Text, Text Area, Long, Rich, Encrypted	До 255 — в записи и с возможностью индексации; больше — без индекса и фильтрации

Поля, которые вычисляет Salesforce

Auto Number присваивает каждой новой записи следующий номер в последовательности, в заданном вами формате, например T-{000000}. Используйте его, когда человеку нужен удобный ярлык и никто не должен его придумывать. Все значение — до 30 символов, и 20 из них отведены под префикс или суффикс. Только помните из главы 2: это метка для людей, а не идентификатор записи, и номера не всегда идут строго подряд.

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

New Custom Field, формула: выбор типа возвращаемого значения (скриншот, 2026-10-12). Полный размер

Затем вы пишете саму формулу, с полями, операторами и функциями, и проверяете синтаксис. Обратите внимание на кнопку Use Formula Assistant: теперь ИИ Salesforce поможет вам написать формулу. Пользуйтесь им, а потом прочитайте, что он написал. Формулой владеете вы, а не ассистент.

Редактор формул с Formula Assistant (скриншот, 2026-10-12). Полный размер Формула может быть длиной до 3 900 символов и не может превышать 15 000 байт при сохранении или компиляции; длинную формулу можно разбить на несколько полей-формул, которые ссылаются друг на друга. Длинные текстовые области, зашифрованные поля и поля Description в них использовать нельзя.

Поля Roll-Up Summary находятся на главной записи и считают количество, сумму, минимум или максимум по ее подчиненным записям. Они работают только через связь master-detail, и это одна из главных причин вообще выбирать master-detail. Мы вернемся к ним и к их ограничениям в модуле 7.

Хранить или вычислять?

Нужно ли вообще хранить это значение? Если у меня есть количество и цена за единицу, нужно ли кому-то — или какой-то автоматизации — поддерживать итог? Может, его должна вычислять формула: один источник расчета, пересчитываемый при чтении, — меняете количество, и ответ следует за ним. У формул свои ограничения (размер при сохранении и отображаемая длина; Formula Field Limits and Restrictions (opens in a new tab)), и сложные формулы трудно поддерживать.

Но иногда бизнесу нужен не сегодняшний ответ. Ему нужен ответ таким, каким он был. Если правило скидок изменится в следующем году, должен ли прошлогодний счет вдруг показывать другую сумму? Конечно нет. Поэтому вопрос не в том, «может ли Salesforce это вычислить?». А в том, «это текущий расчет или исторический факт?» Исторические факты хранят.

Поля связей

Связи Lookup, Master-Detail и External Lookup — тоже поля, и именно в них линии вашей модели становятся реальными. Lookup — свободная связь; master-detail привязывает жизнь, владение и безопасность дочерней записи к родительской; external lookup дотягивается до внешнего объекта из модуля 4, сопоставляя по его External ID. Выбор между ними — достаточно крупное решение, чтобы получить собственный модуль.

Checkbox

Checkbox (чекбокс) — самое простое поле, какое есть: истина или ложь, отмечено или не отмечено. Идеально для факта «да/нет» о записи: Is Active, Install Required, Signed For. Когда вы его создаете, Salesforce заставляет выбрать значение по умолчанию, отмечено или нет, и это настоящее решение: с него начинается каждая новая запись, включая записи, которые интеграция создает, не передавая это поле. Отчеты и представления списков фильтруют его как True и False; инструменты импорта и еженедельный экспорт показывают его как 1 и 0.

Одна ловушка, о которой надо знать. У поля на записи два значения, а у автоматизации вокруг него может быть третье. Во flow переменная-чекбокс, которой так и не присвоили значение, — это null, а не false, и сохранить ее в запись не получится (Trailblazer Community (opens in a new tab); см. также известную проблему Salesforce W-11208535 (opens in a new tab)). Выберите разумное значение по умолчанию и сделайте так, чтобы ваши flow и код обрабатывали null осознанно.

Number, Percent и Currency

Number хранит настоящее число и отбрасывает ведущие нули — именно поэтому номер в автопарке вроде 001247 не Number. Salesforce округляет числовые поля половину от нуля: 12,345 превращается в 12,35, а −12,345 — в −12,35. А в полях слияния (merge fields) он округляет по локали пользователя, а не по числу знаков после запятой, заданному для поля.

Percent хранит десятичную дробь и показывает процент: введите 0,10 — и увидите 10 %. После 15 знаков после запятой значения теряют точность.

Currency форматируется для денег, а в org с несколькими валютами несет код валюты и может использовать курсы обмена; с расширенным управлением валютами (opens in a new tab) возможности могут использовать датированные курсы — курс за период, в котором закрылась сделка. Датированные курсы используют только возможности и все вокруг них (продукты, графики, разделения и их отчеты); поля валюты на других объектах сохраняют единый статический курс. Следите за округлением: без знаков после запятой Salesforce просто отбрасывает дробную часть (23,5 становится 23); с одним или более знаками он округляет половину от нуля.

Date, Date/Time и Time

Три типа, три разных смысла. Date — это день: договор истекает в определенную дату. Date/Time — это момент: доставка прибыла в 9:42 утра. Time — время суток вообще без даты: магазин открывается в 7:00, каждый день.

Ловушка — в моменте. Salesforce хранит значения даты/времени в GMT (UTC). Время, которое вводит пользователь, читается в его часовом поясе, преобразуется и сохраняется; когда кто-то его читает, оно снова преобразуется — в часовой пояс читающего. Чаще всего это ровно то, что нужно. Но вот пример, который я привожу на занятиях: координатор в Лос-Анджелесе поздно вечером в воскресенье, в 22:00 по тихоокеанскому времени, регистрирует доставку. Под капотом Salesforce сохранил утро понедельника, 5:00 по GMT. Отчет, сгруппированный по дням в другом часовом поясе, или интеграция, читающая сырое значение, могут отнести эту воскресную доставку к понедельнику. «День, когда это случилось» зависит от того, чьи часы вы спрашиваете. Следите за часовыми поясами пользователей и решите, какой из них имеет в виду бизнес.

И будьте осторожны, сравнивая их. Под капотом дата/время — это одно большое число: Apex читает его как количество миллисекунд с 1 января 1970 г., 00:00:00 GMT (Datetime Class (opens in a new tab)). Это точный момент, а не день. Поэтому проверка, равны ли две даты/времени (==), почти никогда не делает того, что вам нужно: 9:42:00 и 9:42:01 не равны, как не равны «понедельник» и любой момент понедельника. Вместо этого спрашивайте о диапазоне: не раньше начала (>=) и не позже конца (<=). «Все доставки в понедельник» — это все доставки >= понедельник 00:00 и <= понедельник 23:59:59, в том часовом поясе, который, как вы решили, имеет в виду бизнес.

И забавный момент: Salesforce не может хранить любую дату. Допустимые даты — с 1 января 1700 г. по 31 декабря 4000 г., и Salesforce дает тот же диапазон для дат и дат/времени (Data Import Dates (opens in a new tab)). Даже границы — это моменты в GMT, поэтому для пользователя в тихоокеанском времени самое раннее допустимое значение — 16:00 31 декабря 1699 г. Дата основания вашего исторического общества может не поместиться. А классический прием «без даты окончания», 31 декабря 9999 г., будет отклонен; если нужен заполнитель в далеком будущем, он должен быть в 4000 году или раньше.

Email, Phone и URL

Это форматируемые поля, и они делают больше, чем хранят символы. Email вмещает до 80 символов и проверяется на правильный формат; у контактов и интересов щелчок по нему начинает письмо на этот адрес. Phone вмещает до 40 символов, форматируется как номер телефона и становится click-to-dial (звонок в один клик), когда к org подключена телефонная система. URL вмещает до 255 символов и открывается как ссылка. Это платформа дает вам поведение бесплатно, и поэтому я бы никогда не стал хранить номер телефона в обычном текстовом поле.

Интеграции тоже проверяются. Значение, которое не соответствует формату поля, например неправильно составленный адрес электронной почты, не проходит проверку, и отклоняется вся запись, а не только это поле. Поэтому, когда данные в системе-источнике грязные, очистите их до того, как они придут, или заранее спланируйте, что делать с записями, которые не загрузятся.

Geolocation и Address

Geolocation хранит широту и долготу. Под капотом поле Location__c — это на самом деле два значения, которые можно читать и задавать по отдельности: Location__Latitude__s и Location__Longitude__s. И по нему можно делать запросы: функции SOQL DISTANCE и GEOLOCATION находят записи в заданном радиусе или сортируют их по удаленности. «Все открытые доставки в пределах 25 миль от этого грузовика» — это один запрос: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab)). Address хранит весь адрес — улицу, город, штат или область, почтовый индекс и страну, — и пользователи могут найти адрес поиском, чтобы части заполнились сами.

Оба — составные поля (compound fields): одно поле на экране, несколько под капотом. И они стоят больше одного поля в лимите вашего объекта: Geolocation считается как три пользовательских поля, а Address — как девять. На объекте, где и так тесно, это важно.

Picklist и Multi-Select

Список выбора (picklist) контролирует, что пользователи могут ввести: одно значение из заданного вами списка. Статус? Скорее всего, список выбора. Но значения — это метаданные, и добавлять или менять их должен администратор. Поэтому я все равно спрашиваю, кто владеет значениями, как часто они меняются, нужен ли один и тот же список нескольким объектам, несут ли значения собственную информацию и не владеет ли словарем другая система.

Где живут значения — тоже решение. Когда список используется один раз, в одном поле, держите значения в самом поле, на объекте; так Salesforce делает по умолчанию. Но когда один и тот же набор значений начинает появляться в нескольких местах — регион на организации, на доставке и на складе, — превратите его в глобальный набор значений, пока копии не разошлись. Глобальный набор значений хранит один список для всех, до 1 000 значений, активных и неактивных вместе (Picklist Limitations (opens in a new tab)). Описание в самом Setup объясняет, почему это важно: набор значений «ограничен, чтобы пользователи не могли добавлять неутвержденные значения через API». Один список, один владелец, и никакая интеграция не протащит новое написание.

Этот последний пункт — разница между ограниченным (restricted) и неограниченным (unrestricted) списком. В ограниченном списке выбора разрешены только значения, которые задал администратор, откуда бы данные ни пришли: пользователь, импорт или интеграция, которые присылают что-то другое, получают ошибку «bad value for restricted picklist field», и запись не сохраняется. В неограниченном списке выбора пользователи на экране все так же выбирают из списка, но API, импорт и автоматизация могут прислать любое значение, и Salesforce его сохранит и добавит как неактивное (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab)). Так в org и появляются «Delivered», «delivered» и «Dlvrd». Глобальные наборы значений всегда ограничены. Мой выбор по умолчанию — ограниченный; неограниченный — это осознанный выбор для случаев, когда значениями действительно владеет другая система, и тогда кто-то отвечает за чистку неактивных значений.

Setup, Picklist Value Sets: новый глобальный набор значений (скриншот, 2026-10-12). Полный размер

Список с множественным выбором (multi-select picklist) позволяет пользователю выбрать несколько значений, которые хранятся вместе через точку с запятой. Удобно на экране, неудобно везде еще: по нему труднее фильтровать, строить отчеты и интегрироваться, и его нельзя использовать в фильтре поля roll-up summary. Несколько значений для одной записи обычно означают урок из главы 2: там пытается вырваться наружу дочерний объект.

У списка выбора есть еще одно значение помимо заданных вами: пусто. Запись может стоять без выбранного значения, и на этом люди попадаются. В формуле или правиле проверки нельзя проверить список выбора одним ISBLANK; пишут ISBLANK(TEXT(Field__c)) или ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab)). Поэтому решите, что означает «нет значения» для каждого списка выбора: разрешено ли это и что это значит, когда так происходит? А потом сделайте так, чтобы ваши формулы, правила проверки и фильтры это обрабатывали.

А иногда атрибут на самом деле сущность. Кто-то просит список выбора распределительных центров. Их девять. Легко. Потом мы узнаем, что у каждого есть адрес, руководитель, часы работы, вместимость, регион и грузовики. Это не список выбора; это сущность. Не превращайте сущность в список выбора только потому, что их пока немного. В первый год это кажется отличной идеей, а на пятый — ужасной. (В модуле 5 главы 2 есть мои эмпирические правила о том, когда список заслуживает собственного объекта.)

Семейство текстовых полей

Я преподаю текст как два вида, и граница между ними — 255 символов.

До 255: хранится вместе с записью. Text вмещает до 255 символов, и его можно использовать почти везде: в формулах, фильтрах, отчетах, представлениях списков, как уникальное поле или External ID, и его можно индексировать. Text Area тоже вмещает 255, на отдельных строках, как короткая заметка.

Больше 255: хранится по ссылке. Text Area (Long) вмещает до 131 072 символов, а Text Area (Rich) — столько же с форматированием, ссылками и изображениями. Я представляю их хранящимися в стороне, а запись держит указатель, и ведут они себя соответственно: нет индекса, поэтому их нельзя сделать уникальными или External ID; по ним нельзя фильтровать в предложении SOQL WHERE (SOQL WHERE (opens in a new tab)); формулы не могут их использовать (Formula Field Limits and Restrictions (opens in a new tab)); а отчеты показывают только первые 254 символа пользовательского поля, и фильтры отчетов ищут только примерно в первых 255 (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Изображения, загруженные в поле форматированного текста, могут быть размером до 1 МБ каждое и расходуют файловое хранилище, а текст — хранилище данных (Rich Text Area Field Considerations (opens in a new tab)). Поэтому если кому-то нужно искать, сортировать, сопоставлять значение или строить по нему отчеты, держите его до 255 символов и оставляйте полем Text.

Text (Encrypted) хранит до 175 символов в зашифрованном виде, с помощью Classic Encryption. Если ваш org использует Shield Platform Encryption, вместо этого шифруют обычное поле Text, и так же можно шифровать многие другие типы.

Дайте каждому полю описание

Мой стандарт: у каждого поля есть описание. Я верю в это давно, а в эпоху ИИ это важнее, чем когда-либо: каждый ИИ-инструмент и агент, который читает ваш org, читает описания, чтобы понять, что означает поле. Пустое описание — это догадка, которая ждет своего часа. Что означает Customer_Status__c? Кто им владеет? Откуда оно берется? Могут ли пользователи его редактировать, или ERP перезапишет его сегодня ночью? Через полгода я не вспомню, а через три года администратор, поддерживающий org, не узнает, если мы ему не сказали. Метка — не документация, и API-имя тоже.

На объектах, которыми пользуются очень широко (Account, Contact, Opportunity), я также использую префиксы в именах для специальных полей, чтобы их происхождение и назначение были видны в самом имени: например, все, чем владеет ERP, начинается с одного и того же префикса. Мне не нужны API-имена из двенадцати слов. Я хочу, чтобы модель объясняла себя сама.

Классифицируйте то, что важно: поля таксономии

Salesforce дает каждому полю набор метаданных классификации. Я называю их полями таксономии. Можно указать владельца данных (data owner); использование поля (field usage: Active, DeprecateCandidate, Hidden); уровень чувствительности данных (data sensitivity level: Public, Internal, Confidential, Restricted, MissionCritical); и категорию соответствия требованиям (compliance categorization): PII, HIPAA, GDPR, PCI, CCPA и другие. Они работают и на стандартных полях, и на пользовательских (Data Classification Metadata Fields (opens in a new tab)).

Зачем это нужно? Потому что процессы могут их читать. Пометьте поле как GDPR, и процесс сможет найти на записи все поля GDPR и замаскировать или удалить их. А когда слой доверия Salesforce отправляет промпт большой языковой модели, он может использовать именно эту классификацию, чтобы маскировать чувствительные поля: на выходе он заменяет имя клиента, скажем «Maria Lopez», на заполнитель, модель имени не видит, а на входе имя подставляется обратно в ответ (Einstein Trust Layer (opens in a new tab)).

Обновление. Теперь Salesforce документирует, что маскирование по шаблонам и по полям для LLM отключено для агентов: маскирование может лишить агента контекста, нужного для ответа (Data Masking Limitations in Agentforce (opens in a new tab)). Классификация по-прежнему управляет маскированием для других функций генеративного ИИ, но не рассчитывайте, что она уберет персональные данные от агента; это решение о доступе и дизайне (глава 12).

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

За пределами экзамена: что меняет ИИ. Плохая документация полей раньше наказывала следующего администратора. Теперь она вводит в заблуждение каждый ИИ-инструмент и агента, читающих схему: Flag2__c чувствительное, авторитетное, еще используется? К тому же ИИ создает поля быстрее любой команды, поэтому имена, описания и классификация — это часть архитектуры, а не уборка.

Каждое поле — это обязательство

Как только поле начинает собирать данные, все начинает на него опираться. Экраны его показывают, flow по нему ветвятся, правила проверки его проверяют, отчеты по нему группируют, интеграции его отправляют и читают, а теперь и ИИ-инструменты о нем рассуждают. Каждый из них делает предположения о поле: его тип, длина, бывает ли оно пустым и что означают его значения. Поменяйте поле позже, и вам сначала придется найти каждое из этих предположений. Переименовать значение списка выбора, укоротить текстовое поле или превратить поле Text в список выбора звучит как мелкое изменение, а может сломать интеграцию в системе другой компании. Вот почему поле — это обязательство.

Click to enlarge

Я не хочу, чтобы вы уходили из этого модуля, боясь создавать поля. Salesforce создан, чтобы его расширяли; пользуйтесь этим. Я хочу, чтобы вопрос сменился с «какой тип поля выбрать?» на «что означают эти данные и на какое поведение мы подписываемся?» Тип, обязательность, уникальность, External ID, список выбора, формула, описание, классификация: вместе это физическое выражение логической модели из главы 2.

Что здесь решает архитектор

• Что означает значение — до выбора типа поля, и является ли оно атрибутом, идентификатором, контролируемым словарем или на самом деле другой сущностью.
• Является ли значение текущим расчетом, который можно вычислить, или историческим фактом, который нужно хранить.
• Какая система владеет каждым идентификатором и является ли его уникальность настоящим обещанием бизнеса.
• Когда на самом деле становится известно обязательное значение и что происходит с записями и интеграциями, у которых его нет.
• Какое описание, имя и классификация нужны полю, чтобы люди, процессы и ИИ могли безопасно им пользоваться.

Дополнительно

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab), на английском, проверено 2026-10-02.
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) и Data Masking Limitations in Agentforce (opens in a new tab), на английском, проверено 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab), на английском, проверено 2026-10-02.
• Salesforce Help, Picklist Limitations (opens in a new tab), на английском, проверено 2026-10-02.
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab), на английском, проверено 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab), на английском, проверено 2026-10-02.