Case notion

Which object type this log is projected onto. It decides what a case is, and therefore every figure on every screen that counts by case.

Now

purchase_order

1,598 cases

Events in a case

57.3%

8,404 of 14,671

Object types

any of them can be the case

Every object type, measured coverage and repetition together - neither answers on its own

Object type	Cases	Events in a case	Coverage	Distinct paths	Cases on a repeated path
goods receipt	1,941	9,090	62.0%	73	1,921 (99.0%)
purchase_order current	1,598	8,404	57.3%	35	1,588 (99.4%)
invoice receipt	927	5,048	34.4%	41	920 (99.2%)
quotation	927	4,123	28.1%	18	922 (99.5%)
purchase_requisition	927	2,385	16.3%	3	927 (100.0%)
material	729	1,458	9.9%	2	729 (100.0%)
payment	927	1,166	7.9%	5	926 (99.9%)

Ordered by coverage, which is an ORDER and not a ranking. Read the two right-hand columns together: a type where nearly every case takes its own path has no process structure to analyse, however much of the log it covers. Changing the notion rebuilds the log from its source and takes as long as loading it did; the previous version keeps serving until the new one is whole - which includes every enrichment layer being recomputed against it, so a layer that fails on the new projection leaves you on the log you have now with the reason printed above.

Why both columns Coverage says how much of the log ends up inside a case. Repetition says whether those cases have anything in common. A type can be excellent on one and useless on the other, and choosing on either alone picks the wrong one - which is why neither is shown without the other and why nothing here is marked recommended.

Back to Data