# Detect the object status from onOffice

<Lead>
The object status (Active, Reserved, Sold and so on) is detected from onOffice
automatically during the sync. This page explains exactly how that works, how to
attach your own status value list, and how to fix "all objects set to active".
</Lead>

## Automatic detection from standard fields

onOffice provides three reliable standard fields with every object, and the
platform derives the status from them. You can rely on these because onOffice
always includes them, regardless of the broker configuration.

<DefinitionList>
<DefItem term="verkauft = yes">→ **Sold** (`sold`)</DefItem>
<DefItem term="reserviert = yes">→ **Reserved** (`reserved`)</DefItem>
<DefItem term="status = active">→ **Active** (`active`)</DefItem>
<DefItem term="status = inactive">→ **Draft** (`draft`)</DefItem>
</DefinitionList>

The order is unambiguous: **sold** beats **reserved**, which beats the **active
flag**. A sold object is therefore always "Sold", even if onOffice still lists it
as active. An unknown status code is deliberately kept visible (Active) rather
than hiding the object under a guessed value.

<Success title="Correct without configuration">
For most brokers this is all it takes: sold, reserved and active are detected
correctly without any mapping. You only need a status mapping if you want finer
stages (see below).
</Success>

## Map a custom status value list (e.g. Status2)

Many onOffice accounts keep the marketing status in a **custom field**, often
`Status2`, with an individual value list: "Active marketing", "Passive
marketing", "Reserved", "Sold, sole sale", "In acquisition", "Market
observation", "Order expired" and so on.

The automatic detection cannot know such fine stages (Acquisition, Preparation,
Lost, Archived). For those you map the field yourself:

<Steps>
<Step title="Open the field mapping">
Under **Settings → Integrations → onOffice**, in the "Objects from onOffice"
frame, open the **"Field mapping"** area.
</Step>
<Step title="Add the status field">
Add a new row: pick your status field as the onOffice field (e.g. `Status2`), and
**"Status"** as the platform field.
</Step>
<Step title="Translate the values">
Click **"Values"** in the row. **"Load values from onOffice"** fetches the field's
real value list, and you map each onOffice value to a platform status (e.g. "Sold,
sole sale" → Sold). Suggestions are pre-filled; review them.
</Step>
<Step title="Save and sync">
Save the mapping, then click **"Sync now"**. On the next sync your mapping wins
whenever it resolves a value.
</Step>
</Steps>

<Info title="Your mapping wins, detection is the safety net">
If your status mapping resolves a value, that value is used. If it resolves
nothing (value not translated, or the field not readable right now), the
automatic detection from sold / reserved / status kicks in. So the status is
always sensible.
</Info>

## Fixing "all objects set to active"

Previously it could happen that **all** imported objects were "active", including
sold ones. This had a clear cause and is fixed.

<Accordion>
<AccordionItem title="Why it happened">
When the status mapping did not resolve (for example because the mapped field
`Status2` was once classified as "unknown" via the API and then silently
skipped), the status was set to "active" as a fallback on insert. On update it
stayed "active". Result: all objects active.
</AccordionItem>
<AccordionItem title="What changed">
The status is now derived from the reliable standard fields instead of being set
to "active" blindly. Sold and reserved objects are detected correctly, even
without a working Status2. A field once classified as "unknown" gets a fresh
chance when you save the field mapping and is read again on the next sync.
</AccordionItem>
<AccordionItem title="What you should do">
Open the field mapping, save it once (this releases previously skipped fields)
and click "Sync now". Already imported objects are updated in the process; sold
and reserved jump to their correct status.
</AccordionItem>
</Accordion>

<Warning title="If your status field cannot be read">
If onOffice cannot deliver a mapped status field via the API, the platform keeps
using the automatic detection (sold/reserved/status). Sold and Reserved are then
still correct; only the fine stages from your own value list are missing. In that
case, check whether the API user is allowed to read the field.
</Warning>

## Available platform statuses

<DefinitionList>
<DefItem term="Draft">Not yet in marketing.</DefItem>
<DefItem term="Acquisition">In acquisition / market observation.</DefItem>
<DefItem term="Preparation">Before marketing starts.</DefItem>
<DefItem term="Active">In active marketing.</DefItem>
<DefItem term="Reserved">Reserved.</DefItem>
<DefItem term="Sold">Sold or let.</DefItem>
<DefItem term="Paused">Marketing paused.</DefItem>
<DefItem term="Lost">Order ended without a deal.</DefItem>
<DefItem term="Archived">Archived.</DefItem>
</DefinitionList>

## Next

<CardGrid>
<Card href="/help/integrations/onoffice/objekte" title="Object sync" eyebrow="Basics">
The full object sync workflow.
</Card>
<Card href="/help/integrations/onoffice/feldzuordnung" title="Field mapping" eyebrow="Deep dive">
Map fields, add custom fields, translate values.
</Card>
</CardGrid>