> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Field mapping

> Map what Vorel captures onto the fields your CRM actually has, including custom fields.

Every CRM is customised. A generic integration writes a lead into the fields the vendor shipped, and
then your team cannot find it, because your business stopped using those fields two years ago.

Field mapping is how Vorel writes to your fields.

## How it works

Vorel captures a set of standard values during a conversation: contact details, the enquiry, what
was qualified, the source, the outcome. Mapping decides where each one lands in your CRM.

<Steps>
  <Step title="Connect the CRM">
    See [CRM](/integrations/crm).
  </Step>

  <Step title="Read the schema">
    Vorel inspects the CRM and lists the fields it actually has, including your custom ones. The
    mapping is built against reality rather than against the vendor's documentation.
  </Step>

  <Step title="Map">
    For each value Vorel captures, choose the destination field. Anything you leave unmapped is not
    written.
  </Step>

  <Step title="Test">
    Write a test record and confirm it lands where you expect before real traffic does.
  </Step>
</Steps>

## What can be mapped

| Vorel captures        | Typical destination                                      |
| --------------------- | -------------------------------------------------------- |
| Name, phone, email    | Standard contact fields                                  |
| The enquiry           | Description, notes, or a custom field                    |
| Qualification answers | Custom fields, one per question                          |
| Source and channel    | Lead source                                              |
| Booking details       | Appointment or activity record                           |
| Conversation link     | A custom URL field, so your team can open the transcript |

That last one is worth setting up. A link back to the conversation turns a CRM record from a summary
into something your team can verify.

## Custom fields

Custom fields are first-class. They are listed alongside standard fields when you build the mapping,
using the names your team gave them.

## Picklists

Where a CRM field is a picklist, the mapping shows the allowed values, so a value that would be
rejected on write is caught while you are configuring rather than in a queue of failed writes.

## Changing a mapping

Mappings can change at any time and take effect on the next write. Existing records are not
rewritten, which is usually what you want: a mapping change fixes what happens from now on rather
than rewriting history.

## When a write fails

A rejected write is retried with backoff and surfaced under **Reliability** rather than dropped. The
common causes are a required field the mapping does not fill, a picklist value the CRM does not
accept, and a permission the connected credential does not have.

Because writes are queued outside the customer's turn, a mapping problem never affects the
conversation. It shows up as a queue you can fix and redrive.