Delivery execution without drops

[C_Canada]

I need to be able to execute a delivery for direct mail and/or Phone where the delivery just executes ALL rows, regardless of whether the recipient record has a terrestrial address or phone number on it.  The file is being appended externally with address and/or phone number elements that are (or may be) different than what is on the recipient record.  Unfortunately, I cannot find a way to force any delivery to NOT drop records for incomplete address or phone number. 

[Adhiyan]

Hi There,

So if I understood you correctly , you do not need any records to be dropped when a delivery is analyzed or you do not need any "exclusions"

Exclusions typically happens via typologies in deliveries and some of them are visible , some not in the properties of the delivery.

To check the reasons for the exclusions you go to audit>causes of exclusions to see which rules filters out the records , and once identified you can simply disable those rules.

Some rules are present in the "To" field of the delivery editor and others can be accessed via a typologies view folder.

Let me know if any doubts

Regards

Adhiyan

[C_Canada]

Exactly, I need records to not be dropped during analysis.  I don't have any typology rules set to drop where address is incomplete, but records are still dropping in the delivery analysis where address is incomplete.  (I believe it has to have at least a city & zip.  What I want is to execute a delivery where the only criteria for all records to create entries into the broadlog is that there is a recipient ID.  So, if I have 100 recipients in the transition into the delivery activity, I need 100 rows in the broadlog.

[Adhiyan · Accepted solution]

Hello ,

Yes this can be achieved if you do the following :

1>. Check the audit tab of the delivery to see which rules are excluding targets : Keep a note of the names to use in step3

2>. Click on "To" in the delivery editor and uncheck all the exclusion settings :

You may want to do this change at the delivery template instead of the delivery to avoid recurrent work.

3>. Create a typology view folder and check the name of the rules which excludes the recipients from the delivery from step 1 .

Uncheck the active button from the rule and that rule will not be applied to the delivery after this.

One word of caution : Disabling these typology rules will have an impact on the whole platform and all deliveries, so you need to exercise caution while disabling these rules.

Regards,
Adhiyan

[C_Canada]

This is the solution I was looking for.  I didn't realize there were typology rules being applied that I didn't see in my active Typology.

Perfect!  Thanks so much.

[farrahs85887753]

Can you show how to create a typology folder view to uncheck the active button for these rules?

[Vipul_Raghav]

• Create a new folder as explained in this diagram
  
  
  
• Rename it as per your liking
  
• Open Properties of this fiolder, go to Restriction tab and then enable the view option followed by saving the changes
  
• Hit Yes when prompted
  
• All typology rules on your instance will now be visible. You can disable the ones you don't want.

Regards,
Vipul

[C_Canada]

So, I'm coming back to this thread because the recommendation did not work.

I created a new typology and  removed ALL typology rules from it just to be sure.  The delivery activity, regardless of the channel I use, still continues to drop all records that don't have a complete address.

I don't want that to happen.  I NEED to run a delivery that ignores the  "complete address" calculation. I don't care if the address is complete, I want all records that I choose to get a delivery broadlog record.

[davidk21713691]

You need to uncheck unqualified address

By default some fields are mandatory to compute the direct mail.

Thanks

David

[C_Canada]

I have ABSOLUTELY done that.  It’s still dropping incomplete addresses.

i have removed all these settings and all the typology rules.

[Adhiyan]

Hello ,

I had a discussion with the engineers regarding this and this seems to be a hard coded rule in the Product code which is excluding this addresses .

The logging is not proper and hence the exclusion gets mapped against a wrong typology name. To resolve this in the current version , you need to update the addrDefined attribute to 1 or True in the contact information part of recipient form.

This addrDefined field is a calculated field based on a combination of Zip code and last name .

To make this update on a mass scale , you can create a workflow and update the field addrDefined to yes .

Regards,

Adhiyan

[cbeattie1992]

Hi Adhijyan,

I too have the same scenario as C Canada that the address for DM csutomers is not held within Adobe campaign but appeneded after the list is export externally.

However you can not update the address specified field (addrDefined) as this is an OOTB calculated field based on the following fields:

location/@zipCode], [../location/@city], [../@lastName]

Therefore in order to change the Address Specified field from 0 to a 1(Yes) you must update all of these field to contain a value.

I have found this to be the only work around given the information above.

I have implemented this within the workflows before the delivery:

This is the work around i have found works best for now. But of course not ideal as there is now an additioanl step within all DM workflows.

I will be interested to hear of any other work arounds or if there is any updates on Adobe Campaign side as this appears to be a bug.

Thanks a lot

Connor

[Adhiyan]

Hi Connor,

Yes that is right. Updating the zipcode ,city and last name would update the addrDefined field automatically. I mentioned that this is a calculated field in my last update but yes in the workflow you need to update all the attributes to have a value updated.

But honestly , this is not a bug . Because this attribute is meant to be used only for Direct mail deliveries and for direct mail we need a valid postal address and these 3 fields determine if we have a Valid address or not.

Regards,
Adhiyan

[cbeattie1992]

Hi Adhiyan,

Thanks for getting back to me.

I appericate the reason for the exclusion of customers with no address however then the TO exclusion is rather misleading .

As the you said:

The logging is not proper and hence the exclusion gets mapped against a wrong typology name. To resolve this in the current version , you need to update the addrDefined attribute to 1 or True in the contact information part of recipient form.

The TO exclusion criteria does not impact the exclusion criteria for a DM. therefore we have to update the date as a work around.

Thanks

Connor