# Service

> Dispatch, maintenance plans, assets, cases, inventory and SLAs for field work.

Source: https://bettersupabase.com/docs/blocks/service

Covers a service team: work orders on a dispatch board at customer assets, planned maintenance, cases, parts from stock and response targets. The `field-service` preset lists it.

```bash
better-supabase add service
```

```ts title="better-supabase.config.ts"
export default defineConfig({ blocks: { service: {} } });
```

`add` lists `service` in `blocks`, writes the modules of every part and wires the client in `lib/blocks.ts`. Import the manifest from `better-supabase/blocks/service` when you build the set with [`createBlocks`](/docs/blocks/create-blocks).

```ts
import { serviceBlock } from "better-supabase/blocks/service";
```

## Parts [#parts]

Installing `service` installs these blocks. Each stays an ordinary block in the config and keeps its own client.

- [`dispatch`](/docs/blocks/dispatch)
- [`maintenance`](/docs/blocks/maintenance)
- [`assets`](/docs/blocks/assets)
- [`cases`](/docs/blocks/cases)
- [`inventory`](/docs/blocks/inventory)
- [`sla`](/docs/blocks/sla)

## Helpers [#helpers]

`completeVisit`: Record the parts used and the meter readings, then mark the work order done. The work order stays open when a part or reading fails, so call it again with the remaining items.

```ts
await blocks.service.completeVisit({
  workOrderId,
  parts: [{ name: "Filter", quantity: 1 }],
  readings: [{ meterId, value: 1280 }],
});
```

The helper returns a `Result`; each step is idempotent, so retrying after a partial failure is safe.

## Remove [#remove]

```bash
better-supabase remove service
better-supabase remove service --with-parts
```

The first command replaces `service` in `blocks` with its parts. The second removes the parts too, except any part another block still needs ([`remove`](/docs/cli/init#remove)).