Subprocesses

Part of Process Knowledge. A subprocess is a subordinate business object that represents, within the business case, a procedure running at the customer, broker, insurer or a third party; it has a lifecycle of its own and can block the submission of the main object.

What a Subprocess Is

During the application process, procedures take place that the broker does not handle at the application: the customer registers the vehicle, an assessor inspects previous damage, a manager of the insurer approves a discount, the customer proves their identity. They run at the customer, broker, insurer or third parties, have a status of their own, can block the application until their result is in, or only reach a result after submission.

A subprocess (Nebenprozess) represents such a procedure within the business case. It is a subordinate business object under a main object – offer, application or contract – of the same business case, with an IRI, a content, a lifecycle and a version of its own like every business object. The model describes only the object – who is the actor, what comes out, whether it blocks submission – not the procedure at the customer, broker or third party. A main object can carry several subprocesses; how many of which kind is declared by the business case type. The tariff inquiry knows no subprocesses: it has no objects.

Characteristics

Beyond the core characteristics of every business object – timestamps, version, state reason, requester, owner and actor, deadline and consequence, history, reference to the declaration, navigation links – a subprocess carries:

Characteristic Meaning

Characteristic	Meaning
Kind (`bc:kind`)	Which procedure is represented, from an open code list. The standard defines six kinds (below); an insurer may declare further ones.
Business identifier	The identifier of the procedure where it runs: assessment order, registration procedure, identification number of the identity service.
Blocking (`bc:blocking`)	Whether the transition "submit" of the main object is admissible only once the subprocess is fulfilled.
Merge (`bc:merge`)	When the result flows into the main object: before submission, after submission, open (the insurer decides per case) or none (the result stays with the subprocess).
Deadline and consequence (`bc:deadline`, `bc:consequence`)	By when the result has to be in and what happens when the deadline passes: application rejected, provisional cover ends, increased deductible remains. Informative at the interface; binding are policy and letters of the insurer.
Affected components	Reference to the components of the configuration whose values depend on the result; there the values are provisional with a reference back to the subprocess.
Document requirements	Which documents the subprocess requires or delivers: certificate, inspection report, registration certificate.
Result (`bc:result`)	Typed per kind: inspection finding, approved discount, registration date. Confidential results – such as the content of a medical certificate – are not returned by the insurer; state, roles and messages remain visible.

Kind (bc:kind)

Which procedure is represented, from an open code list. The standard defines six kinds (below); an insurer may declare further ones.

Business identifier

The identifier of the procedure where it runs: assessment order, registration procedure, identification number of the identity service.

Blocking (bc:blocking)

Whether the transition "submit" of the main object is admissible only once the subprocess is fulfilled.

Merge (bc:merge)

When the result flows into the main object: before submission, after submission, open (the insurer decides per case) or none (the result stays with the subprocess).

Deadline and consequence (bc:deadline, bc:consequence)

By when the result has to be in and what happens when the deadline passes: application rejected, provisional cover ends, increased deductible remains. Informative at the interface; binding are policy and letters of the insurer.

Affected components

Reference to the components of the configuration whose values depend on the result; there the values are provisional with a reference back to the subprocess.

Document requirements

Which documents the subprocess requires or delivers: certificate, inspection report, registration certificate.

Result (bc:result)

Typed per kind: inspection finding, approved discount, registration date. Confidential results – such as the content of a medical certificate – are not returned by the insurer; state, roles and messages remain visible.

Blocking, merge, deadline and consequence are, at the object, copies of the declaration of its kind, so that a client can read them without process knowledge.

Lifecycle

A subprocess follows the pattern of assessed and set states: open and invalid are assessed by the insurer – at every processing of the main object it reassesses whether request and result still hold –, fulfilled, rejected, aborted and expired are set and remain. A repetition after rejection or invalidity is a new object with origin from the old one, not a reopening.

