# Create your first Profile Resolution project

Use this guide to create your first Profile Resolution project.

[Profile Resolution](/identity-resolution/profile-resolution.md) builds the canonical profile spine: one resolved profile per [`dinmo_id`](/identity-resolution/dinmo-id.md), exposed through the [golden record](/identity-resolution/golden-record.md) table and reused by Customer Hub, Segments, Activations, analytics, and downstream models.

<figure><img src="/files/pysb4RxQSRa3ldhJBkI7" alt="Identity Resolution project overview with key stats, trend chart, resolution rate, and breakdown tables"><figcaption><p>After the first run, the project overview shows quality metrics and breakdowns.</p></figcaption></figure>

## Prerequisites

Before starting, make sure you have:

* access to a DinMo workspace with Identity Resolution enabled
* at least one connected data source
* profile-like source models with stable primary keys
* useful identifiers such as email, phone, user ID, customer ID, anonymous ID, or device ID
* an order field on each source model, such as an update timestamp

## Implementation overview

| Step                       | What you do                                                     |
| -------------------------- | --------------------------------------------------------------- |
| 1. Define the scope        | Select the source, identity models, and identifiers.            |
| 2. Configure models        | Map model fields to the identifiers defined in Step 1.          |
| 3. Define matching rules   | Create the identifier combinations that allow records to merge. |
| 4. Configure golden fields | Select the identifiers and fields exposed in the golden record. |
| 5. Finalize                | Review metadata and choose when the identity graph should run.  |

## Step 1: Define the scope of your identity project

<figure><img src="/files/c1QYJ5g2TR0IrMiEUuhy" alt="Identity project scope step with source, models, identifiers, standardization methods, and conflict limits"><figcaption><p>The scope step defines which source, models, and identifiers participate in the identity graph.</p></figcaption></figure>

**A. Select the source**

Choose the source that holds the models linked to the tables you want to use for your identity resolution project.

Identity projects can be linked to only one source.

{% hint style="info" %}
Identity Resolution is executed in the cloud data warehouse connected to your source data. All generated outputs are written to a dedicated schema named `dinmo_identity`.

Before launching your first project, create this schema and grant DinMo ownership on it.
{% endhint %}

**B. Select identity models**

Choose models that represent people, customers, users, subscribers, accounts, or contacts.

Good profile inputs include:

* CRM contacts
* ecommerce customers
* app users
* subscribers
* support contacts

Avoid using high-volume event tables directly as profile inputs. Events should be attached through [Event Stitching](/identity-resolution/event-stitching.md).

**C. Define identifiers to be used for matching**

Select the identifiers that DinMo can use to match and merge records across the identity models selected in the previous step.

At this stage, you are defining the logical identifiers available in the [identity graph](/identity-resolution/identity-graph.md). You will map these identifiers to actual model fields in the next step.

Identifiers can represent stable customer keys, contact details, or secondary profile attributes, such as:

* user ID
* customer ID
* email
* phone number
* first name
* last name
* country
* ZIP code

For each identifier, configure:

| Setting                | Description                                                                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Identifier             | The logical identifier DinMo will use in matching rules. You can select a standard identifier or add a custom one.                   |
| Standardization method | The normalization applied before matching, such as case insensitive comparison, trimming spaces, or keeping only numeric characters. |
| Conflict limit         | An optional guardrail that defines how many distinct values of this identifier can exist inside one resolved profile.                |

