We have some issues where deliveries are being sent to deleted Recipients, and therefore might fail due to missing data, not to mention the bad customer experience of receiving emails after you ended your relationship with the company.
The case is the following:
First you create a delivery, with a target population, and with an approval process pending.
This seems to create some kind of log, where the addresses are stored (temp:forecastLog)
You then delete some recipients, some of which is in the target population.
After the recipients have been deleted, you approve the delivery (unbeknownst that the deleted recipient was in the target population).
This approval could theoretically take days in our organization, making this scenario more likely.
The delivery will then be sent to the deleted recipient, and if there is any dependencies to fields in the recipient-schema, these will be NULL
E.g. for our call activities sent to CRM, we have attached some extra data such as account number to the extraction file. When these are null, we get a crash in the automated imports into the CRM-system.
Is there any way to prevent this from happening? I've tried looking for any kind of option, but did not find any.
I believe the DB (Campaign Mart) updates (especially the purge processing) need to be re-evaluated. Data purge cannot take place during campaign execution otherwise you will always run into this type of issues.
Of course shortening the campaign deployment approval is a key thing also (e.g., approval should not take more than 1-2 hours instead of 1-2 days).
That might be improving the technical issue, but the customer experience is still bad. While we postpone the deletion of customer records, we increase the risk of communicating with non-customers, which is bad in both a GDPR and a customer experience standpoint.
I do agree that shortening the approval process also is key, but it is always hard to rely on the availability of resources to ensure relevant communications, which is the main use case for Marketing Automation.