State	Kind	Meaning
Open	assessed	Initial state; the procedure is running, "actor" names who has to act. A blocking open subprocess blocks the transition "submit" of the main object.
Invalid	assessed	A change of the main object has invalidated request or result: the previous damage was removed from the application, the vehicle exchanged, the discount changed. With reason; final state.
Fulfilled	set	The result is in and holds; the insurer has established it. Where the merge provides for it, the provisional values of the main object are replaced.
Rejected	set	The insurer rejects (discount not approved, inspection negative), with reason.
Aborted	set	The requester withdraws the procedure, with reason.
Expired	set	The deadline has passed; the declared consequence takes effect, with reason.

State

Kind

Meaning

Open

assessed

Initial state; the procedure is running, "actor" names who has to act. A blocking open subprocess blocks the transition "submit" of the main object.

Invalid

assessed

A change of the main object has invalidated request or result: the previous damage was removed from the application, the vehicle exchanged, the discount changed. With reason; final state.

Fulfilled

set

The result is in and holds; the insurer has established it. Where the merge provides for it, the provisional values of the main object are replaced.

Rejected

set

The insurer rejects (discount not approved, inspection negative), with reason.

Aborted

set

The requester withdraws the procedure, with reason.

Expired

set

The deadline has passed; the declared consequence takes effect, with reason.

The Six Standardised Kinds

The standard defines six kinds for the application process. Each names in its declaration requester, owner, whether it blocks and when it is merged; the table shows the default case, deviations are declared by the insurer.

Kind	Procedure	Actor	Merge
Discount approval	The broker requests a discount beyond its authority; the insurer approves or rejects it. Until then the premium at the main object is provisional.	insurer	before submission, blocking
Approval reservation / acceptance	The insurer checks acceptance (risk, creditworthiness, sanctions) and decides under reservation; cover is provisional until the decision.	insurer	after submission
Certificate	The customer presents proof from a third party: medical certificate, expert opinion, attestation. The content is confidential; visible is only whether it is in and sufficient.	customer, third party	before or after submission, declared
Previous damage inspection	An assessor inspects the vehicle when the application names previous damage (example below).	third party	three variants, declared
Identification of persons	The customer proves their identity, for instance by video identification at an identity service; mandatory under anti-money-laundering law in certain lines of business.	customer, third party	before submission, blocking
Registration	The customer registers the vehicle with the insurance confirmation; the registration office reports the registration to the insurer. The insurance confirmation remains a business object of its own; the subprocess represents the procedure at the registration office. If the registration was already in at the first call, the insurer reports the subprocess as fulfilled if the kind is declared as "always report".	customer, third party	after submission; carried over to the contract

Kind

Procedure

Actor

Merge

Discount approval

The broker requests a discount beyond its authority; the insurer approves or rejects it. Until then the premium at the main object is provisional.

insurer

before submission, blocking

Approval reservation / acceptance

The insurer checks acceptance (risk, creditworthiness, sanctions) and decides under reservation; cover is provisional until the decision.

insurer

after submission

Certificate

The customer presents proof from a third party: medical certificate, expert opinion, attestation. The content is confidential; visible is only whether it is in and sufficient.

customer, third party

before or after submission, declared

Previous damage inspection

An assessor inspects the vehicle when the application names previous damage (example below).

third party

three variants, declared

Identification of persons

The customer proves their identity, for instance by video identification at an identity service; mandatory under anti-money-laundering law in certain lines of business.

customer, third party

before submission, blocking

Registration

The customer registers the vehicle with the insurance confirmation; the registration office reports the registration to the insurer. The insurance confirmation remains a business object of its own; the subprocess represents the procedure at the registration office. If the registration was already in at the first call, the insurer reports the subprocess as fulfilled if the kind is declared as "always report".

customer, third party

after submission; carried over to the contract

Operations

Subprocesses need no operations of their own: everything is one of the six operation kinds with the same four checks.

