* Data 360 *

Hi @Vinícius Lima

, 

Short answer: there's no per-API-call line item. What actually gets billed is the

by the call, not the call itself — and it depends on which endpoint you're hitting.  

Breakdown of Data 360 billable usage types confirms the model is consumption-based, not call-based. These can be mapped to the endpoints as follows: 

1. 

usage category, thus usage is calculated based on the number of records processed. The count of records processed depends on the structure of a query as well as other factors like the total number of records in the objects being queried. So a getSegmentMembers call against a segment with 2M members is going to cost meaningfully more than one against a segment with just 200 members.  

2. 

, not customer data rows). They don't process party/individual records, so they don't fall into any of the record-based usage categories on the rate card (Data Queries, Segmentation, Batch Activations, etc.). In practice these behave like config reads, not data processing — so you shouldn't see credit consumption tied to them specifically.  

One important factor for your consideration (quoting exact wording from SF documentation): "Usage of certain Data 360 features impacts credit consumption. If you purchased credits before February 24, 2026, your org consumes Data Services credits for Data 360 services. Orgs purchasing or renewing after February 24, 2026 can have either Data Services or Flex Credits. To monitor your usage in these Data Services usage categories, access your org’s Digital Wallet. If your org has a Data 360 Profiles-type license, some usage types aren't consumed." (Source =

) 

Hope this helps.

Hi @Lukas Lunow

This gets easier to create an approach, when we look at how each piece works underneath. Not done personally, but this is how i would approach this: 

1. Sending works per row, so create the rows you want sent. MC Next sends one email per record that reaches the send step. If you want one email per account relationship, you need one row per Account Contact Relationship. Build a DMO with a Data Transform, keyed on the ACR Id, with the Contact Id, email and the account fields you need (company name, figures, role) on that row. Two relationships means two rows, which means two emails.
2. Personalization reads from the record being sent, so put the account data on that record. The data graph gets ambiguous when one person has several accounts attached, because nothing tells it which one to pick. If each ACR row already carries its own account data, the merge fields just read from that row and the output is deterministic.
3. Identity resolution is for the person, not the relationship, so let it do only that. Unified Individual exists to collapse the same human into one profile, which is exactly what you want for consent on email. Keep Contact Id as a Party Identification and match on email. Keep account-specific attributes off the Individual, so they never compete in the unified profile. Consent and suppression stay at the person level, and the send grain stays at the relationship level.

The main thing I’d validate is how cleanly MC Next lets you send off a relationship-level DMO while still checking consent on the linked Unified Individual. We can prototype with one contact on two accounts before rolling out. 

Hi  @Chris Mauro

, 

Hidden fields are a valid approach and probably the cleanest one in your setup.  

Here is what I would use: 

1. Read the Web SDK’s anonymous device ID on the main site and pass it into the MC Next form, either as a URL parameter on the CTA link or written into a hidden field. The form submission then carries both the email and the device ID, and identity resolution in Data Cloud can link the anonymous browsing to the known individual. You don’t need the SDK to fire an identity event on the subdomain.
2. Also check the SDK’s cookie domain setting. If the cookie is set on the root domain (yourdomain.com) and not the www host, the subdomain can read the same device ID. If you’re allowed to load the SDK on the form subdomain too, that closes the gap completely.
3. For the Pardot-style activity view on Lead/Contact, Data Cloud won’t surface it the way Pardot did. Use a Related List enrichment on the engagement DMO to show page views in sequence, and a Copy Field enrichment for single values like first referrer.

Test it with one form first. Verify that the device ID lands on the submission record and that the unified profile actually merges before rolling out. 

Hi @Benjamin C.

, 

I agree with Santosh that Data Space Filters are a weak fit, but one angle is worth testing before you rule them out.  

ContentVersion has a standard IsLatest field. If your content kit stream brings it in, try a dedicated data space used only for the Search Index, with a filter on IsLatest = true on the ContentVersion DMO. Because the filter evaluates current DMO values, superseded versions should drop out when they flip to false on the next sync. I’d avoid an ingestion-time stream filter for this. An update that flips a record to IsLatest = false may never land, so the old version could stay in the DMO as stale data.  

I’d stay away from a Data Transform into a custom DMO. The index depends on the standard file relationships, and rebuilding those is where things usually break. 

Hi @Lavanya Garimella

, 

Regrading your willingness to join any Data Cloud work, it would be difficult for anyone to involve any new user into any client-based project due to NDAs, confidentiality and time-critial deliverables. If you wish to learn and practice Data Cloud, i would suggest you could use the Salesforce trailhead modules and workshops (

That generic query failure in Data Explorer typically happens when the metadata synchronization between your DLOs, DMOs, and search indexes is interrupted during initial async build jobs. Because you are working in a Full Copy sandbox, background chunking and retrieval jobs can occasionally time out or lag due to resource constraints. To troubleshoot the issue, test metadata responsiveness by running a minimal query on just the primary key in Data Explorer. You should also review your Data Cloud job status and ensure that object permissions are not blocking access to the chunk objects. If failures persist, drop and rebuild the search index or manually refresh the data stream to allow background jobs to re-run successfully.

 In my project, I encountered a similar situation where we were unable to promote Data Kits to other Salesforce instances, whether it was a Partial Copy or a Full Copy sandbox. We reached out to Salesforce Support, but they didn’t have a clue. From my perspective, combining Salesforce CLI, VS Code, and AI

is the best approach to successfully deploy Data Kits. 

The Issue

Salesforce generates a single package.xml file for the DevOps Data Kit. While it contains all the items required for deployment, the deployment itself fails due to underlying Salesforce platform limitations and bugs. 

The Resolution

1. Extract the Data Kit package.xml file.
2. Retrieve all metadata from your source organization.
3. Run a validation against the destination organization.
4. Capture all the deployment errors you receive.
5. Feed the package.xml and error screenshots into an AI tool, then ask it to split the main package.xml into smaller, logical parts for deployment. Note: This step involves some trial and error. If you are lucky, you will get it right on the first try; otherwise, it might take 2 to 3 iterations.
6. Deploy the single Data Kit in phases based on the split versions of the package.xml generated by the AI, bypassing the single-file method provided by Salesforce.

Additional Context

When you open a Salesforce Support ticket for assistance, they rarely know how to fix this particular issue. Eventually, they suggested we use Change Sets to promote the changes. However, manually selecting Data Kit dependencies is incredibly tedious—in our case, a single Data Kit had 1,000+ dependencies

. By using AI to break down the massive package into manageable parts, I successfully promoted our changes all the way to Production without any issues. 

Probable Root Cause

Salesforce launched Data Cloud in a rush. I noticed a very similar pattern when they launched Community Cloud back in 2013, where we faced persistent deployment issues for it all the way up until 2020 and the main issue was promoting dependencies in sequence. same we are noticing in data kit deployments.