Multiple submissions of same event to different groups

As we onboard more campus units into LiveWhale, we are starting to see cases where a community member submits the same event to multiple calendars, not realizing one event can be shared. So when those submissions are published by different groups, we end up with duplicate events appearing on the main calendar site. It’s not a huge issue yet, but it happens enough that I’m wondering how to nip it in the bud. Do others experience this, and if so, how do you handle it? Do you just train editors to check the shared events tab to see if a submitted event already exists before publishing it? Do you have a field on your submission form where folks can select other calendars they’d like their event to be shared to, so the group that receives the submission can suggest it to them? Or do you just manually resolve dupes as you see them one by one (which is what we’re doing now)? Thanks.

In our case, this only occurs only once in awhile, and it tends to be two offices working together both taking it upon themselves to add the event. I tend to catch these, merge them into once, Hide the other, share, then notify those involved. That hasn’t spiraled out of control at least.

I’ve seen your situation more with faculty/staff profiles (CMS): faculty in department A needs to appear in department B, but B doesn’t know about sharing, so they make their own. In this case, when found, similar approach: merge, Hide, share, notify. People tend to learn quickly once they’re aware of the possibility; again, no spiral. If anything, I find editors know sharing is a thing, but don’t think to ask the other party to share and instead ask me.

Since you appear to be onboarding people, perhaps the training/guidance there could use a little more emphasis on the possibilities of sharing? Then watch for instances from those already trained and use those as an opportunity to follow-up with this topic.

Thanks,
Nick

Thanks, Nick. I do go over event sharing in editor training and it is one of the features they like and use the most! But in these cases it is community members, not editors, submitting an event to multiple calendars via our submission form. So just trying to figure out if there is a better way to avoid merging and hiding dupes manually as they come up. Appreciate the input!

Ah, I see it now. Some possibilities, from a developer point of view.

1. Force the choice of a single group.

  • Set the submission form field for group choice to allow a single choice (radio, dropdown, etc).
  • Set instructions for users to “choose the most relevant group,” and that “group editors will share to other relevant groups / groups can find and share all events / etc”.
  • Include a note in the event editor, always or conditional, reminding editors to share events to relevant groups, “especially those submitted by the community.”

2. Send submissions with multiple groups to the web team, or communications team, etc.

  • Keep the current field as-is, but include in the instructions to choose a single group.
  • Allow community to choose all relevant groups, but if more than one is selected:
    • The event is added to a specific, centralized group tasked to manage these submissions.
    • The groups chosen are appended to an existing field, likely the description, for editors to reference.
  • Editors in this centralized group do an initial review the submission in order to:
    • Move the event to the most relevant “owner” group, and notify their editors (somehow?).
    • Potentially share the event with the other identified groups, or leave for owning group’s editor to evaluate and manage.
    • Notify the submitter that the event was assigned to the owner group, their editors would be managing it, and to please choose a single group in future submissions.

(Edited) Both would require some development work. #1 seems ideal, if those involved know their roles. #2 is more labor intensive, but ideal if having the input of multiple groups from the community is important, or if a grace period is needed to train both community and editors in the ideal process before switching to #1.

I hope that may be more helpful in prompting a good solution.

Thanks,
Nick

Thanks, Nick - I appreciate you offering some potential solutions for us to consider!

Hey Jen,

If it’s helpful: a few schools have small customizations to their event editor form that mimic the “suggest this to other groups” functionality on the front-end. In that workflow, the event still gets submitted and approved by one group, but when they do make it Live, the other suggested groups then get “{LWC User} suggested an event to your calendar” notifications. So, while that’s possible to do technologically, I don’t necessarily advocate for doing it on such a broad scale (it makes it kind of easy to blast event submissions to many groups).

Or, some schools opt highlight only specific groups that tend to appreciate showing suggested events (a daily digest type group, or specific audiences) and then share to those on approval.

A different approach—and one I might recommend, personally— would be to make it a human-readable question via a custom field: “Should this event be suggested to any other departments / groups for cross-promotion?” That would allow the submitting community member to put their thoughts on cross-promotion in layman’s terms (while hopefully giving them the sense that they don’t need to submit it twice), and then the event approver can use their judgment about actually suggesting the event.

Hope this helps!
Karl

Thanks, Karl! We’ll take those ideas into consideration!