# Shares

{/* 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>
The **Own contacts only** limit used to be all or nothing. When somebody went on holiday, the only way out was to lift the restriction and open the entire database with it. A **share** is the middle ground: one pair of people, one direction, revocable at any time.
</Lead>

## What you need it for

<DefinitionList>
  <DefItem term="Holiday cover">Anna takes over Bernd's contacts for three weeks. When she is back you revoke the share and everything is as it was.</DefItem>
  <DefItem term="A jointly worked district">Two people work the same region without either of them seeing the rest of the office.</DefItem>
  <DefItem term="Assistant">One person works through the findings of two agents. They get two shares, not the permission to see everything.</DefItem>
</DefinitionList>

## Where it lives

**Settings · Tools · DB-Leads · Shares**. The area requires the **Share other people's contacts** permission, and it requires it for viewing too: the overview answers the question "who sees whose customer data", and that on its own is information about how your office is organised.

<Steps>
  <Step title="Pick the people">
    Two dropdowns at the top: the person who may additionally see, and the person whose contacts become visible. Read it as a sentence: "Anna sees Bernd's contacts."
  </Step>
  <Step title="Add a note">
    Optional, but worth it. A share without a reason cannot be judged six months later, and by then nobody dares remove it. "Cover until end of October" is enough.
  </Step>
  <Step title="Grant it">
    It takes effect immediately, with no need for anybody to sign in again.
  </Step>
</Steps>

Each row is revoked individually via **Revoke**. That takes effect immediately as well.

## What a share is not

<Callout tone="warning">
**Not a substitute for a missing permission.** Somebody who does not hold **Read contacts** at all sees just as little with a share. A share only widens the assignment limit within what the person is allowed to do anyway.
</Callout>

**It is directional.** "Anna sees Bernd's contacts" does not mean Bernd sees Anna's. If the two cover for each other, you need two shares.

**It hangs off the assignment, not off the individual finding.** What is shared is what Bernd looks after, not finding 4711. A finding appears and disappears with every scan; a share tied to one would be a list of dead references within a week. When a contact changes assignee, it moves along with the assignment.

**It survives a change of administration.** If the person who granted the share leaves the office, the share stays. Otherwise the next offboarding would silently cost half a team its access.

## When nobody is restricted

Then a share does nothing, because everybody sees everything anyway. The area says so rather than offering a setting that has no effect. A share only becomes effective once at least one role or person carries the **Own contacts only** restriction.

## What gets recorded

Every share granted and every share revoked lands in the workspace audit log, with both people involved. A share moves who sees whose customer data; whoever reviews that later needs both sides. The note is not in the log, it stays on the row itself.

## Further reading

<CardGrid>
  <Card title="Permissions" href="/tools/db-leads/berechtigungen">Every permission of the tool and its default.</Card>
  <Card title="onOffice import" href="/tools/db-leads/onoffice-import">Where the assignment comes from.</Card>
  <Card title="Roles and permissions" href="/help/howto/rollen-und-rechte">How roles and personal exceptions interact.</Card>
</CardGrid>