Built-in Services

Most services are external processes you register and implement yourself. A few ship with Requence: they are part of the product, they are maintained with it, and you do not implement them.

You use them exactly like your own services — drag a service node onto the canvas and pick the version. Requence Lookup appears in the picker in every scope, because it lives at the system level and inherits downward like any shared definition; the others appear wherever they were added.

Service	Version	What it does
Requence Lookup	one per resource, plus count	Queries Requence itself — the tasks, templates, schemas, services, and automations you can see in the UI
User Interaction	ask	Asks a person a question on the node, waits indefinitely, and continues with their answer
	inject	Gives a person a button on the node; every press emits a message, and the node keeps waiting for the next one

A service’s versions are where the behaviour lives, which is why the table lists them separately: ask and inject are two quite different nodes that happen to share one service, and picking the wrong one gets you a node that never finishes or a question nobody can answer twice.

What “built-in” changes

Requence Lookup carries an Internal badge and is view-only: you can open it to read its versions and their input and output schemas, but you cannot edit, move, or delete it, and it has no credentials to copy — Requence connects it itself. New versions arrive with Requence.

User Interaction ships with Requence but is an ordinary external service: it is added once, with its versions, through the normal service UI, and then behaves like any service you wrote yourself.

Everything else behaves normally. They are ordinary service nodes in the graph: they can fail, they can be retried, their outputs are typed, and downstream nodes consume them like any other.