# Field mapping for the onOffice sync

<Lead>
Field mapping defines which onOffice field flows into which platform field. It
works the same for objects and addresses and ships with sensible defaults.
</Lead>

You find it under **Settings → Integrations → onOffice** in both frames
("Addresses from onOffice" and "Objects from onOffice"), each in the collapsible
**"Field mapping"** area.

## Anatomy of a mapping

Each row connects an **onOffice field** (left) with a **platform field** (right).
The switch enables or disables a row, the trash icon removes it.

<DefinitionList>
<DefItem term="onOffice field">The technical field name from your onOffice (e.g. `objekttitel`, `kaufpreis`, `Email`).</DefItem>
<DefItem term="Platform field">The target field in the platform (e.g. Title, Sale price, Email).</DefItem>
</DefinitionList>

## Add a custom field

Field names differ per onOffice account, especially for custom fields. So you can
enter any field:

<Steps>
<Step title="Pick or type a field">
In the "Add" row, choose a field from the list or, via "Custom field", type the
exact onOffice field name (case-sensitive, as in onOffice).
</Step>
<Step title="Pick the target field">
Select the matching platform field.
</Step>
<Step title="Add and save">
Click "Add", then save the mapping.
</Step>
</Steps>

## Translate values (value lists)

Fields with a fixed value list (for example object type, marketing type or a
custom status field) often need the onOffice values translated into platform
values. For suitable target fields the **"Values"** button appears.

<Steps>
<Step title="Open the values dialog">
Click **"Values"** in the row.
</Step>
<Step title="Load values from onOffice">
**"Load values from onOffice"** fetches the field's real value list. The platform
suggests a translation for each value.
</Step>
<Step title="Review and save">
Review each row, adjust as needed, then apply. Values without a translation leave
the target field unchanged.
</Step>
</Steps>

<Tip title="Status is usually already covered">
For the object status you usually need no value translation: sold, reserved and
active are detected automatically. Map a custom status value list (e.g. Status2)
only if you want finer stages. See the
<DocLink href="/help/integrations/onoffice/status">status guide</DocLink>.
</Tip>

## Unmapped fields are not lost

<Info title="Everything is written without loss">
Fields without a mapping are safe too: all raw data read is kept in full in the
object or contact details. You can add a mapping later and re-sync at any time,
without changing anything in onOffice.
</Info>

## Fields onOffice does not deliver

Field catalogs differ per onOffice account. If onOffice cannot deliver a
requested field, the sync skips it so the whole run does not fail. Such fields
are noted in the run log as "no counterpart in onOffice".

<Warning title="How to release a skipped field">
When you save the field mapping, previously skipped fields are released and tried
again on the next sync. If a field stays empty, check the exact field name
(spelling) and whether the API user is allowed to read the field.
</Warning>

## Reset to defaults

**"Reset to defaults"** restores the factory mapping. Your own rows are replaced.

## Next

<CardGrid>
<Card href="/help/integrations/onoffice/status" title="Detect status" eyebrow="Deep dive">
How the object status is determined and how to attach Status2.
</Card>
<Card href="/help/integrations/onoffice/problembehebung" title="Troubleshooting" eyebrow="Help">
Fixes for the most common sync problems.
</Card>
</CardGrid>