We are trying to fetch the below reports from CASD for the last 3 months ,
1. Tickets created by Fraud partitions
2. Tickets created/reported and handled by Fraud_Analysts users.
Any best practices for fetching the above report. Thanks in advance.
When you say "partition" what specifically are you referring to? Partitions (As in data partitions) dont create tickets, and there is no record of what data partitions were in effect when a ticket was created. I would assume that you are talking about "Tenants" rather than partitions. If thats the case you would pull tickets based on a tenant in a multi-tenancy environment. As for the second part, tickets created or reproted by "Fraud_Analysts" users - is "Fraud_Analysts" a role, group, contact type, access type or tenant?
With that info we can give you a better idea of what to look for.
1. Am referring to data partitions and needs to identify the users contacts who have been provided with Fraud data partition(customized) so that I can able to pull the report with the help of user info.
2. "Fraud_Analysts" is an "Access_type"
Hi Mohan - since users can use multiple roles, and the data partitions are usually attached to roles, we would not know this as there is no mechanism to say what data partition was in use when a user created a ticket. That information is not kept anywhere. As for the second one - this is complex. The way that users are linked to their access type is via the usp_contact table. The UUID in the usp_contact table is mapped to the UUID in the ca_contact table. The CA Contact table is where you will find the userID etc. So you will have to build some joins between the ca_contact and usp_contact, and then usp_contact to the access_type_v2 table where the access types are stored. Unfortunately something like this is outside the scope of support, so we are not able to assist you on this one. You can see if other folks here in the communities have done that before and may be willing to share thier work with you. Additionally, just as a side note, it would be a better practice to differentiate those cases in a different way, possibly by using a custom field that is a checkbox or something so that you can easily pull a report of those cases if needed, without having to build all sorts of custom joins etc.
Hope this helps a bit.
Hi Mohan - Did Jon's response help answer your question? If so please mark it as Correct Answer. Thanks!