This seems more like a design flaw than a straight forward bug.
What I noticed was that when I changed the CSQ name, reports would only show details of calls for the CSQ name at the time of the call.
Hence the CSQ name string must be in the database and not the CSQ database ID, which is what should have been used (if it is available)...
I shall park this until I have a look into the database / database shema further and see if Cisco could correct it by developing reports to reference the CSQ ID (Primary Key) rather than the CSQ Name. This might not be possible depending on the design of the system, and how CSQ are in the database but it is not typical.
i.e. Don't change the CSQ name post go live, as it will have major impact to reporting.
Gerry, you are correct in saying that this is more of a design thing not a flaw actually but something how it had been designed to work. Think it like this, at some point the CSQ name was CSQ1 and calls had come for that and hence Historical Records got written against that. Now few months/yers down the line, there is a need to rename the CSQ from CSQ1 to CSQNew. At this point, if UCCX is allowed to delete the old record for CSQ1 then all the associated call records, details etc will be lost then hence we do not do it that way but the entry is kept in the DB if someone wants that in future unless the records get cleared as a result of DB purge or you manually do that bu going into root with the help of TAC. There is an another way that is creating collection query, refer below for more: