---
title: Resources — masters, places, devices
summary: A resource is whatever time is booked on in a branch. There are three kinds — master, place and device — and they come with the Client booking kit.
tools: [talemo_list_resources, talemo_create_resource, talemo_update_resource, talemo_deactivate_resource, talemo_activate_resource, talemo_delete_resource, talemo_get_resource_history, talemo_list_visits]
related: [resource-schedule, who-does-what, services-and-prices, visits, ../kits/industry-kits]
search: [staff, master, chair, room, equipment, specialist]
---

# Resources

A resource is whatever time is booked on: a person who does the work, the
place where it is done, a machine it needs. A resource belongs to one branch and
cannot be moved to another. A visit takes one or more resources at once (see
[Visits](visits.md)).

## Master, place, device

All three come from the industry kit (see [Industry kits](../kits/industry-kits.md)).

- **Master** — a person who does the service. It can be linked to someone from
  the team, and only a master can.
- **Place** — a chair, table, couch or room. A place without a schedule changes nothing for
  the services: they take places only once a place of the branch has a schedule, and then
  all the services of the branch take a place at once (see
  [Services, prices and currency](services-and-prices.md)). A place added to the
  branch gets its schedule set in the same breath, or clients cannot be booked on it.
- **Device** — a machine or a piece of equipment, for example a lamp.

The names follow the industry of the business: a wellness business says
specialist, room and equipment, a fitness one trainer, studio and machine, a
tattoo one artist, station and equipment, a tutoring one teacher, room and
instrument. They work the same everywhere.

## Master as a resource and Master as a role

These are different things. A master resource is a bookable person in a
branch's calendar. A role is a named set of rights given to a person of the
team, and it can be named Master too. A role can be limited to own visits: it
then sees visits where the resource the person works as is busy. That link is
the field **Who from the team**. An invitation sets it too, when it names a calendar:
a new master is made together with the invitation, and when the person accepts it,
they are linked to the master on their own (see
[Invitations to the team](../account/invitations.md)).

## Fields and where

The resources of the open branch live in the section **Masters, places and
devices** of the left panel (its name follows the industry; the section is there
while the Client booking kit is installed). The list is split into masters, places and devices, and each
resource shows when it works today, what it does and when it is free next;
the deactivated ones are in a separate **Deactivated** card. A resource has a
**Name**, who it is — a master, a place or a device — and, for a master only, **Who from the team**. Time is
booked only on resources added here. One person works as one master in a branch
at a time: a second resource for the same person is refused while the first is
in work. Changing who a resource is — a master, a place or a device — takes away what it did
before; mark what it does on the card of the resource, in the window **What
services it does** (see [Who does what](who-does-what.md)).

## The card of a resource

Press a resource in the list to open its card: how today and the week go, the
usual schedule and up to which day it can be booked, how many of the services
that need such a master, place or device it does, the next visit and a note. Below is a feed: the
visits of the resource and the edits of the resource itself, each edit with who
made it and when; the schedule edits are seen only by someone who may see schedules.
From the card the name, who it is and the team member are changed, and
so are the schedule and the services; the resource is also deactivated or
deleted there. The note is for your own people, for example “Left-handed — the
table by the window”: whoever sees the resource sees it, and it is signed with
the person who wrote it.

## Deactivating

A resource with visits ahead is not deactivated: those visits are moved to
another resource or cancelled first. The check lists them before anything
changes (`dry_run` in the tool). After deactivating:

- its schedule ahead is removed, the usual cycle stays;
- no new time can be booked on it;
- past visits and the history stay.

**Activate** brings it back to work; lay its schedule out again (see
[Schedule of a resource](resource-schedule.md)). A master cannot be activated
while the same person works as another resource of the branch.

## Deleting

Only a resource on which time was never booked can be deleted. Anything with
history is deactivated instead, and its visits keep their master or place.

## Who can do it

Viewing and changing resources are rights at branch level: the Administrator role
changes, the Accountant role only views. Without the Client booking kit these
operations are unavailable.

## Tools and refusals

- `talemo_list_resources` lists the resources in work of a business or one branch; with `deactivated` it lists the deactivated ones instead. Each has a `role` — `master`, `place` or `device`, the same in every business — and, for a master, the team member it is. Name masters, places and devices to the person as the industry of the business does (`vertical` in `talemo_list_businesses`).
- `talemo_create_resource` takes `branch_id`, `name`, `role` and, for a master only, `user_id` of the team member. One person is one resource in work in a branch: a second one is refused with status 409, code `record.duplicate`.
- `talemo_update_resource` changes the name, `role`, team member or note; what is left out stays, and an empty `note` removes the note. The note is signed with the person who wrote it and the time. A deactivated resource is not changed until it is activated: status 409, code `resource.deactivated`. After a change of `role` mark again what the resource does with `talemo_add_service_fit`.
- `talemo_deactivate_resource` takes a resource out of work. Its schedule ahead goes (only laying the usual cycle out again brings it back, and days changed by hand are lost) and no time after that can be booked on it: `resource.deactivated`. A resource with bookings ahead is refused with status 409, code `resource.has_bookings` and `params.count`: move or cancel those visits first. The tool changes a lot at once, so call it with `dry_run` first: the answer lists the bookings ahead and `days_ahead`, the days of the schedule that would go. Make the real call only after the person has seen it and said yes.
- `talemo_activate_resource` puts it back to work and lays nothing out. If the team member already works as another resource of the branch, it is refused with status 409, code `record.duplicate` and `params.field` `user_id`.
- `talemo_get_resource_history` shows what happened with a resource, newest first, a page at a time: its visits that took place or were cancelled, and the edits of the resource itself — added, changed, deactivated, activated, the usual cycle set, laid out up to a date, a day or a piece of time changed, a service marked or unmarked — each with who did it (a person, the Talemo assistant at their request, a program) and when. An edit holds only ids, codes and numbers: never the text of a note, and a service is named as it is named now. `visits_done` counts the visits that took place, `edits_count` the edits; `next` is the `before` of the following call, and without it that is all; `only` is `visits` or `edits`. Visits show only to a role that may see visits, and schedule edits only to a role that may see schedules; a role limited to own sees the visits and the schedule edits of its own resource only.
- What is ahead of a resource is `talemo_list_visits` with `resource_id`, `from` and `live`: the booked and confirmed visits from that moment on.
- `talemo_delete_resource` deletes only a resource on which time was never booked. One with bookings, past or ahead, is refused with status 409, code `resource.has_history` and `params.count`: deactivate it instead. A deleted resource is gone, and a second call is `not_found`. Ask the person before deleting; `dry_run` says how many bookings it has had.

These refusals are answers, not failures: tell the person what stands in the way and change the plan.