Salta ai contenuti

Custom Objects: From Core to Data 360

Questi contenuti non sono ancora disponibili nella tua lingua.

Module 3 in the chapter Bringing In CRM Data, chapter 5 of the Data 360 Architect course. Each module stands on its own. Previous: Data Bundles: the Fast Start · Next: How Fresh Is CRM Data?

The question this module answers: How does a custom object you build in core get into Data 360?

A standard bundle covers the objects everyone has (module 2). But most orgs have their own objects too, built for their own business, and those are often the data that matters most. No bundle knows about them. So let’s walk the whole flow, from creating a custom object in core to seeing its records in Data 360.

In our aviation org, each pilot is a contact. A pilot holds certifications: a license type, a rating for an aircraft type, the date it was issued and the date it expires. One pilot, many certifications. So in core we build a custom object, Pilot Certification, with a lookup to the pilot’s contact.

Try it with the course’s data. SkyData has the certifications for chapter 5’s core contacts: pilot-certifications-synthetic.csv on SkyData (opens in a new tab), 627 synthetic rows for the 150 contacts, one to five each. Each row has its own ID (CRT-000001), the contact it belongs to (CON-00001), the type and the certification, an aircraft type rating where it applies (a Boeing 737, an Embraer 170/175; never an employer), an issue date, and an expiry date on the medicals. Fourteen of the 149 medicals have already expired, on purpose: something for a segment or an insight to find later. To load them with the Data Import Wizard, SkyData’s Salesforce import files (opens in a new tab) have the same rows ready as pilot-certifications-for-import.csv, with the pilot’s Sky Data Contact ID, and a short file, core-org-contact-ids.csv, that puts that ID on each contact first. The card gives every step.

A new text field on Contact, Sky Data Contact ID, Text(20), with External ID ticked and a description

