# Settings in detail

{/* AUTO-SYNCED SOURCE: this page lives in apps/app/src/modules/db-leads/docs/ and is mirrored into the docs app by `bun sync:module-docs`. Edit it in the module, not in apps/docs. */}

<Lead>
Settings (`/settings/tools/db-leads`) are organized into five groups, in the order of the work: first the connection to the CRM, then finding, then working with what was found, then who gets access, and finally the rarely needed. Every area has its own address (`/settings/tools/db-leads/<area>`); the settings open on the connection. Field mappings for addresses and properties are managed by the central onOffice integration under Settings, Integrations, onOffice.
</Lead>

## Connection

### onOffice

Connection status and sync trigger. There is no field mapping inside the tool anymore: address fields are managed by the central address sync, property fields by the central property sync (both under Settings, Integrations, onOffice). The lead import reads from the central address book and picks up the standard fields automatically. In depth under [onOffice import](/tools/db-leads/onoffice-import).

A sync fetches data, it does not rate anyone. If you want new and changed contacts assessed automatically, set the auto-scan under Database scan: it syncs before every run and rates afterwards.

### Synchronization

The live status of the import: per entity status, **inventory**, **last sync**, progress bar, and time. The inventory is the total the tool holds today, across all runs. The last sync next to it shows only what that one run changed: new, changed, unchanged. After the first full import, every sync only fetches what changed since the last one; a quiet day then reads as "No changes" while the inventory stays as it is. Three entities are shown:

<DefinitionList>
  <DefItem term="Addresses → Leads">This tool's address import from the central address book.</DefItem>
  <DefItem term="Activities → History">The complete onOffice agents log across all users, including full email bodies (inbound and outbound). This lets the AI read entire conversations and derive personas and acquisition signals from them. For very large histories the inventory is recounted every 15 minutes; if it cannot be counted right now, a dot is shown instead of a number.</DefItem>
  <DefItem term="Properties → Objects">The platform's central property sync. Status and link only, no second import. The AI uses the properties as context for activities.</DefItem>
</DefinitionList>

While a sync runs, the arrows on the button spin and a box names the phase, progress and remaining time. When it finishes, a short confirmation reports the result, even if the run took only seconds. Failed records appear with their external id and reason. Below, "Synchronized database fields" shows how many fields are active; both entries link into the central onOffice integration.

## Finding

### Database scan

All the knobs of the [database scan](/tools/db-leads/datenbank-scan):

<DefinitionList>
  <DefItem term="Time window (years)">How recent the last contact must be for a contact to be analyzed and a finding to be shown. 1 to 15 years, default 5. Never contacted? The creation date counts. Changes take effect immediately on the findings display: findings are shown or hidden, never deleted.</DefItem>
  <DefItem term="Signal keywords">Terms the prefilter matches against activity texts, maintained as chips. Defaults: Folgeauftrag, verkaufen, Erbe, geerbt, Scheidung, Umzug, Bewertung, Marktwert, Alleinauftrag, zu groß, Eigentümer. Hits prioritize the analysis order and feed the AI as context ("additionally watch for: …").</DefItem>
  <DefItem term="Auto-scan">Off, daily, weekly, or monthly. When active, the platform starts database scans in the background on its own. Every automatic run syncs with onOffice first and then rates only the contacts where something happened since the last assessment. **Daily is the recommended cadence:** your database stays current without any manual work, and a run costs a fraction of a full scan.</DefItem>
  <DefItem term="AI limit per run">Optional: maximum number of AI analyses per scan. The default is **no limit**: one run works through the entire database in stages (the analyses are included in the add-on). With a limit set, the run finishes cleanly at the limit; the next scan continues.</DefItem>
  <DefItem term="Adjust weights automatically">The scan learns from your decisions on findings which signals really count in your database and weights them accordingly on the next run. Off means fixed weights.</DefItem>
  <DefItem term="Include archived contacts">Default off, archived contacts are not scanned.</DefItem>
</DefinitionList>

A scan started by hand under Findings does the same as the automatic one: sync first, rate second. The start responds immediately; sync and rating run in the background, and the first findings appear within seconds.

### Qualification

The heart of the acquisition configuration. Each parameter (customer personas, contact types, acquisition signals, sales readiness, summary) is a mapping between the AI taxonomy and an onOffice field:

