# Permissions

{/* 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>
DB-Leads writes into your CRM, sends messages and consumes AI budget. That is why its permissions are cut finer than "may enter" and "may not enter".
</Lead>

## The permissions at a glance

<PermissionTable roles="tenant_owner,tenant_admin,employee" caption="DB-Leads: default per role">
  <Permission action="tools.use.db-leads" label="Open" description="See the tool and its views." allow="yes,yes,yes" />
  <Permission action="db-leads.read" label="Read contacts" description="View contacts and the board." allow="yes,yes,yes" />
  <Permission action="db-leads.create" label="Create contacts" description="Record single contacts by hand." allow="yes,yes,yes" />
  <Permission action="db-leads.update" label="Edit contacts" description="Edit, change phase, notes, property leads, run-through." allow="yes,yes,yes" />
  <Permission action="db-leads.assign" label="Assign" description="Assign contacts to a person." allow="yes,yes,yes" />
  <Permission action="db-leads.qualify" label="Qualify" description="Start AI analysis, resolve findings, disqualify." allow="yes,yes,yes" />
  <Permission action="db-leads.delete" label="Delete contacts" description="Archive and permanently delete." allow="yes,yes,no" />
  <Permission action="db-leads.sync" label="Start sync" description="Trigger the sync with the CRM." allow="yes,yes,no" />
  <Permission action="db-leads.scan" label="Start scan" description="Run a full scan. Consumes AI budget." allow="yes,yes,no" />
  <Permission action="db-leads.export" label="Export contacts" description="Download the filtered database as a file, with names, contact details and scoring." allow="yes,yes,no" />
  <Permission action="db-leads.scope.manage" label="Share other people's contacts" description="Additionally show one person the contacts of a colleague." allow="yes,yes,no" />
  <Permission action="tools.configure.db-leads" label="Configure" description="Change scan, phases, qualification, billing, sync." allow="yes,yes,no" />
  <Permission action="db-leads.read.assigned_only" label="Own contacts only" description="Restriction: only contacts you are assigned to." allow="no,no,no" />
  <Permission action="tools.danger.db-leads" label="Reset" description="Discard assessments, findings and pipeline state." allow="no,no,no" />
</PermissionTable>

Everything is granted in the workspace permission matrix under **Settings · Team**. The owner always holds every permission, regardless of the matrix.

## The two nobody has by default

<DefinitionList>
  <DefItem term="Own contacts only">
    A **restriction**, not a grant: whoever holds it sees only contacts they are assigned to. It is deliberately preset nowhere, because a permission that silently takes data away must not switch itself on.
  </DefItem>
  <DefItem term="Reset">
    Owner only, and deliberately not admins: on rollout every existing admin would suddenly hold a permission that can discard a whole tool's working data, without anybody having granted it. Whoever needs it gets it individually.
  </DefItem>
</DefinitionList>

<Warning title="Assignment must be maintained before you restrict">
The **Own contacts only** limit depends on the recorded assignee. If it is empty, the person sees nothing at all. Assignment comes from the onOffice username; how to connect it is described under [onOffice import](/tools/db-leads/onoffice-import).
</Warning>

## Exporting contacts

**Export contacts** is a separate permission and does not hang off reading. Being allowed to look at the list does not mean being allowed to take it away as a file.

The reason is the content: what leaves are names, phone numbers, email addresses and the AI assessment alongside them, which is the complete appraisal of a person your office looks after. Once that file sits on a private machine you cannot pull it back, cannot delete it, and when a subject access request arrives you can no longer say where it ended up.

That is why the permission is off by default for members, and why the system asks before you turn it on. What that confirmation means is described under [roles and permissions](/help/howto/rollen-und-rechte) and in the [terms of use](/legal/terms).

## Sharing other people's contacts

The counterpart to the **Own contacts only** limit: instead of lifting it entirely, you release individual assignments on top of it. How that works, and what a share is not, is described under [shares](/tools/db-leads/freigaben).

The permission deliberately does not sit with everyone who may configure the tool. Whoever maintains the field mapping should not thereby be able to move around who sees whose customer data.

## Permissions in the frontend and the backend

If a permission is missing, the corresponding button disappears. That is convenience, not security: every action is additionally checked on the server. A crafted call without permission is rejected regardless of what the browser shows.

## What the tool records

Every consequential action lands in the workspace audit log: who did what and when, without the contents themselves. That covers scans, syncs, disqualifications, write-back to onOffice, property leads and resets.

## Further reading

<CardGrid>
  <Card title="Settings" href="/tools/db-leads/einstellungen">What sits behind "configure".</Card>
  <Card title="Reset" href="/tools/db-leads/zuruecksetzen">What the most dangerous permission does.</Card>
  <Card title="Shares" href="/tools/db-leads/freigaben">Open the assignment limit one entry at a time.</Card>
  <Card title="onOffice import" href="/tools/db-leads/onoffice-import">Take assignment over from the CRM.</Card>
</CardGrid>