I don't think there's a straightforward way to fix this problem. But what you can do is create a new table. Then, whenever you're updating the attribute, make sure to update this new table too. This way, you'll have the correct values whenever you need them.

Hi,

When using augment attributes in a new views, they always create a new table - for example:

when I wanted to add customisable notes to my case table called: "WORK_ORDER_CASE_TABLE" a new "WORK_ORDER_CASE_TABLE_AUG_CASE_NOTE" tables has been created. As you can see in the picture it contain info who, when updated the values in the augmented table. You can also add PQL code to check if specific status (like urgent) was appearing in the values for that case and "flag" it permanently with some colour and value :)

Hope I correctly understood your problem, let me know if that helps!

Best Regards,

Mateusz Dudek

Hi Mateusz,

Thanks for your reply.

I just checked that but seems not to work?

In new views I cant even see the table Im looking for (so the one you mentioned - when we are creating augmented attribute, then respective table is created which stores values for those attributes). From what I heard, we cant see currently in new views records which were created manually. The record we are talking about in theory was not created manually (but manually triggered). However maybe the reason of not seeing that is just the fact it was created long time ago. No clue

However in old views I was using that, but it keeps only the newest value.

This is not the case in your set up?

Lets take one example - Document X.

Below you can see changes on the status:

In table which was automatically created "XYZ_AUGMENTED_STATUS" I see only the most recent change - no history:

Regards,

Maciek

Hi Maciek,

I've make some tests and it seems you're right - no full history of changes is kept - only last recent status, my bad. In theory that could be fixed with applying trigger to a augmented attribute table but for now it's not possible :|

The only option I can think of is to add AF that will read those values from whole table, and run a skill that will store it in the regular table, with some sort of message that they were 'saved', but that's very clumsy workaround...

AF proposition:

Skill proposition:

Long term solution would be to report 2 feature request:

A) AF allowing for replacing skills - saving data into table (maybe can be done with custom HTTP request, with right header)

B) Allowing augmented attribute table to be linked to triggers

C) Full change history for Augmented Attributes table + ability to interact with them

Best Regards,

Mateusz Dudek