Adding ContactIDs to multiple lists

[LaRetta]

Users want to select/de-select a Contact (while viewing the contact on the Contact's main form layout) and add them to a 'list'. They need to be able to name and date the list and select/retrieve those Contacts later. These lists will be things such as: 1) Send emails for new promo, 2) Duplicate an Order for everyone in the list etc. I do not want to flag the Contacts and I plan to write the ContactIDs to multi-line. However, I can't use global because the list needs to be there the next day (even if the databases are closed). Questions:

1) Field size: If I store ContactIDs as multiline in standard text field and the IDs are 10 characters, how many Contacts max can the text field hold? I'm probably fine on size but I want to know the calculation to determine how many (depending upon character count).

2) Structure: Would you suggest a table of Finds attached to the user (Staff) table? I'm envisioning User viewing their lists in portal, selecting a list and GTRRing to those Contacts (in List view).

3) User Friendliness: While viewing a Contact detail, the User needs the ability to add (or remove) this Contact to/from ANY of their lists (and even starting a new list). I considered popup (displaying their list with NEW option to create a new list on the fly and add the Contact to it) but adding/removing ContactID will require script, right? How can I make this easy for a User on the Contact's detail form layout?

Item 3 is my big stumbler. All ideas appreciated.

LaRetta

[RodSierra]

I'd probably set up a new table.

MailLists

ListId

ContactId

Do a self on ListId

Then ContactId back to your Contacts table of detailed info.

Allow new records to be made in MailLists, and have one global in contacts for selecting the ListId relating SelListId to ListId.

Then you can do all your work in that portal.

Rod

[Ender]

I'd suggest extending that out one more level. Use a Mailing table and a Contact-Mailing join table.

It's easier to manage the adding and removing of these join records than it is to manage the keys in a multi-line. But more importantly, with the join records you can remember additional attributes. For example, it may be useful to remember when a Contact was sent a Mailing.

LaRetta, if you look around for my old MergeLetters sample file, you'll have my suggested interface for adding Contacts to a Mailing. Adding and selecting a Mailing isn't in there, but that should be no big deal.

[LaRetta]

Hi Mike,

Actually, I have your Merge Letters right here in your folder! Thanks, I'll take a look.

The reason I went with multiline thinking is because (prior to GTRR Match All in Set) we HAD to write to multiline. Ha ha. The thing is ... I already have an Activities table which tracks work done, calls to make and so forth. I wonder if my attempts to split something else apart is more an indication that my existing Activities table isn't being fully used.

Why flag a Contact when we can just create a related record to 1) add the Contact to a list and 2) track when and what was done. It seems like ThingsToDo, Activities, WorkDone, Lists ... all share the same critical attribute - the need for each User to flag, list and perform their work on groups of Contacts. What is the difference between the Bookkeeper selecting 10 Contacts to call on past-dues or a Sales Rep scheduling Activity to send proposals to 20 Contacts? Work is work, no matter the type and it requires grouping records by dates, types, work to do and so forth.

Usually when I review a concept, it opens up 50 more ideas/concerns for me.

We need to 1) flag a Contact to 'do something', 2) view those lists of 'somethings' and 3) view other Contacts within each 'something' group. And we need to easily be able to select a Contact and POINT to the 'something' it should be added to (or removed from). Management asked for a way to flag records for work-sets but they already have it in their Activities table! They (and I) didn't put it together because (obviously) Activities isn't structured easily enough for them.

This is my current thinking. Thank you both for the input on this. It's obvious I almost headed off track and I appreciate all the help I've been given on it.

LaRetta