* Data 360 *

Hi @Allan Pheiffer,

Since neither object is in the CRM connector, the realistic route is to push the data in yourself. Here are the options, most practical first. 

1. Keep the EventLogFile approach, but centralize it (recommended) 

• Extend your script, or use middleware such as MuleSoft, to loop over every org and pull the Login and Lightning page-view logs.
• Add an OrgId column to every row. Include it in the primary key, otherwise IDs from different orgs can collide.
• Load the result into Data 360 in one of two ways: 
  • Land the files in cloud storage and use the storage connector.
  • Push them to the Ingestion API. It supports both streaming and bulk patterns, and it handles backfills and scheduled loads of large volumes. salesforce
• For a Tableau Next usage report, daily batches are usually enough. If you want fresher data, streaming ingestion is processed asynchronously roughly every 3 minutes. salesforce
• Event Monitoring logs are a good source but aren’t durable, so data loss can occur during site switches, instance refreshes or outages. Keep your own copy of the raw files if you need an audit-grade history. salesforce

2. Push from inside each org

• Run a scheduled Apex or Flow job in each source org.
• Query LoginHistory with SOQL and call the Ingestion API.
• For LightningUriEvent, plan the query carefully. It’s a big object that only allows filtering on EventDate and EventIdentifier, and only supports WHERE, ORDER BY and LIMIT. That means incremental pulls by EventDate watermark. salesforce
• This keeps everything in Salesforce, but you maintain code in every org.

3. Streaming via Real-Time Event Monitoring

• LoginEventStream is part of Real-Time Event Monitoring and requires the Shield Event Monitoring add-on plus the View Real-Time Event Monitoring Data permission. salesforce
• There is also a Data 360 Platform Events connector, but it’s in Beta and requires a Shield or Event Monitoring license along with a Data Cloud license. salesforce
• I haven’t verified whether that connector can subscribe to other orgs’ event buses or only the home org’s. Check that before designing around it. Beta status may also have changed since that page was written.

What won’t solve it

• Data Cloud One. Standard CRM connections can already ingest from many orgs. Data Cloud One adds companion-org access to the unified data, not new source objects. salesforce

Check in each source org

• Event Monitoring or Shield is licensed in every org, since LightningUriEvent and the logs depend on it.
• How far back you need history. I believe LoginHistory is only kept for about six months, but I haven’t confirmed that here. If you need a longer history, start archiving now.
• Whether the “home page” usage you want to report on is the same as Lightning page views. LightningUriEvent covers record create, access, update and delete in Lightning Experience only, and doesn’t track Setup events. For page-level views, the Lightning page-view log in EventLogFile may fit better. I haven’t checked its exact fields. salesforce

Sources:

• LightningUriEvent (Platform Events Developer Guide)
• Ingest Data into Data 360
• Set Up the Platform Events Connector (Beta)
• Subscribe to a Standard Platform Event Channel
• Connect Multiple Orgs with Data Cloud One (Trailhead)

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

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.

 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. 

Hi @Cosmin Stanescu

, 

I recently ran into a very similar issue. After some investigation, I found that Salesforce had sent a Security Notification regarding Data Cloud access for portal and guest users.

The notification stated:

According to Salesforce, this only affects environments where administrators have explicitly configured access to Data Cloud (Data 360) entities for portal or guest users, for example by assigning Data Cloud permissions to community users, exposing Apex classes through Experience Cloud, or using Retriever-based access.

In my case, the issue was related to these security changes. After reviewing and updating the Data Cloud entity access settings according to Salesforce's guidance, the flow started working again. I would recommend checking whether your org received the same Security Notification and reviewing the

Based on my experience, it appears that Salesforce has tightened security around external access to Data Cloud objects, which may explain why something that worked previously is no longer working for guest users. Hope that helps!