<DefinitionList>
  <DefItem term="onOffice field">Per parameter, the field on the onOffice address record (picker listing all fields of your account). Its option values feed the onOffice value column; the AI writes its result there. For "Zuletzt aktualisiert" only date fields are offered, because a date written into a text field does not arrive as a date in onOffice.</DefItem>
  <DefItem term="Link status">Below every field and every single value it says whether it is really linked to your onOffice, whether your onOffice does not know it, or whether nothing has been picked yet. Without a connected onOffice there is nothing to check, and the display says exactly that instead of claiming a link.</DefItem>
  <DefItem term="Map fields automatically">Looks up the matching entry in your onOffice for every parameter and every value and fills it in, evening out small differences in spelling. Anything that cannot be matched unambiguously is left empty and named, rather than guessed. Mappings you set yourself are never touched.</DefItem>
  <DefItem term="Value table">Per value: label (internal name the AI works with), AI description (how the AI recognizes this value), onOffice value (option of the mapped field), active switch, and delete. Add your own values via "Add custom value". The sentinel value "Kein Signal" is fixed: it is set when no other value is backed by evidence.</DefItem>
  <DefItem term="Summary (text)">Instead of values, an AI instruction describing how the summary is written (default follows the "information diet": only documented facts). "Restore default" resets it.</DefItem>
  <DefItem term="Acquisition status">The onOffice field that receives the lead's pipeline stage name after qualification (e.g. "Kontaktversuch", "Follow Up"). Switch off to disable.</DefItem>
  <DefItem term="Last updated">The date field that receives the day of the latest AI assessment, so onOffice shows at a glance whether the assessment still matches the recent activity.</DefItem>
  <DefItem term="Exclude contact types">Contact types that are not qualified. The exclusion also applies to the database scan's prefilter. These contacts no longer appear in the list, on the board, in counts, or in the CSV export either. Exception: a contact with a stage set stays visible so ongoing work does not disappear. In the list view, the "Excluded contact types" filter brings the rest back when you need them.</DefItem>
  <DefItem term="Write assessment to the agent log">Instead of (or in addition to) the "Last updated" field, every qualification adds a line to the contact's history in onOffice. Default: off. See below.</DefItem>
  <DefItem term="Context filters">Activities that feed the qualification as context (action type, direction, characteristic, label).</DefItem>
</DefinitionList>

<Callout tone="note" title="Automatic write-back to onOffice">
After every qualification the acquisition agent automatically writes the results into the linked onOffice fields. Requirement: the data-flow switch "Write to onOffice" of the onOffice integration is enabled. Only the configured acquisition fields are updated, nothing is deleted, and every write is logged in the lead's history. After writing, the record is read back to confirm the values actually landed: onOffice confirms a write even when it discards a value. Whatever did not arrive is stated in the contact's history.

Nothing is written for a parameter without a linked field. On first use no link is set, on purpose: fields are named differently in every account, and a suggested mapping that is not a real one looks exactly like a verified one. "Map fields automatically" takes care of most of the work.
</Callout>

#### Writing the assessment to the agent log

The switch is off by default, and both sides are worth knowing.

**In favour:** no purpose-built field required. The line appears in the contact's history with the assessment and a short rationale, and that history is kept rather than overwritten with every new assessment. On an account with no mapped fields, this is the only way to surface anything in onOffice at all.

**Against:** the contact's history fills up, and some offices read it daily. Once a line is in the agent log, the API cannot take it back out.

Below the switch you set the **action type** the line appears under. The default is "Notiz" because practically every account has it and it does not claim a call or a viewing that never happened. If your onOffice does not know the configured type, nothing is written, and the reason lands in the contact's history on our side under System. This line is written by the scan; in the agents log it therefore appears under the API user, not under a member.

#### Creating the fields in onOffice

"Map fields automatically" only finds what already exists in your onOffice. If no fields for the results have been created yet, the **"Create fields in onOffice"** section right below helps. For each field it gives you the name to copy, the required field type and all option values as a block to paste. "Check now" fetches your field list fresh from onOffice and reports per field whether it is in place, whether the field type does not fit, or which option values are still missing.

You create the fields yourself, in onOffice under Extras, Settings, Administration, Input fields. The onOffice interface may read fields but not create them; that is only possible in the administration and only with administrator rights.

<Callout tone="note" title="Two fields are enough to start">
The list is split into three tiers. With the two fields of the "Minimal" tier (summary and status date) every assessment is visible directly in onOffice. Everything beyond that exists so you can filter by these results inside onOffice, and it is optional.

The suggested fields are deliberately your own fields, not onOffice standard fields. The AI never writes its assessment into a field your office maintains itself: an AI contact type would otherwise overwrite the real one.
</Callout>

<Callout tone="note" title="AGG-compliant by design">
Qualification classifies only within these values and evaluates only documented behavior and statements from the activities, never personal characteristics.
</Callout>

### REOS AI

Two things live here:

