Can I ask what implications does it have when you are NOT sending deliveries from the standard recipient table, but instead from a table that is 1:1 linked to the nms:recipient table?
Any particular impact on reporting or anything else that needs to be taken into account? Or not really any implications?
I'm still in the middle of designing table structure so any help would be much appreciated!
Thanks David.. However I figure out there's a simpler solution to my problem (probably I didn't explain it very clearly in my initial post), so here is the update in case someone else run into the same scenario:
So I am still using the Recipient table (i.e. no new table is created), but obviously I still needed to extend the recipient table.
And then when it comes to data import, use Enrichment to 'Add data', and then define 'A link'. Select 'Define a collection' as the link type. Select 'Database schema' and 'nms:recipient' as the Target schema.
Next step is to 'Use a simple join'. Then in the Join conditions:
Then after Enrichment, add the Update data activity. Make sure the Record identification is set to 'Using reconciliation keys' and add both folder name and email in the Keys for finding records list.
So the end result is that if firstname.lastname@example.org come onboard, AC will check if this email exists in the TEST01 recipient folder. If it does not, it will insert it, even though TEST02 recipient folders contains email@example.com in the same AC instance.
Hope this helps.
You have to follow these steps :
- data partitioning: create a folder for your business unit with entities needed (recipients, campaign management, operator)
- user access: grant the access to the folder only to your XYZ users. They can access all data and objects within the folder for which they have access to.
- Advanced restriction using sysfilter to enforce the folder dependency on a source schema.
That section is helpful - thanks for pointing me to it.
By quickly skimming the introduction, it seems that using a non-standard recipient table can cause a few problems if there's a need to use Services and Subscriptions or Social Marketing module in the system in the future (so not very much future-proof).
Let me share my use case here:
Let's say the overall business is called ABC, and they have a business unit or department called XYZ.
ABC has an existing AC instance (hosted by Adobe), and XYZ will onboard to the same instance soon.
If all XYZ and ABC data are going to be stored in the same recipient table, the newer records will overwrite some older records if they share the same email addresses, which is not something I want.
That's why I am considering to build a new table, and store the XYZ recipients in this table.
But is there a better way to do so? Ideally I want to keep the XYZ contacts in the default recipient table but somehow they will not overwrite the existing or future ABC contacts.
Any feedback would be highly appreciated!
There is a section in the docs dedicated ton using a custom recipient table. Please have a look at it, from this page: Introduction, and the related pages available on the left.
Can you share more of your use case as usually the common thing to do is not to create a link with nms:recipients but rather to create a dedicated target mapping.
Let me know,