{% hint style="success" %}
**Conflict limits** help prevent unsafe merges. For example, you may allow only one `user_id` per resolved profile, while allowing several emails or phone numbers depending on your data model. See [Matching rules](/identity-resolution/matching-rules.md#conflict-limits) for more details.
{% endhint %}

Choose identifiers that are meaningful across your selected models. Start with stable and high-confidence identifiers, then add secondary identifiers only when they help support stricter matching rules.

## Step 2: Configure models

In this step, map the identifiers defined in the previous step to the actual fields available in each identity model.

<figure><img src="/files/wsyAKHr4dOZlPNRQ0hJy" alt="Configure models step showing model fields mapped to identity identifiers"><figcaption><p>Each selected model maps its physical fields to the identifiers used for matching.</p></figcaption></figure>

**A. Map model fields to identifiers**

For each selected model, review the list of available fields and choose which fields should participate in the identity graph.

Use the **Use** checkbox to select a field, then assign it to one of the identifiers defined in Step 1.

For example:

* `mail` can be mapped to `Email`
* `phone number` can be mapped to `Phone Number`
* `id` can be mapped to `User ID`

The identifier is the logical concept used by DinMo. The model field is the physical column in your source model.

**B. Repeat the mapping for each model**

Each model can use different field names for the same identifier.

For example, `email`, `mail`, and `customer_email` can all be mapped to the same `Email` identifier across different models.

An identifier does not need to exist in every model, but each identifier used in the identity graph should be mapped to at least one field.

**C. Select an order field**

If available, select an order field for each model.

The order field is usually a timestamp such as `updated_at`, `created_at`, `signup_date`, or `last_login_date`. It helps DinMo order records within a model when evaluating the most recent available information.

The order field is optional, but recommended when your models contain timestamps that reflect record freshness.

## Step 3: Define matching rules

Define the identifier combinations that allow records to merge into the same resolved profile.

<figure><img src="/files/vOC1DeevtdiLiuo9yz3G" alt="Match rules step showing criteria joined by AND and rules joined by OR"><figcaption><p>Matching rules define which identifier combinations can merge records.</p></figcaption></figure>

Start with conservative rules that are easy to explain and validate:

* exact user ID
* exact customer ID or CRM ID
* exact email
* exact normalized phone number
* exact strong identifier + fuzzy secondary attribute

Criteria inside the same rule use **AND** logic. Multiple rules act as **OR** alternatives. If you use [fuzzy matching](/identity-resolution/fuzzy-matching.md), anchor it with at least one exact criterion.

See [Matching rules](/identity-resolution/matching-rules.md) for the detailed AND/OR model, match types, criteria, and guardrails.

## Step 4: Configure golden fields

Decide which identifiers and fields should appear in the [golden record](/identity-resolution/golden-record.md), and how DinMo should choose the winning value when several source records provide different values.

DinMo automatically includes `dinmo_id` and `last_updated_at`.

**A. Select the fields to include**

Add only the identifiers and model fields that should be available downstream.

* **Identifier**: one of the identifiers defined in Step 1, such as `email`, `phoneNumber`, `userId`, or `country`
* **Model Field**: a specific field from one of the selected identity models, such as `Prospects.lastlogindate`

**B. Choose a survivorship strategy**

For each golden field, choose how DinMo should select the value when multiple records are merged into the same `dinmo_id`:

| Strategy             | Description                                                                             |
| -------------------- | --------------------------------------------------------------------------------------- |
| Last non null        | Keeps the most recent non-empty value available for the field.                          |
| Most frequent        | Keeps the value that appears most often across the merged records.                      |
| Model Priority Order | Keeps the value from the most trusted model according to the configured model priority. |

See [Survivorship rules](/identity-resolution/survivorship-rules.md) for strategy details and recommended use cases.

Keep the first golden record focused. Start with high-impact fields such as email, phone number, user ID, customer ID, country, consent status, and key lifecycle dates.

## Step 5: Finalize

Review the project details and choose when the identity graph should run.

**A. Add project details**

Enter a name and optional description.

**B. Select a schedule**

Choose **Manual**, **Interval**, or **Custom Recurrence**. Use **Manual** while validating the setup.

**C. Save**

Save to create or update the identity graph.

## Next steps

After the first run:

* validate the first run in [Review and monitor](/identity-resolution/review-and-monitor.md)
* query the generated warehouse tables in [Output tables](/identity-resolution/output-tables.md)
* configure [Event Stitching](/identity-resolution/event-stitching.md) once the profile spine is trusted


---

# 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/identity-resolution/get-started.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.