---
cuppy_hub: salesforce
cuppy_path: reference/data360/automation-and-data-kits.md
cuppy_section: docs
cuppy_doc: SW40-MKQF
cuppy_doc_uuid: ccd5fc44-8b8e-4da7-97f1-6dbcf90ab1e0
cuppy_permalink: https://cuppy.io/salesforce/d/SW40-MKQF
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/salesforce/docs/reference/data360/automation-and-data-kits
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 79f4dcc390f9a619f6fb276d80fc21998874aa657be45d255577b579508b3c35
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Automating Data 360

## Three routes

| Route | Use it to | Covers |
|---|---|---|
| **Connect API** (`/services/data/v66.0/ssot/...`) | Build and run inside one org, from a script or CI | Connections, data streams and their runs, DLOs, DMOs, mappings, data spaces, identity resolution and runs, calculated insights and runs, search indexes, data graphs and refreshes, segments, `query-sql`, data kits |
| **Data kits** | Move a working configuration to another org | Stream bundles (CRM and others), DLOs, transforms, calculated insights, identity resolution, search (`DataSemanticSearch`), AI retrievers, segments, data actions, semantic models and more |
| **Metadata API** (`sf project deploy`) | Version and deploy what a kit packages | `DataPackageKitDefinition`, `DataPackageKitObject`, `DataKitObjectTemplate`, `DataStreamDefinition`, `DataSrcDataModelFieldMap`, `ObjectSourceTargetMap`, `MktCalcInsightObjectDef`, `DataObjectSearchIndexConf`, `MarketSegmentDefinition` |

There is **no** metadata type for an identity resolution ruleset or a retriever in Salesforce's registry. Those move through a data kit, or through the Connect API with a captured body.

## Data kits

1. In the source org, add the components to a data kit. A kit is metadata (`DataPackageKitDefinition`): retrieve it, commit it and deploy it.
2. In the target org, deploy the kit's components with `POST /services/data/v66.0/ssot/data-kits/{dataKitDevName}` and a `components` array of `{ "type", "config" }` objects. Configs from Salesforce's payload guide:

| `type` | `config` fields |
|---|---|
| `DataStreamBundle` (CRM) | `bundleName`, `forceNoRefresh`, `bundleConfig.orgId` |
| `DataLakeObject` | `dataSourceObjectDevName`, `apiName`, `label`, `dataSpaceName` |
| `IdentityResolution` | `dataSpaceName`, `templateDevName`, `dataKitDevName` |
| `CalculatedInsight` | `apiName`, `apiNameOverride`, `label`, `publishInterval` |
| `DataTransform` (batch) | `dataTransformDevName`, `apiName`, `label`, `dataSpaceName`, overrides |
| `DataSemanticSearch` | `dataSpaceName`, `searchIndexName`, `dataKitName` |
| `MarketSegment` | `name`, `dataKitName` |

AI Retriever, Activation, Data Custom Code and others are supported too, but the guide gives no example payload for them.

Related endpoints:
- `GET /ssot/data-kits` and `/ssot/data-kits/available-components`;
- `GET /ssot/datakit/{name}/manifest` (note the singular `datakit`);
- `POST …/data-kits/{name}/undeploy`;
- per-component `…/components/{component}/dependencies` and `…/deployment-status`.

Per a community audit of Salesforce's v67 spec, there is no get-single-kit or deploy-job status resource: poll component status instead. That audit also found that deploying a kit into the org that built it was rejected. Deploy to a different org.

## Capture and replay

The nested request bodies for identity resolution, search indexes and data graphs didn't render for the hub in Salesforce's Connect API reference. The reference page itself (`developer.salesforce.com/docs/data/connectapi/references/spec`) has the OpenAPI document, about 201 operations at v67 per the community audit; download it there. For a script that must not guess:

1. Build the component once in a development org, in the UI or by API.
2. `GET` it and remove server-owned fields: IDs, status, run times, created and modified stamps.
3. Commit the JSON next to the pipeline.
4. In other orgs, look it up by name, and `POST` it if it's absent or `PATCH` it if it differs.

`guides/data360/automate-the-golden-record-pipeline.md` implements this.

## Order of operations

1. **Manual and Setup:**
   - Data 360 provisioned;
   - Einstein and Agentforce on (`guides/agentforce/build-agent-with-agentforce-dx.md`);
   - the integration user's Data 360 permission sets;
   - the CRM connection;
   - the agent user's Data 360 access and data space scope.
2. Streams for Account, Contact, Order, OrderItem and Product2 → wait for the first refresh.
3. Mappings, including Order → Sales Order and OrderItem → Sales Order Product.
4. Identity resolution rulesets → run → wait (up to 30 minutes).
5. Calculated insights → run.
6. Narrative DMO and its transform → run. Then the search index → Ready, the data graph → refresh, and the retriever → active.
7. Data Library (`sf agent adl create`) → agent publish and activate → agent tests.

## Rules for the scripts

- **Idempotent:** every step reads before it writes, and the script can be re-run after any failure.
- **Gate the credit-consuming steps** behind an explicit flag: stream runs, identity resolution runs, insight runs, index builds and data graph refreshes all consume Data 360 credits (family 10).
- **Respect run limits:** identity resolution on-demand runs are limited per day (`reference/data360/identity-resolution.md`).
- **Verify with SQL after each stage**: counts in the DLO, DMO, unified, CIO and chunk objects, through `query-sql`.
- **Tools:** no official `sf` plugin manages Data 360 setup. A community plugin, `@anushdsouza/sf-plugin-data360`, wraps 135 operations and is an experimental beta, not a Salesforce product. Its source is a useful map of endpoint paths.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 376 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/salesforce/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->