<DefinitionList>
  <DefItem term="AI mode">REOS AI (platform AI, no setup needed) or your own provider key (BYOK, Max plan and up). Database scans are included in the DB-Leads add-on; single briefings are billed against your credit balance, or directly at your provider with BYOK. Details in the [Cost and add-on](/tools/db-leads/kosten).</DefItem>
  <DefItem term="Phase automation">Automatic, suggest, or off (default: off). This setting controls whether the [acquisition agent](/tools/db-leads/akquise-agent) moves leads into the derived phase on its own.</DefItem>
</DefinitionList>

The former switch "Automatically qualify new leads" is gone. It made a scan follow every sync, and that order was backwards. The same effect, in the right order, comes from the auto-scan under Database scan: sync first, rate second.

## Working

### General

Behavioral settings that span individual features:

<DefinitionList>
  <DefItem term="Assignee write-back">The onOffice field the assigned agent is written back to (e.g. `ID`). What gets written is the onOffice username mapped to the member under Settings, Integrations, onOffice; without a mapping the field in onOffice stays untouched. Empty = no write-back.</DefItem>
  <DefItem term="Notes to the agents log">The default of the switch in the note dialog: whether a note from the contact panel, an outcome of the run-through and the reasoning behind a readiness rating also go to the onOffice agents log, plus the action kind and action type of the line. Every note can be decided differently in the dialog. In the agents log the line appears under the onOffice user mapped to you; without a mapping, under the API user. If the transfer fails, the note stays in the tool and can be retried from its line.</DefItem>
  <DefItem term="Assessment retention">After how many months the tool deletes what the AI computed about a contact: assessment, summary, persona, signals, sales readiness, the findings, and the AI property hints. Default 24 months, adjustable between 6 and 60. Contact data and history stay (they belong to your CRM), and so do property hints you entered or confirmed yourself. Counted from the later of last contact and when the assessment was created; contacts with a stage set are exempt. The job runs daily.</DefItem>
  <DefItem term="Queue">Lock for the shared queue: clicking "Nächster Fund" under Findings hands out the highest-scoring free finding, and for the configured duration it is not offered to anyone else as their next one. It stays visible and workable for everyone. `0` = off: findings are still handed out, nothing is reserved. See [Database scan](/tools/db-leads/datenbank-scan).</DefItem>
  <DefItem term="Lead import">Pull incoming portal inquiries into the pool automatically, recognized by property origin. This option addresses new inquiries and conceptually belongs to the planned inquiries tool. You don't need it for owner mining. **Not active yet:** your choice is saved, but nothing is pulled in.</DefItem>
</DefinitionList>

### Pipeline

Maintain stages and disqualification reasons. Both lists are **reorderable** (arrows) and **inline-editable** (pencil): for stages the name and status, for reasons the name. New stages get a status type (Not started, In progress, Qualified, Disqualified) that drives timestamps and board behavior.

### Rules

The if-then rules: triggers, conditions and up to five actions per rule, plus a log of every execution. This is where you create rules, activate them, and apply them to existing contacts. The section has its own page: [Rules](/tools/db-leads/regeln).

## Access

### Grants

Who additionally sees whose contacts. A grant only matters for roles restricted to their own contacts (the "assigned contacts only" right); whoever sees everything anyway needs none. You pick the person who should see, the colleague whose contacts are meant, and can leave a note, for example the reason or the duration of a stand-in. Every grant can be revoked individually; the person then stops seeing those contacts immediately.

This area has its own right, independent of who may configure the tool: being allowed to maintain settings does not mean being allowed to redistribute whose customer data someone sees. Details under [Permissions](/tools/db-leads/berechtigungen).

## Other

### Maintenance

Everything you rarely need and only find when you look for it. Two sections:

<DefinitionList>
  <DefItem term="Rarely needed">The **full scan** re-rates the entire database, uses one run from the add-on's monthly quota and syncs with onOffice first; the quota status is shown next to it. The **complete synchronization** re-reads addresses and activities from onOffice in full, takes hours on a large database and is possible once a day. Nothing is lost with either; findings, assessments and pipeline stages stay.</DefItem>
  <DefItem term="Reset and delete">This discards what DB-Leads computed itself, in tiers: only the findings, the AI assessments including findings, the pipeline stages, or all of it "as freshly connected". Every tier says beforehand what disappears, what stays and how many records are affected. Your contacts and their history come from onOffice and are not touched by any action on this page; settings, stages, reasons and the connection stay as well. The scan history always stays, because the monthly quota hangs on it.</DefItem>
</DefinitionList>

Each card only appears if you hold the respective right; the reset carries its own. In depth under [Reset](/tools/db-leads/zuruecksetzen).
