> For the complete documentation index, see [llms.txt](https://mango-5m.gitbook.io/mango5m-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mango-5m.gitbook.io/mango5m-docs/resources/mango-dispatch/configuration/recipients-and-units.md).

# Recipients and Units

Who receives alerts and can respond - by job, by registration from another resource, or both.

A player is a **unit** when the server says so. Units receive alert cards, can open the quick call window, and can respond to calls. Everyone else is a civilian as far as this resource is concerned - their keybinds do nothing.

```lua
Config.Recipients = {
    mode = 'both',
    jobs = { 'police', 'sheriff', 'ambulance' },
    requireOnDuty = false,
}
```

### The two ways in

<table data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>By job</strong></td><td>Their framework job name appears in <code>Config.Recipients.jobs</code>. Nothing else to set up.</td></tr><tr><td><strong>By registration</strong></td><td>Another resource called <code>RegisterUnit</code> for them - a duty system, a phone, or your own roster script.</td></tr></tbody></table>

### `mode`

| Value          | Who is a unit                                                    |
| -------------- | ---------------------------------------------------------------- |
| `'job'`        | Only players whose job is in the list. Registrations are ignored |
| `'registered'` | Only players another resource registered. Jobs are ignored       |
| `'both'`       | **Default.** Either route qualifies                              |

`'both'` covers the common case: job-listed officers always hear calls, and anything you register on top also hears them. Use `'registered'` if you want your own duty system to be the single source of truth for who is on the air.

{% hint style="info" %}
An unrecognised value falls back to `'both'` rather than locking everyone out.
{% endhint %}

### `jobs`

Framework **job names**, not labels:

```lua
jobs = { 'police', 'sheriff', 'ambulance', 'doj' },
```

Leave it empty (`{}`) and the job route is disabled entirely, which is equivalent to running in `'registered'` mode.

### `requireOnDuty`

When `true`, a player whose job reports `onDuty = false` is not a unit.

{% tabs %}
{% tab title="ESX" %}
ESX has no core duty flag. The bridge treats everyone as on duty **unless** a duty-managing resource has written `job.onDuty = false` onto the player's job table. If nothing on your server writes that field, `requireOnDuty` has no effect.
{% endtab %}

{% tab title="QBCore / Qbox" %}
Both read `job.onduty`, which their duty systems maintain. Setting `requireOnDuty = true` works out of the box.
{% endtab %}

{% tab title="Custom" %}
Return `onDuty` from `GetJob` in your bridge file. See [Framework and Bridges](/mango5m-docs/resources/mango-dispatch/configuration/framework-and-bridges.md).
{% endtab %}
{% endtabs %}

### How often it is re-checked

Jobs are cached for **5 seconds** on the server, and each client re-asks the server for its own unit state **every 30 seconds**, on spawn, and when the resource starts. So a player who goes on duty starts receiving alerts within about half a minute without any framework-specific hook.

Registration is instant in both directions: `RegisterUnit` and `UnregisterUnit` push the new state to that player immediately.

### What the player sees when they stop being a unit

Their alert stack and call window are cleared straight away. If they were responding to a call, the response itself stays on the server until it is cancelled or the call is cleared - going off duty does not silently drop you off a call.

### Registering units yourself

```lua
exports['mango_dispatch']:RegisterUnit(source, {
    name = 'Officer Reyes',
    deptName = 'LSPD',
    deptColor = '#3b82f6',
    tag = '1-ADAM-12',
})
```

Full field list and lifecycle on [Registering Units](/mango5m-docs/resources/mango-dispatch/developer-guide/registering-units.md).