Create work from an authorised request
The rebooking journey begins when a service asks Open BPM to create work. The request identifies the business record, required result, responsible role, deadline and the person or system making the request.
The future component should accept or refuse the request explicitly. Retrying the same request must not create a second work item. This property is called idempotency: retrying the same request does not create another copy of its effect.
Offer work before somebody owns it
Open BPM would offer the new item to a scheduling queue. A queue shows eligible people which work is available; it does not mean that one person has accepted responsibility.
When a scheduler claims the item, the component records who accepted it, when and under which role. The scheduler may release it if they cannot continue, so another eligible person can claim it.
Complete, refuse or escalate
When the scheduler completes the item, Open BPM should record the required result, such as the date on which a new appointment was offered. A business refusal is also a result and should not be misreported as a software failure.
If the deadline approaches or the work becomes blocked, an escalation changes who must respond or which action is required. The work history retains the original request, every accepted change and any recovery action.
Keep domain records with their owner
Open BPM manages the state of the work. The appointment service remains responsible for the appointment record itself. Open BPM stores a stable reference and receives only the information needed to organise the work.
That separation lets the work component be replaced without turning it into the authoritative database for every service that uses it.