Пользовательские объекты
Также доступно на 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)

Модуль 3 из 10 главы Архитектура данных Salesforce, глава 3 курса Data Architect. Каждый модуль самостоятелен. Назад: Смотрите на корабль-носитель: стандартные модели данных · Далее: Где живут эти данные?
Вопрос, на который отвечает этот модуль: если в Salesforce этого нет, что вы на самом деле получаете, когда строите свой объект?
В прошлом модуле мы посмотрели, что Salesforce уже построил. Иногда в нем нет того, что вам нужно. Steve Trucking работает с грузовиками, а стандартного объекта «Грузовик» (Truck) нет. Значит, вы строите его сами: пользовательский объект.
Вот что я хочу, чтобы вы увидели в этом модуле. Пользовательский объект создается в метаданных, как и все остальное в модуле 1, и с того момента, как он появился, он получает набор стандартной функциональности. Это не пустая таблица. А экран, который вы заполняете, чтобы его создать, задает вам архитектурные вопросы, замечаете вы это или нет.
Экран New Custom Object
Заголовок раздела «Экран New Custom Object »Откройте Setup → Object Manager → Create → Custom Object, и вы получите одну длинную форму. Большинство людей заполняют первые два поля и нажимают Save. Давайте не будем спешить и прочитаем ее.
Label и Plural Label (метка и метка во множественном числе). «Грузовик» и «Грузовики». Это то, что видят пользователи — во вкладках, макетах страниц и отчетах. Их можно поменять позже без особой боли.
Object Name (имя объекта). С ним по-другому: это API-имя, имя, которое используют код, интеграции, отчеты и теперь агенты. Введите «Truck», и Salesforce сделает из него Truck__c. Поменять его позже — значит найти все, что на него ссылается, а это снова тест на обратимость из главы 1. Сделайте это правильно с первого раза.
Description (описание). Заполняйте его. Каждый раз. В модуле 1 я говорил, что метаданные больше не украшение: это читает следующий администратор, и это читает каждый ИИ-инструмент, который пытается понять ваш org. Пользовательский объект с пустым описанием — это коробка без надписи.
Record Name (имя записи). У каждого пользовательского объекта есть поле Name, и здесь вы решаете, каким оно будет. Text (текст), например «Грузовик 117», или Auto Number, например T-000184, которое Salesforce заполняет за вас. Прочитайте предупреждение на этом экране: если вы планируете вставлять большой объем записей через API, Salesforce советует использовать Text. Это платформа говорит вам что-то о масштабе еще до того, как вы создали хотя бы одну запись.

Salesforce Setup, New Custom Object: раздел Record Name с предупреждением (скриншот, 2026-10-12). Полный размер
Optional Features (дополнительные возможности). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. По умолчанию выключены. Каждая из них — возможность, которую вы включаете для этого объекта; решайте осознанно.
Object Classification (классификация объекта). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access — все включены по умолчанию. Экран говорит прямо: когда они включены, объект — это объект Enterprise Application; когда выключены — объект Light Application. Эти названия совпадают с лицензиями на подписку приложений Salesforce: у Lightning Platform Light App нет общего доступа на уровне записей, и он не может использовать Bulk API или Streaming API, а Enterprise App может. Мой совет: оставьте их включенными, если вы точно не знаете, почему нет. Выключите доступ к Bulk API для объекта, который потом будете загружать в больших объемах, — и узнаете, почему это было важно.
Deployment Status и Search (статус развертывания и поиск). «In Development» скрывает объект от пользователей, пока вы его строите; «Deployed» делает его рабочим. А Allow Search по умолчанию выключен, поэтому пользователи не найдут эти записи в глобальном поиске, пока вы его не включите. На этом люди попадаются каждый раз.

Значения по умолчанию: три настройки API включены, Deployed, Allow Search выключен (скриншот, 2026-10-12). Полный размер
Нажмите Save, и Object Manager покажет вам объект: API-имя Truck__c, галочка в Custom, метки, статус развертывания. Но посмотрите на список слева: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access. Этот список — модуль 1, ставший видимым. Объект — это не просто хранилище; это место, на котором висит все это поведение.

