Signal definitions

Signal definitions let you manage the rules behind the signals that appear as soft warnings in the right place throughout Scrivio — for example "client is missing contact details" or "appointment not yet billed". A signal definition determines which kind of record is watched, under which conditions a signal is raised, and which message the user then sees. This screen is intended for organisation administrators.

Overview

Route	/organization/signals
Audience	Organisation administrator
Required permission	signal_definitions.manage

The signal definitions are shown in a table with the following columns:

Column	Meaning
Name	Name of the signal, with a short description underneath.
Type	The kind of record the signal watches (see the table below).
Active signals	Number of times this definition currently raises an active signal.
Status	Switch to enable or disable the definition.

Next to the name a badge indicates whether it is a System definition (supplied by default) or a Custom definition (created yourself). System definitions can be enabled and disabled, but not deleted.

Signal types

The type determines which kind of record a signal watches. When creating a definition you choose from:

Type	Watches
Client	A client's details.
Appointment	An appointment.
Appointment fact	A completed appointment (for billing signals).
Care trajectory	A client's care trajectory.
Document	A document.
Form	A form submission.
Contract	A contract.

How it works

A signal definition is a rule that Scrivio continuously checks against your data. When the rule holds for a particular record, an active signal is raised and appears as a soft warning in the right place in the app. When the cause disappears (the rule no longer holds), the signal resolves itself. The points below explain how that checking works and why the screen behaves the way it does.

Conditions decide when a signal is raised

The conditions are the heart of a definition: a set of comparisons on the fields of the chosen type. A signal is raised as soon as a record meets all the conditions. You build them with the condition builder; each condition consists of a field, an operator and (usually) a value.

Operator	Meaning	Example
equals	Field has exactly this value.	status equals ACTIVE
does not equal	Field has a different value.	status does not equal ARCHIVED
is empty	Field is not filled in.	phone is empty
is not empty	Field is filled in.	bsn is not empty
greater than / less than	Numeric or date comparison.	days_since_appointment greater than 14

A worked rule — "client is missing contact details" on the Client type:

email is empty and phone is empty

As long as a client is missing both email and phone, the signal stays active. Once either is filled in, the client no longer meets the rule and the signal disappears. The message template decides the text shown with it; use {client.name} to insert dynamic values from the record.

When checking happens

Scrivio checks the rules at two moments:

• Immediately (event-driven): as soon as something about a record changes — for example a client is updated or an appointment is completed — Scrivio re-checks the relevant definitions straight away. Signals therefore appear or disappear almost instantly.
• Safety sync (every 15 minutes): a background task periodically walks through all definitions, as a safety net for changes that don't trigger an immediate check. So it can take up to about 15 minutes before a signal that arises outside the direct paths becomes visible.

Who sees a signal

A definition has no separate "who sees this" setting. The audience is derived from three things together:

• the type (what the signal is attached to, the so-called root entity);
• the role and permissions of the user;
• the relationships between entities (for example: does the client belong to the user's treatment team).

As a result, a professional sees client signals for their own clients, while billing signals reach the right administrative role — without you having to set that per definition.

Why a definition is fixed once created

Name, type, message template and conditions can no longer be changed after creation (see Edit signal). The reason: active signals are continuously derived from the definition. If you changed the rule along the way, existing signals would no longer match the conditions under which they were raised, and the Active signals count would become unreliable. If you want something different, delete a custom definition and create a new one. Enabling and disabling is allowed, because that doesn't change the rule itself.

Appointment versus Appointment fact

Two types look alike but operate at a different level:

• Appointment watches an appointment itself (planned, rescheduled, cancelled) — useful for signals around scheduling.
• Appointment fact watches a completed appointment at the billing level. Each completed appointment produces a fact that can be billed separately, so billing signals ("appointment not yet billed") attach to the appointment fact, not the appointment. That way a signal stays tied to exactly that billable fact, even when one appointment produces several facts.

Create signal

1. Click + New signal in the top right.
2. Fill in the fields in the dialog.
3. Click Create.

Field	Required	Description
Name	Yes	Name of the signal, for example "Client is missing contact details".
Description	No	Optional explanation of the signal.
Type	Yes	The kind of record the signal watches (see Signal types).
Message template	Yes	The text the user sees with the signal. Use {entity.field} for dynamic values, for example {client.name}.
Conditions	Yes	The conditions under which the signal is raised.

You build the conditions with the condition builder. Choose a type first; you can then set conditions on the fields of that type. The builder shows a preview and indicates whether the conditions are valid. You can only create the signal once name, type, message template and valid conditions are filled in.

Enable or disable

Use the switch in the Status column to turn a signal on or off. A disabled definition no longer raises new signals. The change is saved immediately. This works for both system and custom definitions.

View details

Click a row to open the detail dialog. Here you see all the settings of the signal definition:

• The status (Active or Inactive).
• The description (if filled in).
• The type and the number of active signals.
• The message template.
• The rule expression — the underlying conditions in technical form.

The detail dialog is read-only; close it with Close.

Edit signal

An existing signal definition cannot be edited in terms of content. From the detail dialog you can review the settings, but name, type, message template and conditions are fixed once the definition has been created.

What you can change:

• Enable or disable the definition with the status switch.
• Delete a custom definition and create it again with different settings.

Delete signal

Only custom definitions can be deleted; system definitions cannot.

1. Click the delete button (×) at the end of the row of a custom definition.
2. Confirm in the dialog by clicking Delete.

Note: deleting cannot be undone. If the definition has active signals, that number is shown in the dialog; those signals are removed along with it.

Sort

Click a column header to sort the signals by that column. Click the same header again to switch between ascending and descending. You can sort by Name, Type and Active signals. By default the signals are sorted by name in ascending order.