Idea Details

Need to identify filenames for email events in the iConsole

Last activity 06-11-2015 09:35 AM
alise02's profile image
03-31-2015 10:02 AM

Currently with control/outgoing email/control triggers, when an email contains multiple supported attachments, there is NO way to identify, from the iConsole, which attachment caused the trigger to fire. Reviewers need to sift through each of the attachments to figure out which one (or which ones) triggered the policy.


Ideally, we need to be able to treat filenames and their respective extracted text as key:value pairs such that (a)  in policy, we can reference these in smart-tags, data lookups or otherwise & (b) in the iConsole, reviewers can quickly identify which file contains which keywords/match


06-11-2015 09:35 AM

You have voted for this Idea so that is all you need to do Christina! The creation of Ideas in this forum has replaced the previous Enhancement Request process.

06-05-2015 03:33 PM

Our users have requested this feature to help with their review. Was looking to raise this as an enhancement request but found that this idea already details exactly what we are looking for. Please advise if I still need to create a separate Idea for it to qualify as an enhancement request.

04-09-2015 11:00 AM

Thank you. Yes, that's what I thought might be best as well.


I like the idea and feel this should definitely be considered for a future release. However, we will need to overcome the kvoop limitations mentioned by @Beeks as well as make several UI changes.

04-08-2015 06:01 PM

@Beeks. Thank you for the up vote. I appreciate your feedback and your reflection. I don't feel i was being hostile, and i certainly did not wish or intend to come across as such. I'm not a seasoned front-end developer or even and un-seasoned one... so i would have to defer to my engineering team on how the schema would change if at all.


@sprro04 - I suppose one way to do it is on the Trigger Detail pane in the iConsole, have a list of files that actually triggered the policy and then group each of the triggered terms under respective files - a reviewer could expand / collapse each file and see what caused the trigger to fire - much like a tree-view.

04-08-2015 05:05 PM

I like the idea, but conceptually I have concerns how all this information could be displayed in the iConsole.


What are your thoughts/suggestions regarding this?

04-02-2015 10:49 PM

@Seb I like the idea, and have upvoted after your reminder, but the tone of this thread seems a bit hostile. My main hat is SQL DBA/Custom Dev against the product (I don't work directly for CA.) So I look at this and think "how does this change the schema? What OOTB reports will this impact?" When I see suggested DB/UI changes I pause and think of the impacts to my existing customers with customizations to meet client requirements. I'm not adverse to schema changes, just cautious


How I'd like to see it? Not sure. How I imagine i'd see it? Multiple iterations of extracted text, per trigger, per file. But if you send an email, with a word document, with an embedded powerpoint, which violates policy,what to display? Kvoop doesn't really help us here in determining the file name. And if we're sticking with kvoop we dont get much help.Chances of getting off kvoop to a solution that identifies file names, without getting seperate hits against a PE? heh. Your thoughts would be appreciated there.

04-01-2015 10:35 AM

Beeks, as a CA Services Architect my role is provide a technology solution that meets specific business requirements. I also keep an eye out for ways to improve the product where or when it falls short of meeting those business requirements. HOW the product can be developed and enhanced to provide such an improvement - is the product of a specific and documented business use case and the job of our Engineering department.


Having dabbled in development & design myself, i know that there's maybe a dozen different, practical ways this can be accomplished.


What i'm interested to know is how YOU would like to see it in the iConsole... How i might like to see is immaterial.


PS: if you like this idea, i would appreciate your vote.

04-01-2015 09:47 AM


“Right way” is subjective; What’s not right is ignoring that the presented solution is better than the current state of displaying extracted texts from inner/nested files without even properly referencing from where such text came from.


One thing that we already do is (note that it is configurable) how much text it is supposed to be extracted for the analysis as well as how deep the extraction should go (default is 3 levels down, if I am not mistaken).


Now, IMHO, the acceptable solution should display on the ‘Extracted Text’ section the breakdown of which text was extracted from which part of the email (e.g. attachment, body, subject);

It would be great to have: If extracted from an attachment the name of each attachment a text was extracted from, on that breakdown;

It would be ideal to have: Not only the above mentioned but also, a display of the message attachments (nested), right below the main analyzed email (for supported message files – but here is another discussion because of how the PE was designed to strip the text out from the emails to analyze and then compile into a ISO compliant format).


I believe that the point here is providing constructive feedbacks – So, feel free to contribute with something that can be used by the community.






CA Services | Security & Compliance | Data Protection & Privacy

+1 214 548 9021



03-31-2015 08:03 PM

I like the idea, and think it could be very useful if applied in the right way. But how do you perceive the iConsole to display this information when an email contains multiple attachments which are either included emails, or nested zips? If a document that is nested multiple layers deep triggers a policy, what do you display to the reviewer?

03-31-2015 11:47 AM

‘Egg of Columbus’, right ? The idea seems obvious now it has been stated, and every one can make the egg stand on the end after Columbus..

03-31-2015 11:24 AM

Seb, great thought, but I have to say, this is a feature which should have been included a very long time ago.  Still surprised it hasn't.....

03-31-2015 10:35 AM

Great idea - That should be a must have feature - Thanks so much for that, Seb. Best regards.