# Synchronise object attributes

### Activation configuration

Once the Dynamics 365 destination is connected, you can create an **activation** to sync a DinMo audience into a Dataverse table (e.g. `contacts`, `accounts`, or a custom table).

#### 1. Choose the target object

When creating an activation:

1. Select the **Microsoft Dynamics 365** destination you created earlier.
2. Choose the **target table** in Dataverse, for example:
   * `contacts`
   * `accounts`
   * `leads`
   * A custom table (e.g. `new_loyaltymember`)

DinMo will display the list of available tables exposed by the Web API.

#### 2. Primary key strategy – GUID only

DinMo uses the **Dataverse GUID** as the unique identifier for all activations.

For each target table:

* `contacts` → primary key: `contactid`
* `accounts` → primary key: `accountid`
* `leads` → primary key: `leadid`
* Custom tables → `{logicalname}id` (e.g. `new_loyaltymemberid`)

In your DinMo model, you must expose a column that contains this GUID:

* Example for contacts: `contact_id` (mapped to `contactid`)
* Example for accounts: `account_id` (mapped to `accountid`)

**Behaviour with GUIDs**

* **If the GUID is present** in the incoming record:
  * DinMo performs an **update** (PATCH) on the corresponding row in Dataverse.
* **If the GUID is empty or null**:
  * By default, DinMo **skips** the record (no creation).
  * This keeps the behaviour deterministic and avoids accidental record creation.

> Recommended workflow:
>
> * Use your initial Dynamics → warehouse ingestion to populate GUIDs.
> * Build DinMo models on top of that data and let DinMo update the existing records in Dynamics via the GUID.

(If later you want a “Create & update” mode, you can extend this behaviour to create new rows when the GUID is empty, then push the new GUIDs back to the warehouse via your ingestion jobs.)

#### 3. Field mapping examples

For each activation, you configure **field mappings** between DinMo attributes and Dataverse columns.

**Example – Contacts**

Typical mapping from a DinMo “Customers” model to `contacts`:

| DinMo attribute    | Dynamics 365 column   | Description                              |
| ------------------ | --------------------- | ---------------------------------------- |
| `contact_id`       | `contactid`           | GUID primary key (required for updates)  |
| `email`            | `emailaddress1`       | Main email address                       |
| `phone`            | `mobilephone`         | Mobile phone                             |
| `first_name`       | `firstname`           | First name                               |
| `last_name`        | `lastname`            | Last name                                |
| `country`          | `address1_country`    | Country                                  |
| `city`             | `address1_city`       | City                                     |
| `postal_code`      | `address1_postalcode` | Postal code                              |
| `lifetime_value`   | `new_ltv`             | Custom decimal field for LTV             |
| `churn_risk_score` | `new_churnriskscore`  | Custom score field                       |
| `segment_name`     | `new_segment`         | Custom text field representing a segment |

You can map any DinMo attribute to any writable Dataverse column, including custom fields.

**Example – Accounts**

Mapping from a DinMo “Companies” model to `accounts`:

| DinMo attribute    | Dynamics 365 column            | Description              |
| ------------------ | ------------------------------ | ------------------------ |
| `account_id`       | `accountid`                    | GUID primary key         |
| `company_name`     | `name`                         | Account name             |
| `industry`         | `industrycode` or custom field | Industry sector          |
| `billing_country`  | `address1_country`             | Billing country          |
| `billing_city`     | `address1_city`                | Billing city             |
| `billing_postcode` | `address1_postalcode`          | Billing postcode         |
| `account_tier`     | `new_customertier`             | Custom field for tiering |

#### 4. Sync behaviour

For each activation, DinMo will:

1. **Resolve the GUID**
   * Use the primary key field (`contactid`, `accountid`, etc.) from your model.
2. **Build a PATCH payload**
   * Only the mapped fields are included in the payload.
3. **Send updates in batches**
   * Batched calls to the Dataverse Web API, handling throttling and transient errors.
4. **Skip records without GUID**
   * No creation is attempted if the primary key is empty.

You can control:

* **Activation frequency** (e.g. hourly, daily).
* **Sync mode** (Upsert, Insert or Update only - logic based on your DinMo model).

#### 5. Recommended modelling

To make this integration clean and predictable:

* Keep a **dedicated field** for the Dataverse GUID in your dimension tables, for example:
  * `contact_id` (GUID from Dynamics)
  * `account_id`
* Avoid overloading it with internal warehouse IDs.
* Use that GUID consistently:
  * In your ingestion from Dynamics to the warehouse.
  * In your DinMo models and activations back to Dynamics.

This keeps Dynamics as the “source of truth” for identity, and DinMo as the decision and activation layer on top of it.