Client Management Suite

So, as the title says, I made a little bit of a mistake...the automated report I set up is now sending me 13k emails...Any ideas on how to stop this?

I'VE LEARNED MY LESSON TO NEVER DO THAT AGAIN... ;)

Change the evaluation rule for the policy from run for each record to run for non empty data. 

First though, chose a report which doesn't return a lot of rows though.... ;-)

If your report still doesn't look right, you might want to clone an existing email automation policy (a policy that already uses the "send automated report email" task) and edit that to suite your needs.

To be explicit here I'm saying use the "send automated report email" task as for 13k records it's unlikely you'll want that in an email and that a URL to visit might be mode appropriate. 

If you do however want the all these records to be included in the email body (rather than email contain the URL to visit) then use the "send automation policy email" task.

Well, got this fixed...Had to delete the query I had created and the emails finally stopped.  To be clear, the reason I was even testing something like this is so that a certain person could receive an email with results that could be outputted to a .csv, but I was testing html before I tried a .csv.

Ahh.. I see the issue was still 'live'. I take it that disabling the policy didn't stop the iteration; and hence why you had to delete the actual query.

In our environment, when a user requests huge data sets like this it's normally because they haven't yet decided exactly what they want to do with it. When a user requests such large report rowcounts it frankly sets off alarm bells (humans aren't designed to digest this volume of information).

 In the end, what I find is,

1. Huge data sets are requested for future-proofing against future audits 
   For this we can provide backups of the CMDB. The advantage is that this really does contain everything (rather than second guessing an auditors requirements). Should an audit occur we can restore any backup and deliver the exact information they request. This gets around the problem that of people requesting historical data that wasn't originally requested for in their emailed report archives.
    
2. Huge Datasets are requested for their own data munging
   With a bit of dialog, you can often find that this data munging can be performed on the fly with some decent report parameters. This has the advantage that the requester has rapid access to the real information they need. And often, these more tuned reports have a much reduced row count.
    
3. Huge Datasets are requested for import into other asset systems
   In this case, a CSV is an understandable route. Setting up a connector to link the two systems can also work.. and many asset applications come with their own db mapping utility to make this sync a bit easier (you can create a read-only db credential for this).

Hi dyeLucky,

Not sure how to mark up this post. If anything here was useful to you please mark any helpful posts. Otherwise, we'll consider it closed and lock it.

Kind Regards
Ian./