---
schema_version: "1"
id: 945910ab3e539a685cdcd42fe4aaa0f9695d533caf105d754d14885ff29b030c
title: Data 360 In Apex
collection: legacydeveloper
version: current
locale: en-us
portal_url: https://docs.salesforce.com/legacydeveloper/current/en-us/apexcode/DataCloudInApex.md
canonical_url: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/DataCloudInApex.htm
source_site: developer.salesforce.com
content_type: documentation
content_hash: a7263d012946ee9c6096ab5b8a6b025b2da8662a6e6121a8a1cb3a064a04d746
description: You can use Apex with Data 360 objects, with constraints and considerations that are detailed in this topic. Further, you can mock SOQL query responses for Data 360 data model objects (DMOs) in Apex testing by using SOQL stub methods and a test class.
---
# Data 360 In Apex

You can use Apex with Data 360 objects, with constraints and considerations that are detailed in this topic. Further, you can mock SOQL query responses for Data 360 data model objects (DMOs) in Apex testing by using SOQL stub methods and a test class.

## Using SOQL in Apex with Data 360 Objects

Static SOQL is supported with Data 360 data model objects (DMOs) as a more direct alternative to using either dynamic SOQL or ConnectAPI. Additionally, SOQL queries against DMOs using Apex Database.QueryLocator or in FOR loops is supported in API version 61.0 and later. In versions earlier than 61.0, only the first 201 records are returned. Batch Apex is blocked against DMOs when using QueryLocators, but is supported when using Iterable.

![Warning](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/images/icon_note_warning.png)

#### Warning

Running SOQL queries against DMOs can result in Data Services credits being consumed from your Data 360 subscription. For more information on how usage is billed, see [Data 360 Billable Usage Types](https://help.salesforce.com/s/articleView?id=data.c360_a_data_usage_types.htm&language=en_US). Use caution when using FOR loops, query locators, recursion, or any mechanism that can result in multiple queries to Data 360.

A static SOQL query against Data 360 from Apex is considered a callout and is subject to the same restrictions as HTTP callouts from Apex. For example, if there is pending DML, this sample code can result in an unexpected exception with this message: UnexpectedException: A callout was unsuccessful because of pending uncommitted work related to a process, flow, or Apex operation. Commit or roll back the work, and then try again.

insert as user new Account(Name='Test');
List<ssot\_Account\_dlm> dmo1 = \[Select Id from ssot\_Account\_dlm WITH USER\_MODE\];

Apex cursors support SOQL queries against Data 360 objects. Use Apex cursors as performant alternative to Batch Apex for working with large query result sets. See [Apex Cursors](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cursors.htm "Use Apex cursors to break up the processing of a SOQL query result into pieces that can be processed within the bounds of a single transaction. Cursors provide you with the ability to work with large query result sets, while not actually returning the entire result set. You can traverse a query result in parts, with the flexibility to navigate forward and back in the result set. Package developers and advanced developers can use cursors to work with high-volume and high-resource processing jobs. Cursors combined with chained queueable Apex jobs are a powerful alternative to batch Apex and address some of Batch Apex’s limitations.").

## Security Considerations

You must consider field- and record-level access when using Apex with Data 360 data model objects (DMOs). DMOs in all data spaces are accessible from Apex in system mode, even when a permission set for the data space isn’t explicitly assigned. Read-only object-level access checks are supported if the user has access to the data space. There’s currently no support for field-level security or for record-level access control. Apex features, such as WITH USER\_MODE describe calls, and  Security.stripInaccessible(), can check only object-level access for DMOs.

Starting with API version 61.0, you can get information on a specific DMO using SObjectType.getDescribe(). There’s no field-level security to be enforced because all fields on DMOs that are accessed by field describes and security model checks are read only. You can’t use Schema.getGlobalDescribe() to discover exposed DMOs. Instead, use the Schema.describeSObjects(List<String>) method with the known DMO API names.

This example uses static SOQL with the UnifiedIndividual\_\_dlm Data 360 object.

//Static SOQL example
List<UnifiedIndividual\_\_dlm> unifiedIndividuals = \[
      SELECT
        Id,
        ssot\_\_FirstName\_\_c,
        ssot\_\_LastName\_\_c,
        ssot\_\_Email\_\_c,
        ssot\_\_SkyMilesBalance\_\_c,
        ssot\_\_MedallionStatus\_\_c
      FROM UnifiedIndividual\_\_dlm
      WHERE ssot\_\_CompanyId\_\_c = :companyId
      WITH USER\_MODE\];

- **[Mock SOQL Tests for Data 360 Data Model Objects](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/MockSOQLTestsForDMOs.htm)**  
    You can mock SOQL query responses for Data 360 data model objects (DMOs) in Apex testing by using the new SOQL stub methods and a new test class. Use static or dynamic SOQL queries against DMOs and return mock records in a testing context.