Operation	Kind	Description
Request by the insurer	addition during processing (no call of its own)	At an edit, replacement or transition of the main object the insurer determines that a kind is due (trigger condition met or decision per case) and sets up the subprocess. The response carries it under the main object, with "actor", deadline and – if blocking – without the transition "submit" among the next steps.
Request by the broker	creation or derivation from the main object	The broker sets up the subprocess, for instance the discount approval with the requested discount. Admissible only if the declaration provides the kind for the broker; conforming if the content matches the shape of the kind.
Read subprocess	inquiry	State, roles, deadline, affected components and result, as far as not confidential.
Submit result	edit	Whoever is the actor transmits result or document: inspection report, registration notification, approved discount. Admissible only in state open and with the presupposed version; conforming against the shape of the result. The insurer then establishes whether the subprocess is fulfilled and replaces provisional values of the main object.
Abort	transition	Only in state open, by the requester, with reason. A blocking subprocess no longer blocks afterwards; whether the insurer requests it anew is decided by the trigger condition at the next processing.
Fetch state changes	inquiry	The events of all objects of the business case since a point in time, including the subordinate ones: "subprocess fulfilled", "subprocess expired".
Merge after submission	derivation (insurer)	When a subprocess under the contract delivers its result, the insurer derives from it the contract change application of a contract change. The contract change application carries the subprocess as origin; for this the origin may point across the boundary of the business case.

Operation

Kind

Description

Request by the insurer

addition during processing (no call of its own)

At an edit, replacement or transition of the main object the insurer determines that a kind is due (trigger condition met or decision per case) and sets up the subprocess. The response carries it under the main object, with "actor", deadline and – if blocking – without the transition "submit" among the next steps.

Request by the broker

creation or derivation from the main object

The broker sets up the subprocess, for instance the discount approval with the requested discount. Admissible only if the declaration provides the kind for the broker; conforming if the content matches the shape of the kind.

Read subprocess

inquiry

State, roles, deadline, affected components and result, as far as not confidential.

Submit result

edit

Whoever is the actor transmits result or document: inspection report, registration notification, approved discount. Admissible only in state open and with the presupposed version; conforming against the shape of the result. The insurer then establishes whether the subprocess is fulfilled and replaces provisional values of the main object.

Abort

transition

Only in state open, by the requester, with reason. A blocking subprocess no longer blocks afterwards; whether the insurer requests it anew is decided by the trigger condition at the next processing.

Fetch state changes

inquiry

The events of all objects of the business case since a point in time, including the subordinate ones: "subprocess fulfilled", "subprocess expired".

Merge after submission

derivation (insurer)

When a subprocess under the contract delivers its result, the insurer derives from it the contract change application of a contract change. The contract change application carries the subprocess as origin; for this the origin may point across the boundary of the business case.

An edit or transition of the main object that a blocking subprocess blocks fails the admissibility or completeness check with HTTP 409; the error response names the blocking objects with their state (Checks and Responsibilities). There is no "gate" element of its own: the block is in the next steps and in the report.

Declaration in the Process Knowledge

Which subprocesses exist and how they behave is declared by the process knowledge per business case type and insurer in groups (pk:):

Kinds (pk:subprocessKind): which kinds may occur under which main object.
Selection (pk:selection): all kinds of the group, exactly one or any – for instance exactly one of the variants of the previous damage inspection.
Requirement (pk:requirement): must, should or may.
Order (pk:relation): before submission, after submission or after another subprocess.
Trigger condition (pk:condition): a SHACL shape over the main object; when it matches, the insurer requests the subprocess – "previous damage = yes", "discount above the threshold", "sum insured above the limit". Without a condition the insurer decides per case. With the condition a client can anticipate the request and point the customer to it early; binding remains the request of the insurer.
Requester and owner per kind, plus deadline and consequence and blocking.
Carry-over at derivation (pk:carryOver): whether open and fulfilled subprocesses move with the derivation application → contract to the new main object (registration: yes) or stay with the predecessor (discount approval: no, because absorbed into the contract). The default is "yes".
Always report: whether the insurer reports a subprocess even when it is already fulfilled, so that the client evaluates uniformly.

