Skip to content

Procesbibliotheek

A procesbibliotheek is a browsable library of the process definitions deployed to the platform: what each one is called, what state it is in, and what else is deployed alongside it. Where a regelcatalogus catalogues rules against the services they implement, a procesbibliotheek catalogues the process definitions themselves.

What a library entry describes

An entry represents one deployed process definition. It carries the process's name, the identifying key it is deployed under, a lifecycle status, and whether it runs standalone or as a subprocess invoked by another. An entry also lists what is deployed alongside that process definition and bound to it: the forms it uses, any document templates it produces, and the decision tables it evaluates — so the entry reflects everything that ships with the process, not the process definition in isolation.

How a definition reaches the library

An entry is not authored separately from the deployment itself. It is derived from a deployment index that tracks every deployed process bundle, so a process definition appears in the library once it has actually been deployed — and disappears from it, or its listed status changes, as that deployment changes. There is no parallel documentation step to keep in sync: the library is a read view onto what is deployed.

What it relates to

Because an entry is derived from the deployment itself, it stays tied to what is actually runnable rather than describing a process definition as it was once designed. A form, document template, or decision key listed against an entry is the one that resolves at runtime — the same binding described in Dynamic Forms and Business Rules Execution — not a separately maintained description of it.

Public and internal exposure

A process definition can be attributed to the surface that owns it, and only definitions owned by a public-facing surface — or carrying no such attribution at all — are exposed on the library's public, read-only view; others stay restricted to internal use. Which surfaces count as public-facing is configuration rather than code, so the public boundary can be widened to another board without changing the implementation.

Ownership is the whole of that decision. A definition's lifecycle status does not gate public visibility, and deliberately so: the status vocabulary describes how far along a deployment is, not whether it may be seen, and treating it as a visibility rule meant a library that showed nothing at all. The status is instead published — an entry carries its status label on the listing and in search results, not only on its own detail page — so a reader sees that a process is an example or still in progress rather than being shown nothing and left to infer it.

Within that public boundary, the library is reachable in more than one place at once — inside an otherwise authenticated working environment, and on a public site with no login — both reading the same underlying data; see Public Publication.