Automatic triggers

A trigger creates requests on a service without anyone entering them: on a schedule, when reading a mailbox, a file, and so on. The request follows the same path as an entered request: the service form is filled in (without being shown), the process starts, and the requester is the System account unless set otherwise.

Triggers are set in the Triggers tab of the service page (menu Administration › Catalog and workflow › Catalog, then the service). The tab appears once the service is saved. It is open to Administrators and Scoop administrators.

The trigger types offered depend on the installed modules.

Service settings

Orderable from the catalog (checked by default): unchecked, the service disappears from the catalog, the search and the guest catalog, and can no longer be ordered directly. Only its triggers then create requests.
Maximum requests per run (100 by default): when a run would produce more requests, it creates none. It is Blocked (cap) and the service owners are alerted. The cap protects against a runaway source. Exception: a mailbox or a due date is a queue that drains over time — the run creates requests up to the cap and leaves the rest to the next run.

Save applies both settings.

Add a trigger

Choose the type in Add a trigger, then Add. The page that opens asks for:

a Name;
Active: a new trigger is inactive by default. Set it up, test it with Preview, then activate it;
the Requester of the created requests: System account, a Designated user, or Given by the source (for example the sender of an email; otherwise, the System account);
the Type settings, specific to each trigger type.

The trigger list

For each trigger, the list shows its name, type, state (Active, Inactive, Run in progress) and Last run. The actions:

Edit;
Activate or Deactivate;
Run now: starts a run right away (active trigger), then opens its log;
Preview (for the types that offer it): shows what a run would receive, without creating anything, and warns if the cap would be exceeded;
Log;
Delete: the trigger and its log are permanently removed.

A type marked Type unavailable comes from a disabled module: the trigger stays saved but no longer does anything.

Timer

The Timer type creates a request at each occurrence of a six-field Schedule (cron): second, minute, hour, day, month, day of week. For example 0 0 8 * * MON: every Monday at 8:00. The time is in the instance time zone, shown under the field.

Each request receives trigger_date (2026-10-12), trigger_time (08:00) and trigger_datetime (2026-10-12T08:00:00+02:00): a form field with that name is filled in, otherwise the value becomes a request variable. Disabling or deleting the trigger disables or deletes its task in the scheduler. An occurrence missed while the application was stopped is not caught up.

When a timer run does not succeed, the history of its task in the Scheduler explains it in your language: items refused (number shown, the task then partly succeeds), run failed, service cap exceeded (number of items shown, no request created), trigger deleted (delete the task). The detail of each item is in the trigger's log.

Scheduled query

The Scheduled query type runs a query from the Queries module on a Schedule (cron) and creates one request per row of the result. Choose the query among those you are allowed to run, then give a fixed value to each of its parameters (@name). The run is performed as the System account.

Each column fills the form field of the same name; otherwise it becomes a request variable. An article.<code> column selects an item. Values come in a neutral format: dates 2026-11-01, ISO 8601 timestamps, numbers with a decimal point (1250.50), booleans true/false. No row: nothing is created. More rows than the cap: the run is blocked and the owners are alerted.

The query must exclude the rows already processed, otherwise every run creates the same requests again. The values of submitted forms can be read from the dynamicforms.v_submitted_field_values view; for example, with a @service parameter set to the service identifier:

SELECT c.code AS contrat, c.ends AS echeance
FROM contracts c
WHERE c.ends < current_date + 30
  AND NOT EXISTS (
      SELECT 1 FROM dynamicforms.v_submitted_field_values v
      WHERE v.catalog_service_id = @service::uuid
        AND v.field_slug = 'contrat'
        AND v.value = c.code)

Before enabling the trigger, open the Preview: it runs the query and shows, without creating anything, the rows that would be processed, what each column becomes (field, item or variable) and whether the request would be accepted.

CSV file

The CSV file type creates one request per row of a file you upload. In the trigger list, click Upload a file, choose the file, then Preview: you see the rows read, what each column becomes (field, item or variable) and whether each request would be accepted. Nothing is created before Create the requests.

The first row holds the column names. Separator ; or ,, UTF-8 encoding (with or without BOM), 5 MB at most; a quoted field may contain the separator or a line break. Each column fills the form field of the same name, otherwise a variable; article.<code> selects an item. More rows than the cap: nothing is created and the owners are alerted.

contrat;echeance;article.badge
C-1001;2026-11-01;1
C-1002;2026-11-15;0

A file previewed but never turned into requests is forgotten after one day. Through the API: POST …/triggers/{id}/csv/preview then POST …/triggers/{id}/csv, with the file in the file field.

Mailbox

The Mailbox type creates one request per email received in a mailbox collected by the Mailboxes module. Choose the mailbox in the list; View its configuration opens its page, Declare a mailbox adds one. In its configuration, the mailbox must use the servicecatalog handler, and a mailbox can feed only one trigger.

Each email fills the fields from, from_name, to, cc, subject, body, body_html, received_at and message_id (otherwise variables); its attachments go to the form's attachment field, images embedded in the text are ignored. Choose the requester Given by the source: the sender becomes the requester if they are a known, active user, otherwise the System account. The cap applies to each collection of the mailbox: beyond it, the oldest emails are handled first, the others at the next collection.

A reply to an email already processed, or an email whose subject contains a request number in brackets (for example [WF-000123]), does not create a request: it is added as a comment to that request, with its attachments, even if it is closed. Only requests created by this trigger qualify: the number of any other request is ignored, and the email creates a new request.

