# Overview

{% hint style="info" %}
Activation is the process of synchronizing a segment’s or model’s data to a predefined destination.
{% endhint %}

An activation can trigger one or many syncs, depending on its configuration and schedule. A sync is the technical execution that applies changes from DinMo to the destination.

For most recurring activations, DinMo is designed to avoid reprocessing the full dataset at every run. The first run usually creates the initial state, then following runs process only the records that changed since the previous execution.

For more details, see Run types and Sync modes.

### Sync operations

When syncing data to a destination, DinMo can perform different operations depending on the destination capabilities and the activation settings:

* **Insert** a new record and its attributes
* **Update** an existing record's attributes
* **Delete** an existing record
* **Clear** all existing records when the selected mode requires a full replacement

### Run types

Run types define how much source data is processed during each execution.

* **Full sync** processes the full dataset. It is automatically used for the first run of an activation and can also be triggered manually when a full refresh is needed.
* **Delta sync** processes only data that changed since the previous successful run. This is the default behavior for recurring activations when supported by the destination and configuration.
* **Incremental sync** is used for event-based use cases where DinMo sends only the newest event data.

Delta and incremental runs help reduce processing time, data warehouse compute, API calls, and bandwidth usage.

### Sync modes

Sync modes define how the processed records are applied to the destination. Available modes depend on the destination.

Common sync modes include:

* **Upsert**: creates new records and updates existing ones. Records missing from the source are not deleted from the destination.
* **Update only**: updates records that already exist in the destination. New records are ignored.
* **Insert only**: creates new records only. Existing records are left unchanged.
* **Mirror**: keeps the destination aligned with the source by applying inserts, updates, and deletions when the destination supports it.
* **Snapshot**: exports or writes a full snapshot of the selected data.

Each activation runs with one sync mode, and the setup form only displays the modes supported by the selected destination.

<figure><img src="/files/yxRBu7Ki6oBKyDHgkdqI" alt=""><figcaption></figcaption></figure>

### Fields Mapping

Mapping defines how fields from a segment or model should be matched with the fields expected by the destination.

For example, a destination may require DinMo to know which column contains the email address, phone number, customer ID, order ID, or other platform-specific identifier. Additional attributes can also be mapped when the destination supports them.

Mappings are important because they determine which fields are sent and how records are matched, created, updated, or deleted in the destination.

<figure><img src="/files/elWEhrwcpLUOwUufuFeT" alt=""><figcaption></figcaption></figure>

### Run history

The **Run history** tab lets users monitor each sync execution and verify how the activation behaves over time.

For each run, DinMo displays operational statistics such as:

* **Extracted**: the number of records selected for the sync before validation. On recurring delta runs, this reflects the changed records to process, not necessarily the full source dataset.
* **Loaded**: the number of operations applied to the destination. Users can expand this value to see inserted, updated, and deleted records.
* **Source issues**: records skipped before being sent because of source-side validation issues, such as an empty or invalid email address.
* **Destination issues**: records sent by DinMo but rejected by the destination.
* **Status**: the final status of the run.

This makes it possible to confirm that recurring activations are running incrementally and to understand exactly which operations were performed during each sync.

<figure><img src="/files/Uq4ZzFombSeZqZAbiKc1" alt=""><figcaption><p>Troubleshooting Destination Issues</p></figcaption></figure>

{% hint style="info" %}
Not all destinations return detailed statistics about rejected records. When available, DinMo displays these errors in the **Destination issues** column.
{% endhint %}

<figure><img src="/files/zfSFTJteMjccCJ3c6psO" alt=""><figcaption><p>Monitoring run operations</p></figcaption></figure>

***

## Ready to get started?

Book a demo and we will walk through the best way to launch your first DinMo use case.

[Book a demo](https://www.dinmo.com/contact/)

## Need help?

Our team is here to help with setup, modeling, activation, and troubleshooting.

[Contact us](mailto:hello@dinmo.com?subject=Docs%20help)

## Feature requests?

Tell us which connector, workflow, or improvement would make DinMo more useful for your team.

[Request a feature](mailto:hello@dinmo.com?subject=Feature%20request)

[Privacy Policy](https://www.dinmo.com/legals/privacy/) | [Terms of Service](https://www.dinmo.com/terms-of-service/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dinmo.io/activations/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.