# ProcessHistoryEntry
## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**element_id** | **String** | |
**transition** | **String** | |
**via_flow** | Option<**String**> | The incoming sequence flow the token arrived at this element by (#1613). Not keyed to the transition kind (#1627): the engine snapshots the token's arrival flow once per visit and stamps it on whichever record that visit produces -- `entered`, `completed` or `failed` alike. Absent only where there is no arrival flow to name: a token freshly created at a start event, a multi-instance body token, and the records written on the async job-resume path. This is what makes per-edge run state a fact rather than an inference. From element state alone a traversal is only derivable as \"source completed AND target now active\", which cannot express a parallel join mid-execution (the branch that already delivered reads idle) or a re-traversed loop-back (indistinguishable from a single pass). The engine records an `entered` on a converging gateway for every arrival, satisfying or not, so each delivered branch is named here by its own flow id; and a loop-back is two `entered` records with the same `via_flow` and different `at`. | [optional]
**note** | Option<**String**> | why this transition is not what it looks like. Set only by a `noop` delegate binding today (#923): the activity reports `completed` without having run anything, and this carries the binding's mandatory reason. | [optional]
**at** | **String** | |
[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)