Rules
On this page
A rule says when something happens to a visit, for which visits and what Talemo writes to the client. It has three parts:
- When (
event): some hours before the visit starts (1 to 72), or something happens to the visit — it is booked, moved or cancelled. - For which visits (
conditions): only visits of chosen services, service groups or masters, at most 50 of each. Nothing chosen means any visit; when several lists are chosen, a visit must fit all of them. - What (
action): write to the client one of three messages that go with the event. The confirmation goes with "booked" and "moved", the reminder with "hours before the visit", the cancellation notice with "cancelled". The words are those of the message template, a rule has none of its own (see Channel window and WhatsApp templates).
Rules belong to a branch. talemo_list_rules lists them, and talemo_get_rule shows one. Each has
created_by_name, the name of the person who made it; it is left out for a built-in rule, when the
person is gone, or when they have no name. In the app the assistant shows them as the cards "Rules"
(rules, a branch) and "Rule" (rule, one rule with its history); in the web they are the card
"Clients" on the page "Booking rules".
Built-in and added in words
The three notices of a visit — confirmation, reminder, cancellation — are the built-in rules of
every branch (see Visit notices). They work as they always did, and the booking
rules of the branch (confirm_on_booking, remind_before_hours) are the same settings: a change
in one is a change in the other (see Booking rules). Built-in rules change
less than the others: the confirmation can only be turned on or off, the reminder only gets other
hours, the cancellation notice cannot be changed, and none of them has conditions. Such a change is
refused with status 400, code request.body_invalid and params.field enabled, event or
conditions.
The others are added with talemo_create_rule, for example "remind about a manicure 2 hours before
the visit": event {"on": "before_start", "hours": 2}, conditions {"services": [<service_id>]}
and action {"do": "write_to_client", "message": "visit_reminder"}. The rule works at once. One
with before_start also takes the visits already booked whose hour has not come; one with visit
acts on what happens from then on. talemo_update_rule turns a rule on or off and changes its
time (event) and conditions, which replace the old ones whole. A new time moves the firings that
wait for their hour. Rules are not deleted: a rule that is not needed is turned off, and what it
did stays in the visits and in its list of firings.
A message that does not go with the event is refused with status 400, code request.body_invalid
and params.field action; hours out of range, an empty list of what happens to the visit or a
word named twice — with event; a list of more than 50 or a number named twice —
with conditions.services, conditions.groups or conditions.masters. A service, group or master
of another branch is refused with status 422, code record.reference_missing and the same
params.field. A rule of the whole business is changed only by a role of the whole business; for
any other role it is refused with status 403 and code role.forbidden. These refusals are
legitimate answers, not failures.
What a rule would do
A rule writes to clients by itself, so before it starts, talemo_create_rule and talemo_update_rule
with dry_run show it with its forecast and change nothing. talemo_get_rule shows the
forecast of a rule that is already there. It has two windows: ahead — the next 14 days — and
past — the last 30 days, as if the rule had stood then. In each:
firings— how many visits the rule fires on;clients— how many clients;sends— how many messages would go;by_template— how many of them would go as a WhatsApp template, outside the 24-hour window. Meta charges the business for these by its own rates, by country and category; the forecast counts the messages and does not count the sum, and the rates are in Meta's price list for WhatsApp Business;skipped— why the rest would not go, a reason and a count: for exampleno_confirmed_contact,window_closed,template_not_approved,daily_limit.
A rule with visit has nothing ahead to count: what happens to visits is not known in advance, and
the forecast ahead is empty; the last 30 days show what the rule would have done. Whether a message
would go is decided by the same rules as for a real one: the contact of the client, the window of
the channel, the approved template, the limit of the day.
Three messages in a day
All rules together write to one client at most three automatic messages in any 24 hours. The
fourth is not sent and is skipped with daily_limit. The cancellation notice is not counted and is
never held back by this limit; replies of people in the chat and the word "stop" do not count
either.
Whose rights, and pause
A rule runs with the rights of the person who made it, as if they had written the message
themselves. When that person leaves the business, or no longer has the right to change the
booking rules of the branch, the rule pauses (state paused, pause.reason
creator_left or creator_lost_right) and writes to nobody. It also pauses (failures) when its last
three sends did not go because of the rule itself: the channel is disconnected, the WhatsApp template
is refused, or the business has no payment method in WhatsApp. A failure of Meta or of Talemo, or one
that belongs to a single client (a number that cannot be reached, a closed window), is not counted, and
it does not break the three either. A paused rule is not lost: someone who may change the branch turns it on or
off with talemo_update_rule; the pause goes, and the person who did it becomes the one whose
rights the rule runs with. The count of three sends starts again from turning the rule on (and from
any change of the rule): old failures do not pause it again. Until then a case "rule paused" waits for everyone who may change the
branch of the rule (see Kinds of items in Waiting for you); it goes away
by itself when the rule is turned on or off.
Talemo can also switch the rules made in words off in a business for now, for example after a problem
(feature.off, params.feature rules_in_words). Then talemo_create_rule is refused and is not in the
list of tools, the rules made in words that are on show as paused with pause.reason feature_off
and write to nobody, and there is nothing to turn back on: they work again by themselves when Talemo
switches the rules back on. The three built-in notices of a visit work as usual.
A rule that is on, but whose WhatsApp has no approved template of its message, has state
waits_template: inside the 24-hour window the message goes as text, outside it does not go until
Meta approves the template.
What a rule did
talemo_list_rule_firings lists the firings of a rule, the newest first (limit 1 to 200, 50 when
left out). Each is one notice on one visit: kind (confirmation, reminder or cancellation) and
state: planned waits for its hour (due_at), sent went to the queue of the channel,
skipped did not go, cancelled was withdrawn because the visit was cancelled, done or moved.
reason says why one did not go (see Visit notices for the reasons of the
channel), and these are added by rules: daily_limit, with limit — how many messages a day a
client gets —, has_later_visit, when the rule writes only to a client with no later visit, and
rule_paused. party_name is the name on the card of the client. A sent one says how: channel,
via (text or a WhatsApp template) and delivery (queued, sent, delivered, read or
failed, with the code of the refusal). A waiting one that will not go by what Talemo knows now
has expected_skip, the reason. activity of a rule counts the firings that wait now and those
sent and skipped in the last 30 days.