Every subprocess points with bc:declaredBy to the declaration of its kind; thus a client finds selection, requirement, deadlines and trigger condition without searching. The declaration is part of the process knowledge an insurer delivers at runtime.

Example: Previous Damage Inspection

An application names previous damage to the vehicle. The declaration of the kind "previous damage inspection" provides three variants, of which an insurer declares exactly one (pk:selection exactly-one) or leaves the choice to the customer:

	Variant 1: before submission	Variant 2: after submission	Variant 3: choice by the customer
Trigger condition	shape "component casco included and previous damage = yes" over the application
Coming into being	addition by the insurer at the first processing of the application that meets the condition
Blocking	yes: "submit" is missing from the next steps until the subprocess is fulfilled	no: the application is submittable; the inspection runs after submission	the customer chooses between the two; the choice is an edit at the subprocess
Provisional values	none	the deductible of the casco is increased and marked provisional, with reference to the subprocess	depending on the choice
Merge	before submission: with "fulfilled" the application is submittable without restriction	after submission: the subprocess is carried over to the contract; with "fulfilled" the insurer derives a contract change application that resets the deductible	depending on the choice
Deadline and consequence	no deadline; the application remains a draft	30 days after policy issue; on expiry the increased deductible remains	depending on the choice
Actor	third party (assessor) until the result is submitted; then insurer	third party, then insurer	first customer (choice), then as chosen

Variant 1: before submission

Variant 2: after submission

Variant 3: choice by the customer

Trigger condition

shape "component casco included and previous damage = yes" over the application

Coming into being

addition by the insurer at the first processing of the application that meets the condition

Blocking

yes: "submit" is missing from the next steps until the subprocess is fulfilled

no: the application is submittable; the inspection runs after submission

the customer chooses between the two; the choice is an edit at the subprocess

Provisional values

none

the deductible of the casco is increased and marked provisional, with reference to the subprocess

depending on the choice

Merge

before submission: with "fulfilled" the application is submittable without restriction

after submission: the subprocess is carried over to the contract; with "fulfilled" the insurer derives a contract change application that resets the deductible

depending on the choice

Deadline and consequence

no deadline; the application remains a draft

30 days after policy issue; on expiry the increased deductible remains

depending on the choice

Actor

third party (assessor) until the result is submitted; then insurer

third party, then insurer

first customer (choice), then as chosen

In all three variants a client reads the same set of characteristics at the subprocess and the same next steps at the application; it needs no logic of its own per variant.

Mapping to OMDS 3

OMDS 3 describes subprocesses with the same characteristics – identifier, business identifier, kind, status, blocking, actor, merge, deadline, consequence on expiry, affected component – and with the operations "read subprocess" and "submit result". Two things differ in the model:

The subprocess hangs at the main object (offer, application, contract), not at the business case. This makes clear which version of the application a result refers to: when the application is edited or replaced, the insurer reassesses the subprocesses of this object; a version reference of its own is unnecessary. A subprocess that outlasts submission is carried over with the derivation application → contract.
The block ("gate") is in the next steps and in the report, not in an element of its own in the response: the transition "submit" is missing as long as a blocking subprocess is not fulfilled, and a call nevertheless fails the admissibility check with the blocking objects in the error response. A client need not compute the gate itself.

A wrapper maps the OMDS 3 operations to inquiry and edit as the table above shows; the OMDS 3 error codes become the responses of the admissibility (409) and conformity check (422).

State of the Implementation

Not implemented. Subprocesses follow with the switch of the reference implementations to business objects with states of their own, first in the application process with discount approval and previous damage inspection (Approach and Artefacts).