@Eileenmcnaughton Not having an email in the upload should not have stopped the Contact List from being built. What API calls are you making and with what parameters?

No real person should have that as their email address, I would leave it and opt the user out.

Something struck me on how you can get this data. If you run this API call each day:

Both, you can see who is snoozed in the UI and via an API export - but you can't get the date.

You can export the current list of Snoozed records (which is currently 15,882) but not the date they will become un-snoozed.

SENT_CANCELLED does not do anything with GetSentMailingsForOrg. What is the mailing ID of the canceled mailing?

Your data retention policy is set to 450 days, you can see this under Organization Settings -> Archive Settings. I'll have to test that specific question. I would suggest you should cap all data at 90-120 days, anything after that is likely not real user activity, and has no chance of substantially changing the data. Frankly, I suspect if you had a cutoff of 60 days (or even shorter) that would capture 99.8% of all your data.

I'm hoping once you get rid of all the extra databases, this issue will no longer occur. As this seems to never happen with the main database. There is no reason to open Support tickets on these as they are aware of the issue.

Same issue as before. As this only happens with the non _All wiki DB, I'm hoping once these other DBs are removed this issue will be resolved.

I found an email from 2015 wher eI outlined this API call. I forgot there is an unpublsied elements called SENT_CANCELLED. I'll reforward the email.

Ah yes, remove <SENT/> and that will return all types, included Canceled.

Add List ID 9574332 and that should do it.

Ah... ok. So let's look at the specific API call. Need the full XML. Thanks.

(a) what is Superset? (b) what is the API call you are making, do you have the XML?

I have opened a case up on these two jobs.

No logs are stored more than four days (as that would not be GDPR complaint). I suspect you see the SUCCESS within 1-2 mins every time? Can you setup an alert that if don’t get that say within an hour, it sends us off an email?

Data job results are only retained for three days, so I can ask, but don't expect there is more infomraiton.

With an average of 68 GDPR data calls in the last three days (and the numbers are sequential) , that would make that ID around 50 days ago. Does that make sense?

That ID is a bit confusing. The current GDPR data job are IDs 33341 -> 33546, which all ran in the last three days and all are marked SUCCESS. Thought maybe this was a datajob ID, but that range is 173051574 -> 173776347. What was the API call make with this ID and when?

A 3% is normal for Verizon (aka, AOL/Yahoo). When I see blocks at Verizon it will be 100% soft boucning.

You want to build this report by domain group, not domain. Example, RoadRunner no longer exists, it is now part of Spectrum Communications. I will build a mapping for domains -> domain groups to use.

Each GDPR job has several subtasks. The job may get stuck after completing the subtask. This is a known issue. If a GDPR job does not complete within 60 minutes, just let me know and we can dig into it.

I'll have to ask if there are more details on the failures. When you get one that failed, are you able to re-run it? Did you mean the two from July 2019?

Also, I recommend you merge all your data into a single database to simplfy GDPR requests. There are seven databases right now, and ten suppression lists.

Reading back over the previous notes, wanted to mention "I realize RML contacts should have civi contacts" - there are several hundred thousands RML signups that are not in Civi. Some are historical, and some are recent. I'm unclear how you are getting RML contacts out of Acoustic into Civi, but happy to help debug that if you want.

Can we take one step back and sanity check that the Civi database has all the data from the Master Suppression List? I'm assuming (and this might be wrong) that there are emails on the Master Suppression List that are not marked as opt-outed in Civi. When you export the MSL, select the “Export Contacts, Opt-Outs, Snoozes and Undeliverables” option.

Rebuilding the Master Suppression List is very risky, and I would not recommend it. Anyone on that list should never be emailed. If Civi were missing any data, that could be catastrophic to your deliverability.

"there's a way to import the list of suppressed contacts to the main db with opt-out selected so that it just updates the contacts that are already in the main db" - Are you referring to Civi or the Acoustic database? For sure you can keep this all clean in Acosutic, but over time it will get out of sync again.

A few notes to add. You can do anything mentioned here with the API, it's just up to you how you want to structure it. The link above about CRM integration does not apply here (that is for Acoustic accounts that sync with SFMC or MS Dynamics).

IBM validated the DNS setting, and is using the new key:

The key is correct, and IBM will validate it before turing it live. I would recommend in four months, you remove the old key.