Warning: a sender address is easy to forge. Restrict the mailbox to trusted domains with the inclusion filters of the Mailboxes module. Collection (MailInboxPolling task) is disabled at installation: enable it in the Scheduler.

Event

The Event type creates a request when a product event occurs: a ticket created or moved to a status, a request closed, a CMDB object updated… Choose the event in the list; the values it carries are shown below. Each value fills the field of the same name, otherwise a variable; nested values have dotted names (for example values.cpu).

The optional condition limits the events kept: one rule per line, in the form path operator value, all of which must be true. Operators: =, !=, contient (case and accents ignored), > and < (numbers). Example: eventType = StatusChanged.

The same event never creates two requests. The service cap applies per minute: beyond it, events are ignored and logged, with a single alert. A request that cannot be created is logged, without any effect on the original action.

A trigger that listens to the requests of its own service (their creation, a status change, their closure) does not run forever: as with the Request from another service type, a chain stops at depth 5 (variable chain_depth). The refusal is logged and an alert is sent to the owners. The end of a run of an Event, Threshold crossed or Request from another service trigger is never used as an event.

Threshold crossed

The Threshold crossed type watches a numeric value carried by an event, for example the quantity of a stock item. Choose the event, the monitored value (quantity), the operator (<, <=, >, >=) and the threshold. The monitored item is the path of the value that identifies the item or alert (stockItemId); empty, it is the event subject.

A request is created when the value crosses the threshold for an item, then nothing while it stays on that side: another drop below the minimum does not create a second request. When the value goes back, the trigger re-arms; the next crossing creates a new request. Each item has its own state. An event without a numeric value is ignored.

Request from another service

The Request from another service type chains two services: when a request of the source service reaches one of the given business statuses (their codes, separated by commas), or closes if the box is checked, a request of this service is created. It takes the values of the source request (same name, same field; otherwise a variable), plus source_request_id, source_request_number, source_status and chain_depth.

With the requester Given by the source, the new request keeps the source requester if still active, otherwise the System account. A source request triggers only once for a given status, even if it reaches it again. A chain (A creates B, which creates A…) stops at depth 5: the refusal is logged and an alert goes to the owners.

Due date

The Due date type creates a request some days before, or after, a date: the end of a contract or the warranty end of an asset. Choose the due date, the offset in days (-30 = thirty days before) and the check time (schedule, as for the timer).

Each item gives a single request for a given due date: later checks do not create it again. If the date changes (contract extended), a new request is created in due course for the new date. A missed check day is caught up for seven days. The request receives the item values, plus due_date and days_before. More items than the cap: the nearest due dates first, the others at the next check.

Creating for some of the lines

In the preview of a scheduled query or of a CSV file, each line has a checkbox. Tick the lines you want (or Select all), then click Create for the selection: a request is created for each ticked line, as it appeared in the preview. A line refused by validation cannot be ticked; the reason is shown in the Validation column. The cap applies to the ticked lines. The selection is valid for 15 minutes and can be used once: after that, run a new preview. The log shows a manual run and who started it.

Webhook / API

The Webhook / API type lets a third-party tool (n8n, Zapier, Make, Power Automate, a monitoring tool, a script) create one request per call. Choose the authentication mode and the limit of calls per minute (60 by default), save, then click Generate a new secret. The secret is shown only once: copy it right away. Generating another one makes the old one unusable; after changing the mode, generate a new one.

Bearer token: the tool sends the header Authorization: Bearer <secret> to the address shown.
Secret URL: for a tool that cannot set headers, it calls the address followed by /<secret>.
HMAC signature: for a tool that signs according to Standard Webhooks (headers webhook-id, webhook-timestamp, webhook-signature); a signature older than 5 minutes is refused.

The tool sends JSON or an encoded form (1 MB at most). Each key fills the field of the same name, otherwise a variable; nested JSON gives dotted names, for example ticket.priority or items.0.name. The screen gives curl examples for each mode.

Responses: 202 with the request number, 422 if the data is refused, 401 wrong secret, 404 unknown or disabled trigger, 413 content too large, 429 too many calls. If the tool sends the same Idempotency-Key header (or webhook-id) again within 24 hours, it gets the same response and no second request is created.

An integration that already has an account can call the API POST /api/v1/catalog/triggers/<id>/fire with its token, without a trigger secret.

The log

The log lists the runs, most recent first: Started, Status, items Received, requests Created, items Refused. Choose a run to see its items: the source of each, then the request created or the errors that refused it.

Status	Meaning
Succeeded	Each item produced its request (a run with no item succeeds)
Completed with refusals	At least one item was refused (invalid data); the others produced their request
Failed	Technical error, for example an unreachable source
Blocked (cap)	Too many items: no request created
Skipped (run in progress)	Another run of the same trigger was already running

Runs older than 90 days are deleted every night by the PurgeServiceTriggerRuns scheduled task, which can be disabled in the scheduler.

Alerts

A run blocked by the cap, a refused item or a technical error send a single alert per run to the service owners (the people and the members of the groups set in the General tab), according to each person's notification preferences. The alert links to the run log. A mailbox or a due date that piles up more items than the cap sends a backlog alert, at most once every 24 hours: raise the cap or look for the cause of the influx.

Export and import

An exported service carries its triggers, without their secrets (passwords, tokens) or their designated user. On import, they arrive disabled: the import lists what remains to be re-entered before activating them again.