Some kind of bug?

[miplatt]

We have a table "Mailing List" in which each record is a list of associated contacts (hence the name mailing list).

In the Edit Mailing List interface we are able to open the list either by companies or by contacts and check off who should or should not be on the list (please refer to the attachment).

Today, after making changes and clicking select, we return to the Edit Mailing List interface as attached. When clicking on OK, instead of saving the changes, the error message popped up: Unexpected error while handling a request. Too many values in many-to-many field Selected Contacts.

We have never had this problem before. It usually allows us to make these changes without errors. We checked--this phenomenon happens on multiple computers.

Any ideas what might have caused this all of a sudden? What to check? Thanks.

[ZevToledano]

This is not a bug, this is by design. Too many customers were abusing many-to-many fields due to bad design or misbehaving automations, and suffering as a result. Let me explain:

A many-to-many field stores one record for every value. This means that, for example in your case with 809 contacts, every time you make a change to this field, it needs to compare 809 values to previous values, and then run 810+ SQL queries to save the record. Over the past few years we encountered several systems that seemed frozen/unresponsive but what was really happening was that somebody had written a bad automation that stored 10000s of values into many-to-many fields in several records, and the automation system was spending something like 30 minutes stuck on this task, and every time users tried changing one of these records, the system made them wait for lengthy periods. The customers reported bugs, but it was really a user error.

So we decided to block this kind of use. A many-to-many field is meant for things like multiple Contacts for a task, multiple keywords, locations, answers, etc. all of which typically require a max of 1-50 values. So we gave it a limit of 500. To use more than 500 you need to use either a many-to-one field (e.g. a linked field in Contacts), or in your case probably an intermediate table that links a Mailing List to a Contact. I'm not sure how many Mailing Lists you have but if you change them often, this new method will make your system more responsive. If you use them lightly, then sorry about the change, but we had to do something about this serious issue that kept killing systems.

[miplatt]

Actually, this kind of change (adding or subtracting an individual) is only really done for this particular list. Almost all other lists are built once with a large amount of contacts but not changed along the way, especially not one-by-one.

However, I see that this system-wide alteration prevents the creation of any mailing lists above 500 regardless of subsequent changes. This will change drastically how we need to handle this.

We will work on an alternative solution as you suggest. Yes, we understand but it is quite unfortunate and inconvenient at the moment.

Thanks for your help.

[ZevToledano]

I apologize for the inconvenience but there was no other way. Almost all our customers manage mailing lists using dynamic queries though (i.e. a saved query with filters such as all 'active' contacts from the USA that haven't opted out yet). They simply run this query and send the resulting list of contacts the e-mail without saving the dynamic list of contacts at all.

If you need to save the list for whatever reason, there are several ways of doing it. One way I recommend in your case is to use a 'Create Action' (Menus for Item Creation). I.e. you would run a query on a list of contacts, then right click on the ones you want and select the Create Action you built to associate it with a selected Mailing List (dynamic field). This action would automatically create records in the intermediate table. An automation can also optionally be built to block, or to find and remove duplicates from mailing lists.

[miplatt]

A few thoughts for your consideration (perhaps you have ideas to add to or correct my line of thinking):

For a one time mailing, we can certainly run a dynamic query, send the contacts the email and not save that list. (e.g. all companies in Algeria dealing with medical equipment)

For longer term lists, after running a query and ending up with the desired list of contacts, we could "share" the list to the document repository such that all could access it. The only issue with this seems to be that we cannot subsequently edit and resave it without having to make it a new file. This option also seems to leave up to the user where to save the document--which in our case is not desirable.

If we choose, "save query" this creates a .sls file somewhere. How can that .sls be accessed, opened and edited? After editing must a new saved file be created or can the original list be simply resaved as the edited list?

[ZevToledano]

All objects in the repository can be edited and resaved. Just right-click and 'Edit Attachment'.

Also, Repository folders can be saved to users' toolbars so every time they open the folder they can get the latest list of 'mailing list queries'.

You can also send it to users via the Messaging feature - "Send To..." instead of using the Repository.

When users open the query, they can also make changes and save it to their toolbar unless they have been locked from customization.

Keep in mind that in all these cases the query is still dynamic. I.e. the results may change in a few days when the query is reopened. Alternatively, you can right click in the list and choose "open items as query" to have the current specific list of contacts hard-coded as a filter inside the query.

The .sls file is more useful for developers or when building a solution, not for sharing.

[miplatt]

If we make a dashboard that accesses a specific folder in the repository, is it possible to include in the dashboard a filter so that we can filter the titles of those items? After creating a filter box, it does not seem to recognize the repository so as to search it.

[ZevToledano]

Yes you can store a repository query in a dashboard with filters. But don't forget to make the filters dynamic (you can also right click on the filter to do this).