Object Manager, Truck: API-имя Truck__c, Custom и все, что висит на объекте (скриншот, 2026-10-12). Полный размер
Поля, которые вы не создавали
Заголовок раздела «Поля, которые вы не создавали »Откройте Fields & Relationships у совершенно нового пользовательского объекта — а поля у него уже есть. Каждый пользовательский объект получает стандартный набор:
- Name — имя записи, которое вы только что выбрали; используется в макетах страниц, связанных списках, полях lookup и результатах поиска.
- Owner — пользователь или очередь, которым принадлежит запись.
- Created By и Last Modified By — пользователи, которые создали запись и последними ее изменили.
- Currency — если включена мультивалютность, и Division — если ваш org использует подразделения.
А под ними — ID записи из модуля 1 и даты создания и изменения. Выгрузите несколько записей через Data Loader, и вы увидите их все.
Одно из них может исчезнуть. Сделайте свой пользовательский объект подчиненной стороной связи master-detail — и поле Owner пропадет: владение будет браться из главной записи. Это важнее, чем кажется, и мы вернемся к этому в модулях 7 и 8.
Префиксы и суффиксы: на что вы смотрите
Заголовок раздела «Префиксы и суффиксы: на что вы смотрите »В прошлом модуле я сказал, что у стандартных объектов нет ни префикса, ни суффикса. У всего остального есть, и когда вы научитесь их читать, список полей скажет вам точно, на что вы смотрите.
| Как это выглядит | Что это такое |
|---|---|
Account, Case | Стандартный объект или поле: ни префикса, ни суффикса |
Truck__c | Пользовательский объект или пользовательское поле, например Unit_Number__c |
abc__Inspection__c | Пользовательский объект из управляемого пакета (managed package): abc — пространство имен поставщика |
Delivery_History__b | Big object (модуль 4) |
Shipment__x | Внешний объект: данные живут в другой системе (модуль 4) |
Allergies__pc | Пользовательское поле контакта на персональной учетной записи (модуль 2) |
Truck__r | Связь, стоящая за пользовательским полем lookup, когда вы проходите по ней в запросе |
Несколько вещей, на которые стоит обратить внимание.
Пока это просто список. А вот как я это преподаю: слоями. Есть три вида объектов — стандартные, пользовательские и из управляемых пакетов, — и на каждом из них могут быть одни и те же виды полей: стандартные поля, с которыми он пришел, и пользовательские поля, которые кто-то добавил.
Стандартные объекты. У Account нет ни префикса, ни суффикса, как и у его стандартных полей: Name, Industry, OwnerId. В большинство стандартных объектов можно добавлять пользовательские поля, и каждое добавленное заканчивается на __c: Region__c (Custom Fields (opens in a new tab)). Именно этот суффикс вас и защищает. Salesforce добавляет в Account новые стандартные поля в своих релизах, и поскольку ваши всегда заканчиваются на __c, а их — никогда, будущее стандартное поле никогда не столкнется с полем, которое у вас уже есть.
Пользовательские объекты. Ваш собственный объект заканчивается на __c, Truck__c (Custom Objects (opens in a new tab)), как и пользовательские поля, которые вы на него добавляете: Unit_Number__c. Но поля, с которыми он родился, — те, что из предыдущего раздела, — стандартные: Name, OwnerId, CreatedDate, без суффикса. Так что даже на вашем собственном объекте суффикс говорит, кто сделал каждое поле.
Объекты управляемых пакетов. Когда вы устанавливаете управляемый пакет из AppExchange, его объекты и поля приходят с префиксом пространства имен (namespace prefix) поставщика: abc__Inspection__c и поля вроде abc__Result__c. Этот префикс уникален для поставщика и не меняется (Namespace Prefix (opens in a new tab)). По словам самого Salesforce, префикс добавляется к каждому компоненту, чтобы сделать его уникальным: name__c превращается в prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab)). Поэтому два поставщика могут оба поставлять объект Invoice__c и никогда не столкнуться ни друг с другом, ни с вами. У объектов пакета все равно есть свои стандартные поля, Name и OwnerId, без префикса. Пакет может также добавлять свои поля с префиксом в стандартные объекты, например abc__Score__c на Account. А вы можете добавлять свои пользовательские поля в объекты пакета: Depot__c на abc__Inspection__c получает ваш суффикс __c, но никогда префикс поставщика, потому что его сделали вы, а не они (Known Issue: unmanaged custom field on a managed package object (opens in a new tab)).
Прочитайте любое API-имя — и вы знаете, кто его сделал. Без суффикса: Salesforce. __c без префикса: ваш org. abc__ спереди: поставщик. Это важно каждый раз, когда вы планируете изменение. Свое вы можете менять. То, что принадлежит Salesforce, вы настраиваете и расширяете. То, что принадлежит поставщику, в основном закрыто: кое-что, например макеты страниц и текст справки, вы можете редактировать, но большая часть пакета и каждое API-имя принадлежат поставщику, и его обновления приносят его изменения (Editable Properties After Package Promotion or Installation (opens in a new tab)).
У неуправляемых пакетов префикса нет. Установите неуправляемый пакет, и его объекты окажутся в вашем org так, будто вы построили их сами, без префикса. Если он приносит Truck__c, а у вас такой уже есть, у вас конфликт имен. Проверьте до установки.
Стройте только то, чего нет в Salesforce
Заголовок раздела «Стройте только то, чего нет в Salesforce »Создать пользовательский объект легко; именно поэтому, я думаю, мы создаем их слишком много. Экран New Custom Object с удовольствием сделает вам Customer__c в org, где уже есть Account. Поэтому, прежде чем нажать, задайте вопрос из прошлого модуля: есть ли это уже на корабле-носителе? Если есть — используйте. Если нет — стройте и заполните весь экран как архитектор.
Следующий модуль задает вопрос еще раньше: должны ли эти данные вообще быть в Salesforce?
Что здесь решает архитектор
Заголовок раздела «Что здесь решает архитектор »- Есть ли уже в Salesforce стандартный объект для этого — до того как строить пользовательский.
- API-имя, выбранное один раз, и описание, написанное для людей и машин.
- Имя записи: Text или Auto Number, с учетом ожидаемого объема.
- Какие дополнительные возможности, доступ через API и поиск включать — осознанно.
- Что говорят суффиксы в org: пользовательский, управляемый, big, внешний, персональная учетная запись.
- Может ли пакет, который вы собираетесь установить, столкнуться с тем, что вы построили.
Дополнительно
Заголовок раздела «Дополнительно »- Custom Objects (opens in a new tab) и Custom Fields (opens in a new tab), Object Reference (на английском, проверено 2026-10-13): «имена пользовательских объектов включают суффикс из двух подчеркиваний и строчной буквы „c“»; то же для пользовательских полей; и таблица стандартных объектов, поддерживающих пользовательские поля.
- AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (на английском, проверено 2026-10-13): префикс пространства имен делает каждый компонент пакета уникальным; «name__c превращается в prefix__name__c».
- Namespace Prefix (opens in a new tab), Apex Developer Guide (на английском, проверено 2026-10-13): префиксы пространств имен отделяют имена объектов и полей управляемых пакетов от имен в других org.
- Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (на английском, проверено 2026-10-13): какие свойства компонентов пакета может редактировать разработчик, подписчик, оба или никто.
- Custom Object Standard Fields (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-12): стандартные поля, которые получает каждый пользовательский объект (Name, Owner, Created By, Last Modified By, Currency, Division), и почему Owner убирается на подчиненной стороне связи master-detail.
- Standard User Licenses (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-12): Lightning Platform Light App «не может использовать Bulk API или Streaming API»; Enterprise App «поддерживает общий доступ на уровне записей, может использовать Bulk API и Streaming API».
