Skip to main content
Question

Cumulative Distribution Curve - RUNNING_SUM (COUNT(DISTINCT...) - Line Chart Issue

  • August 7, 2026
  • 2 replies
  • 382 views
ben.hensl
Level 3
Forum|alt.badge.img

Hi all,

I'm trying to build a cumulative distribution curve in Studio using a line chart.

Along the X Axis I have a KPI which gives me 1, 2, 3 , 4, days and so on. On the Y Axis I’m trying to show a cumulative count of items which took the amount of days shown on the X Axis to do something.

I have the error in the line chart that there is undefined behaviour, no ORDER BY specified, because in the Line Chart I cannot sort by the KPI used for the X Axis.

When incorporating ORDER BY as follows:

    RUNNING_SUM( KPI("this is a count(distinct….) kpi"),

    ORDER BY (KPI("nr. of days") ASC))

I am told that I cannot use the count aggregation function together with a dimension function input.

Has anyone faced something similar and found a solution? When I put the two data points into a table and sort the table by the Nr of days it works pefectly but the same sorting functionality is not taken over when I switch that sorted and functioning table to a line chart.

Any ideas? Your feedback would be very much appreciated.

Thanks, and have a great weekend!

Ben

Be the change

    2 replies

    Jan-Peter van der Steege
    Level 12
    Forum|alt.badge.img+26

    Hi ​@ben.hensl, 


    I think running_sum it here not ideal. Would a histogram component not solve this in an easy way? 

    Best regards,
    Jan-peter 

    Visit Our Website: https://www.marcadus.com/en/services/process-intelligence/
    Harshit Jain
    Celonaut
    Forum|alt.badge.img+1
    • Harshit Jain
    • Celonaut
    • August 13, 2026

    Hi,

    I've run into this exact thing — the good news is it's a quick fix. The error isn't caused by your COUNT(DISTINCT …); it's the KPI("nr. of days") reference inside the ORDER BY.

    RUNNING_SUM of an aggregation ordered by a raw record-level column is a perfectly legal pattern in PQL — e.g. this works fine:

    RUNNING_SUM( COUNT(DISTINCT "Cases"."CaseID"),
                 ORDER BY ("Cases"."CreationDate") )

    The problem is that when you pull a KPI into the ORDER BY, PQL resolves it in a dimension-domain context, so you end up with a COUNT aggregation ordered by what it treats as a dimension-level input — which is exactly the "count aggregation together with a dimension function input" message. The ORDER BY needs a plain record/measure-domain expression, not a KPI wrapper.

    So order by the raw formula behind your days KPI rather than the KPI itself:

    RUNNING_SUM(
        COUNT(DISTINCT "Case_Table"."Case_ID"),
        ORDER BY ( <the raw day-count formula, e.g. DATEDIFF(...)> ASC )
    )

    Use that same raw day-count expression as your X-axis dimension, so the dimension and the ORDER BY point at identical values. If the raw formula still errors, it means the days calculation uses a dimension-only function — in that case materialize it as a case-level attribute (a computed column in the data/knowledge model, or a valid PU_ pull-up expression) so it lives in the measure domain, and both the dimension and the ORDER BY can reference it cleanly.

    On why the table works but the line chart doesn't: a table applies its sort visually, after the numbers are computed — it's purely cosmetic. A line chart doesn't carry that component sort into the running-sum calculation, which is why Celonis wants a deterministic order baked into the PQL via ORDER BY. Once the ORDER BY is defined correctly inside RUNNING_SUM, the curve builds consistently regardless of chart type.

    Quick checklist:

    • X-axis dimension = the day-count value (raw formula, not the KPI)
    • Y-axis measure = RUNNING_SUM(COUNT(DISTINCT case_id), ORDER BY(<same raw day formula> ASC))
    • Turn off any component/visual sort — the ORDER BY inside the PQL now governs accumulation.

    Thanks!

    Harshit
      Community Code of ConductAccessibility statement