An external ID on the contact, for the load (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The Data Import Wizard for Accounts and Contacts, Update existing records: Match Contact by Name, Match Account by Name & Site, the file core-org-contact-ids.csv

Filling the new ID: update the contacts, matched by name (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The mapping for the ID update: four columns, Sky Data Contact ID mapped to the new custom field by its label

The new field found by its label (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The wizard for Pilot Certifications: Match by, the record owner question, and the Pilot lookup matched on Sky Data Contact ID (External ID); Character Code Unicode (UTF-8)

The wizard matches the pilot by the external ID (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

Edit Field Mapping for Pilot Certifications: Pilot mapped from Sky Data Contact ID, Pilot Name left unmapped

The lookup mapped, the step people miss (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The contact Ahmed Park with the related list Pilot Certifications (4): CRT-000001 to CRT-000004

The check: four certifications on the first pilot (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

A bulk data load job: Upsert on Pilot Certification with External ID Field Name, 627 records processed, 0 failed, 13 seconds

Matched by name, the load is an upsert: a reload updates instead of duplicating (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

That’s ordinary core work. What follows is what Data 360 needs on top of it.

Build the object, its fields and its relationships, and deploy it. Salesforce lists an object whose deployment status is “In Development instead of Deployed” as one of the reasons a CRM stream can’t use the faster streaming mode (module 4). So finish the object in core first, then bring it in.

New Custom Object in Setup: label Pilot Certification, plural Pilot Certifications, object name Pilot_Certification, a description of what one record is, and the record name Certification ID as text

Building the custom object in core, with a description (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

Object Manager, Pilot Certification details: API name Pilot_Certification__c and Deployment Status Deployed

Deployed, not In Development (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

Pilot Certification, Fields & Relationships: 11 fields, including Certification ID as the Name field, Certification Type as a picklist, Issue and Expiry Date, and Pilot, a lookup to Contact

The object’s fields, with the lookup to Contact (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

And think about the key now, not later (chapter 3). The record ID of each certification is unique, unchanging and meaningless, and it’s what Data 360 will use.

Data 360 doesn’t read your org as you. When you connect an org, Salesforce creates a permission set called Data Cloud Salesforce Connector, used by a system user, the Platform Integration User. Salesforce is clear: “Permissions granted through permission sets to this user determine the data you retrieve from Data 360.” If that user can’t see the object or a field, the data doesn’t come in.

The permission set Data Cloud Salesforce Connector: Allows object and field access for ingestion to Data Cloud, API name sfdc_a360_sfcrm_data_extract, license Cloud Integration User, created by Automated Process

The connector’s permission set, created for you (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

From Salesforce’s permissions page:

  • View All Records and View All Fields must be granted on the objects and fields you ingest.
  • Grant permissions on related objects too, “even if you don’t ingest the related objects.” A certification looks up to a contact, so the connector needs access to Contact as well.

Here’s what I found when I opened that permission set in my org, after building Pilot Certification. The object was already there. I hadn’t granted anything: the connector already had Read and View All Records on Pilot Certification, and Read on every one of its fields. View All Fields was off. And the stream still brought in every certification, all 627 of them, with every field.

The Data Cloud Salesforce Connector permission set, object settings for Pilot Certifications: Read and View All Records ticked, Create, Edit, Delete, Modify All Records and View All Fields not ticked; Read Access on every field

The connector’s access to the new object, already there, with View All Fields off (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The connector permission set's object settings for Contacts: Read, View All Records and View All Fields on; Create, Edit and Delete off

On Contact, the same connector has View All Fields on (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

So why did it work? Because Read on each field is enough for the fields that exist today. View All Fields is about the future. When you create a stream, Data 360 shows a banner asking you to grant View All Fields (Global) on this permission set, “to ensure data is ingested from fields and objects created in the future.” Without it, every field someone adds later needs its own Read access before it can come in. On Contact, in the same org, View All Fields was on.

So check, don’t assume. Open the permission set for each object you ingest, look at the object and its fields, and decide whether you want View All Fields, or field-by-field access you grant on purpose. That’s a security choice as much as a data one (chapter 17).

Put this step on the plan with a name beside it: it’s done in core, often by a different person from the one building the stream.

Now in Data 360, on the Data Streams tab, click New and choose Salesforce CRM. Salesforce’s page walks it through:

  1. Pick the org, then the objects. You can select up to 30, and each one gets its own data stream.
  2. Choose the category: profile, engagement or other. A certification belongs to a person, but it isn’t the person; we’ll come back to categories in chapter 6.
  3. Decide on the data lake object’s name. Data 360 builds a default from the object’s API name and the org’s alias (module 1). Salesforce warns that a customized API name isn’t preserved when you deploy to another org, and the transforms, identity resolution and data space filters that depend on it can then fail to deploy (chapter 22). More on this below.
  4. Review the fields. “By default, all fields for an object are selected.” Deselect what you don’t need (chapter 3, module 5). You can add formula fields here too.
  5. Choose the data space, and deploy. The refresh schedule is set for you (module 4).

New Data Stream, View Objects: Salesforce Objects (1156), searched for Pilo, with Pilot Certification, Pilot_Certification__c, marked as a custom object

Finding the custom object (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

Pilot_Certification__c Details: the default data lake object label, API name and stream name Pilot_Certification__c_Home, Object Category not yet chosen, primary key Record ID

The stream’s defaults, before you choose a category (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The default here is Pilot_Certification__c_Home: the object’s API name, __c and all, then the org’s alias. In my org I changed it to Pilot_Certification_Home, in the label, the API name and the stream name. Why? Because the bundles in module 2 had already made Account_Home and Contact_Home, and I wanted the custom object’s lake object to read the same way, with no __c in the middle.

Pilot_Certification__c Details, filled in: data lake object label, API name and stream name all Pilot_Certification_Home, Object Category Other, primary key Record ID, 16 fields selected

The same screen, renamed and with the category chosen (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

That’s a trade-off, and you should make it on purpose. In one org, a cleaner name helps everyone who reads it. But Salesforce’s warning is about the next org: the custom name isn’t carried across when you deploy, and whatever was built on it can fail. If this org’s work will be deployed to another (a sandbox to production, say), keep the default. If it won’t, or your team has a naming standard and a plan for deployments, rename it, and write the decision down. Either way, decide before you save: as the screen says, “After saving the data stream, you can’t change these configurations.”

The standard fields of Pilot Certification, all selected, with System Modstamp and Record ID required

The fields, all selected by default (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The custom fields of Pilot Certification in the new stream: Record Source, Pilot, Issue Date, Expiry Date, Certification Type, Certification, Aircraft Type Rating, all selected, none batch

And the seven custom fields (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The finishing touches: data space default; this bundle creates 1 data stream and data lake object; Pilot_Certification_Home, category Other, refresh mode Upsert

The data space and the refresh mode, set for you (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

Data Streams, Recently Viewed, just after Deploy: Pilot_Certification_Home, Salesforce CRM, Last Run None, Processing, beside Pilot_SkyData, Contact_Home and Account_Home

Just after Deploy: Processing (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The Pilot_Certification_Home stream: Active, Last Run Success, Last Processed Records 628, Total Records 627

The certifications in: 627 (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The stream lands the certifications in a data lake object. To use them for identity resolution, segments or insights, they need to be mapped to the data model, either to a standard object or to a custom data model object of your own. That’s chapter 8.

Your custom object won’t stand still. Someone will add a field next quarter. You don’t need to drop the stream and start over: give the connector access to the new field, then add it to the existing stream as a source field. That matters, because if you’re going to delete a data stream, there could be a dependent data lake object, data transforms and data model objects. So it can be kind of unraveling the sweater. Being able to add a field later is a very powerful mechanism.

The Contact_Home data stream before the new field: 74 fields, 39 of 79 mapped, 150 records

Contact_Home before: 74 fields (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The connector permission set's Contacts field list: Sky Data Contact ID, Sky_Data_Contact_ID__c, with Read access

First, the connector can read the new field (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

New Source Fields on the Contact_Home stream: one new field, Sky Data Contact ID, Sky_Data_Contact_ID__c, Text, selected

A new field joins a running stream (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

The Contact_Home data stream after the new source field was saved: 75 fields, still 39 of 79 mapped

After: 75 fields, no new stream, nothing rebuilt (Salesforce Data 360 in a Developer Edition org, screenshot, November 2026). Full size

Going the other way, be careful. Disabling a field in a CRM stream will “stop new data ingestion, clear existing data for the fields, and remove it.” And you can’t give a new field the name of a disabled one.

  • Which custom objects come in, and which stay in core.
  • Who grants the connector access in core, for each object, its fields and its related objects, and whether View All Fields is on.
  • The category of each stream, and whether to keep the default lake object names, so deployments work.
  • How new fields reach Data 360 after go-live: access first, then the source field.

All checked 2026-11-14.