Thanks for posting this idea Laurie! I've been working on the LX Starter notices for our members and this one will be a deal-breaker for not moving forward with our implementation once I break the news to our Circulation Committee :(. We can't have two very different looking versions of our notices going out to patrons.

The current configuration based on the location served table (which isn't big enough to hold all the locations for our largest member) means patrons receive multiple notices of the same type. We currently tolerate it using the standard notices in Sierra for Hold Pickup and Courtesy notices, but all our other notices are set to all locations so patrons don't receive multiple versions of the same type of email notice.

In an ideal world, our patrons would receive ONE email of each notice type, based on their home library or pickup location (not the item's location code). We want our patrons to receive a single notice that includes all items the patron has overdue/billed/etc. regardless of the owning library and allow our members to customize their own notices. Records that generate a notice with invalid or missing home library codes could go into a daily report or an alternate queue to be resent once the errors were fixed.

Centralized notices are a must-have for consortia libraries. Patrons would be inundated with messages if we were not able to consolidate. Library communications would just become spam.

Please prioritize this fix! It's essential that messages to our patrons be consolidated from a central location instead of multiple messages being sent from the 66 member libraries in our consortia.

Not only will "looking like spam" hurt our ability to get patrons to read the individual notices, but marking emails as spam often enough could lead to email services taking action against us. https://support.google.com/a/answer/14229414

The courtesy note is an example of why we need this so critically in a consortia. Sierra is not designed to send notices from the "check out" location, the notices for the most part are tied to the owning location. A patron who exists in a consortia does not necessarily know of the other libraries within a consortia, particularly if it is a geographically large consortia. Hold requests are fulfilled by owning locations across the consortia. Therefore, we send courtesy notices from the central system to all patrons to avoid the patron experience of being notified, as a courtesy, by libraries they have not used. Without this feature, patrons would recieve multiple notices from any library whose item they may have checked out at their home library. Very messy.

The lack of this feature is precisely the reason that our consortia opted to not move to LX Starter at this point in time. We love the editor and really want to be able to utilize this product but until centralized notices are available we simply cannot use this product.

This is vital for consortia! The number of notices that would be sent if we didn't have central messaging would be absolutely staggering. I will also wholeheartedly agree that we are also SO ready to leave (the very outdated and tired) Jasper-based circ notices behind.

This is an absolute necessity for us poor little consortia. Getting patrons to read our communications is hard enough without our power users feeling bombarded by email after email after email for each individual item they have checked out or reserved. This would be ideal.

One thing to note is that patrons will not only disregard spam, but an email who's been bombarding them with messages (at least I do). Consolidating messages will increase the chances of the emails being read as well.

In a consortium, it would be very useful to have a system level as well as library level (and branch level below that). I would want this ability for all notice types, so that different consortia can choose to send any or all notice types from the system as opposed to from members, according to what makes sense in their context. Additionally, having a functionality in which the individual consortia members can choose to use or copy+modify the system-level notifications would be ideal. Not all libraries want to do their own emails (from scratch, or at all).