I know that there's an option to use a composite primary key, but there appears to be warnings on various (1) posts (2) by experienced users that this is a dangerous path to travel down. Similarly, dupe rules appear to be fraught with complexity and potential consequences. We could use a partition in combination with dupe rules, but we'd actually like to be able to tie the data back to leads whenever possible.
If we create a custom data object, could we populate some of the data into that object so that the e-mail address can actually store unique data points for the individual submissions on submission? Do we need to leverage the API for this? (From what I read, as well as a previous thread I had started, it sounds like the values stored in data objects can only be updated via the API.)
I have concerns about either an external database or using a data object as each submission essentially represents a registration, but those registrations won't be accurately represented in the program status. (Making it harder to track the number of registrations for live events to verify we don't exceed our caps.)
My preference would be to force users to register using a unique e-mail address, but that would require changes in some processes that would require the buy-in of other business units and we are meant to launch the registration pages in early August.
At a higher level, can anyone provide their take on managing leads with shared e-mail addresses? From my perspective, it's more sensible, in the long term, to push users to provide individual addresses in order to improve registration processes for events and webinars and strengthen other services on the site that might be built on the back of e-mail communications. Has anyone made that sort of transition before? (From allowing multiple leads to share e-mail addresses to expecting a single e-mail address for each lead.)
Apologies. Long post. Just trying to weigh all the options. (And perhaps uncover some that I haven't thought of.)
I hope this helps in your deliberation.