They are treated as values in a column, but only within a record. If it is an attribute built into a record, it cannot be referenced outside of the record like in a KPI. You can go KPI -> Record but not the other way around.

@matt.witty13 , I don't think that's the case. I have several KPIs where I use custom attributes.

Also, the error message is not about the attribute missing, but the KPI referenced in the attribute.

When I use the custom attribute, the PQL editor usually complains about the column not found but the calculation still works. I would try using the official format with " quotes.

Also, maybe adding some calculation / aggregation you want to perform.

This is from the training environment, so it doesn't have any business meaning, just to show that it works:

This is a custom attribute resulting in a number:

The KPI referencing the custom attribute (the ID has to be manually copied over as for whatever reason, the custom attributes cannot be referenced when creating a KPI in the KM):

The PQL editor complains about the missing column but the calculation works:

But this is a very simple scenario, the custom attribute doesn't rely on other KPIs.

The training environment might be a different version of EMS or a different version knowledge model, so I wouldn't go by that. I just tried to do that in my own environment and it could not find the record I was trying to reference.

What I meant was you can't go into KPI in the knowledge model and reference an attribute in a record. You can reference augmented attributes. But I can't take a custom attribute into the KPI section of a knowledge model and reference it there. Unless that's an update we need to our environment, but I don't think that's the case.

I've always created a KPI and then used that as the attribute.

Like this. So that I can reference it outside the record

Want to reopen that topic as I am stumbling only today about it.

I was very happily making use of the exact way matt is claiming its not possible: having calculated attributes and then utilizing them in a KPI.
I find this extremely handy to think first on which level a KPI belongs. If its not an aggregate but belongs to a single object I consider it a “calculated attribute” and set it up there. This helps to not clutter the KPI page of a Knowledgemodel.

I experienced the same behaviour that ​@rita.kiss12 was describing. In the PQL editor of the KPI it was throwing an syntax error “Column not found” but still the calculation went through and properly.

All this was Case Centric and still works today with my Case centric Knowledge Model. Now with a switch to OCPM based knowledge model I experience also in Preview the error: COLUMN_REFERENCE: Column with name m"no_of_activity_execution"] cannot be found on table u"el__MainEventLog"], therefore can not save the KPI and therefore not use this approach anymore.

Can this be something tied to OCPM vs CCPM ? I haven’t believe so initially, but maybe someone made similar experiences.

We use the exact same approach as ​@manuel.wetze: if it’s a “calculated column” belonging to a single object in the records, I set it up as a calculated attribute. Only aggregations go to KPIs. In the meantime, we have applied the same strategy in several other cases.

To confirm: those are all case-centric knowledge models, not object-centric ones.

As a closure to my problem at least I can now shamefully admit it was due to a confusion with the IDs on my end. 

So the take away to the wider community would be that it works to use calculated attributes within KPIs and also within other calculated attribues of another object no matter if its OCPM or CCPM. It will show a syntax error “Column not found” but still calculate it correctly.

I would very much like Celonis though to show those Calculated attributes in the PQL editor of KM as it also does within the Views.

Then we don’t have to rely on copy pasting IDs manually which is obviously error prone.

Please note, you cannot create action flows for records for which you have calculated attributes though: “Currently we have a known issue with using the custom attributes as calculated attributes with triggers on the record. Once the custom attribute is referred as a "recordId"."attributeId" in any of the PQL used on the record, the trigger fails there with the message "column not found", since the trigger assumes this as a data model column and as it doesn't exist on the data model.”

https://www.celopeers.com/s/rightanswer?language=en_US#solutionid=250219093408043&csid=12