# 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.


---

# 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/integrations/destination-platforms/microsoft-dynamics-365-1/synchronise-object-attributes.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.