Members to be able to submit events
Not supported, only administrators can create events.
Members have the ability to submit simple events which can be approved by administrators.
Even though it is not a direct implementation, I hope this could be helpful:
We just launched integration with Integromat platform, which helps to build automated workflows. We also provide several templates for quick start, and one of them allows to copy google calendar events into WA events. So if you share a google calendar for events submission, then the scenario could copy submitted events into your Wild Apricot account.
You can try this integration by this link https://www.integromat.com/en/integration/2275-copy-google-calendar-into-wild-apricot-events
Karen Wall commented
I don't know if I'm allowed to say this on here but I needed the calendar functionality quickly so I signed up for Teamup calendar. It's only about $100 a year (or you can get the scaled down free version) and you can add it to a custom HTML gadget using iframe and it looks just like it's any other Wild Apricot page.
Gregg Heggeland commented
When is this available?
Brett Jardine commented
Our members are organisations (suppliers) operating in the travel industry where they are often hosting retail travel agents at events such as product launches - often competing with each other for the same audience. If members had the ability to upload details of an event that could be displayed in a calendar form (same as currently available for an Administrator), this would be a great "go-to" place for members when planning future events.
Done. Thank you for your attention.
Thanks for such a detailed comment.
We considered both options from the very beginning. The ability to create simple "notes/announcements" in the calendar by members and the ability to give limited access to the administration of events. Such a request is also presented on the forum https://forums.wildapricot.com/forums/308932/suggestions/8827180
I think it makes sense to copy your comment there too. Do you mind?
Our organization hosts many events with recurring sessions that, on a limited basis, are open to the public. Our typical event will have free registration options for members and the public, the latter of which are constricted by the member event organizer’s Membership Level. In effect, the public attendees are “guests at-large” of the event organizer and can self-register into the event (the organizer, when a member, can also register specific guests as well). Bifurcated event registrations, members or the public, serve as a recruiting tool for new members and, since admitting the public helps events to achieve the necessary critical mass of participants, as a retention tool for existing members. As most of our member-generated events are Regular events, I see little benefit to our organization from the current proposal.
1) Under Wild Apricot’s current proposal, the ability to submit events can be assigned to an individual member. In effect that member would be a Limited Event administrator with editing privileges only over the events that member creates. That’s great so far. Rather than creating an entirely new interface for the member’s Profile, instead I suggest extending that administrator paradigm by giving a contact (not just a member) Limited Event administrator access to the Administrative View of the organization website. I propose the following options for setting up each Limited Event Administrator.
a. To view or not view but not edit others’ events in the Event List (or a calendar UI). This allows one to see potential event conflicts.
b. Allowing specific Visibility (i.e. Event Access) settings when creating and editing one’s events. For example, if a Limited Event administrator is restricted to creating Admin Only visibility events then that creates an implicit workflow where that administrator must have de facto approval to change Visibility.
c. A numerical limit on the total number of attendees in an event (no limit is possible).
d. A numerical limit to the total number of future event sessions on the system at any time (no limit is possible).
e. A preset list of Saved Searches that may be used to announce an event.
i. As a sub-option, limits on the number of announcements to reduce “spamming” effects on the recipients.
f. The ability to create/edit/delete Regular events in addition to RSVP events. For Regular events I see the following Limited Event administrator options.
i. Similar to item 1) b. above, restrict to specific Visibility (i.e. Event Access) settings for Regular events. Because Regular events are more complicated, it is reasonable to separate this setting from RSVP events.
ii. A different preset list of Saved Searches that may be used to announce the event. Why is this a different list of saved searches from RSVP events? Because RSVP events cannot have a separate registration limit for the public versus members. If an RSVP event is open to the public, then the organization loses control over how many public members would be admitted to the event. This might be acceptable to some organizations, particularly when they can charge admission to the event. However, for us we have to ration public access differently since our competitors offer free events. Frankly, RSVP events aren’t very useful to us.
• Alternately, have an option to restrict a Limited Event administrator to submitting Regular events only.
iii. Across all Event Registration Types, set a maximum allowed price ($0.00 is possible; no limit is also possible).
iv. Across all Event Registration Types, set a minimum allowed price ($0.00 is possible).
v. Across all Event Registration Types open to the public, limit the number of participants allowed to register (0 is possible, negating public access; no limit is also possible).
vi. Across all Event Registration Types, set a minimum price for types open to the public ($0.00 is possible).
vii. Across all Event Registration Types, set a maximum number of guests allowed per registrant (0 is possible; no limit is also possible).
g. Allow the Limited Event administrator to exceed any or all of the limits set above, but highlight the exceeded limits in red (or some fashion). The system would retain an event that exceeds its author’s limits but it could not leave Admin Only status, nor accept registrations, nor be announced by email blast: only a higher level administrator could make these changes. This would provide an implicit workflow.
2) The Calendar interface is a great idea: event administrators need it too.
a. Calendar events could be coded by their Visibility and/or Open to Registration status.
I fear that the current proposal by WA is going to put event creation into a workflow rabbit hole that will be increasingly divorced from what it is really is: a part of the organization’s administration. It is in most organizations’ interest to empower members from the ground up to serve as potential administrators. Let the members see the backend.
Definitely would like to allow members to submit detailed events without being administrators.
Agree that restriction on membership levels is adequate control and overview by administrators is not required.
Would be good to have a few more details that could be added, just simple "choose from a drop down field" originally defined by admin would suffice.
Lets look forward to an initial release rather than too much initial finesse
Any idea when this will be released? I am reviewing systems at the moment and this is a requirement.
Nothing to comment so far.
As soon as we take it into works, we will post an update here and change the thread status.
Product Owner @ Wild Apricot.
Any update on this? Its been in the "making" for several years - desperately needed! I run 3-4 websites and all of them have this on the wishlist.
Tod Abbott commented
Just pinging this. We're looking forward to having this feature available to our members.
GGTC Webmaster commented
This is fundamental need for our organization. Is there any timing on instituting this functionality?
So do we have any idea on release timing? The design concept has been promoted since 2015! Is there still a roadmap?
Could it be done by Event Creation being initiated from a Site Page which is only accessible to pre set member types/restrictions as is done now under "Page Access Level"? At present Admin need to create all events.
Another realization... I see how large event websites post their events in a list..... With large organizations having many members posting their own events, the membership calendar could be in the grid form to add their post, but the visible calendar would be an Events List with events listed by date with times in ascending or descending order, because many members might post unrelated events during the same time intervals (a grid calendar would become unintelligible). A list could prevent conflicts that a grid calendar would have created. I'll add this comment to the WA wish list post....
The public (and other members) would be able to RSVP (free) to the posting in the member's event calendar.
They could click on the event and read the posting member's event description and then click on any url link included inside that description.
The url could be to a page to pay for the event or registration. A url could direct the public to more details about the event at the member's own website, with Pay Now buttons or whatever. The url link could be to a scheduling platform, so the visiting public could select a session time or something.
Including url details within the Event description box makes this calendar very versatile for members to use.
Your organization's admin might like to spot check event details as a type of quality control. As long as the membership is aware of rules and limits the organization values, there should not be any major issues. At least, admin would not have to post membership events, because that could be a nightmare. Plus, we have found that our membership prefers to post their own; that way if they choose to reword their description or change a date or whatever, they can do it without feeling like they have to impose on anyone, given how we only have kind and considerate members.... :)
Membership would not need to go into the 'administration' side of WA. This membership calendar would be accessed from perhaps a members profile page, if it's possible for WA gurus to design it that way.
We would like to have a calendar for members to post their events on, without admin having to post it for them. This calendar would be available only to certain membership levels, selected from a drop down list for admin. The members must be logged in to add their posts. The Public is able to view the calendar, click on the event to be taken to details. The calendar could be just like the Organizations' event calendar, but it is set up for logged in members to administer. ~Vicki Ellis
As I am increasingly being influenced by this proposal elsewhere on the Wishlist:
I thought that I would experiment here with what the approaches being considered in that proposal would look like with events created by members.
These ideas are based on the hypothesis that everyone potentially has full administrative access to the events module but in reality the organization will restrict that access to meet the organization’s specific management requirements. In principle, everything below would be giving members limited access to the administrative backend.
First, allow events to have a proposed status where they are not yet scheduled into a space-time location. Meetup does this. System users can still register for the proposed event but will have to recommit to the event once it is scheduled. Proposed events can be shown on the calendar gadget. All registration types might have to allow a proposed status followed by a confirmed status in their settings. This is to allow, but not require, the event workflow to start with the membership.
Sets of event information can be saved as an event template which can be instantiated when an event is created. This is to allow administrative control, and standardization of event UIs and data inputs. Meetup just inaugurated this concept in Meetup Pro.
Allow system users, contacts or members, a limited set of administrative roles below the full the administrative event manager role and allow the members access to a limited form of administrative mode to create, edit, and delete events.
The administrative scope of such sub-roles can be limited to read only/create/edit/delete events that are
1) Organized by an individual contact. This is new and many organizations would not want this but my response is that some organizations will want to empower contacts in some ways in order to a) collect revenue from their efforts and b) to induce them into becoming members. It is my personal belief that contacts should be treated as a full system user level below members but that is a separate proposal.
2) Organized by an individual member.
3) Organized by members within the same membership group.
4) Organized by members within a membership level.
5) Later, organized within a chapter.
6) Later, organized within a network of chapters.
Below full administrative control, sub-functions associated with events can be assigned:
1) The ability to propose/create/edit/delete events.
2) Whether an event created by this use requires higher administrative approval to be placed on the schedule as either
a. A proposed event.
b. The actual event itself.
3) Whether the user has the ability to approve another user’s event within one of the above specified administrative scopes.
4) The ability to set event tags for the event, use a defined subset of preset tags, or only one preset tag. In my view there is still need for a central event tag manager at the full administrator level. The event tag feature is a surprisingly powerful feature of Wild Apricot.
5) An adjustable contacts/members access control for sending email invitations to prospective registrants. This can be full access to contacts and searches down to limiting access to zero or more pre-designated saved searches. Later, if social network posting becomes a reality, there would be controls for allowing access to post event invitations to preset social network channels (Facebook, Linked In, etc.)
6) An adjustable access control for allowing users with sub-administrative privileges to overwrite standard email templates used for announcing, registering, and confirming the event.
7) An adjustable access control for allowing members with sub-administrative privileges to set capacity constraints and registration types for the event. For lower access controls, possibly the potential event class described above, and possibly later (if social posting of events on Facebook and Meetup becomes a reality) for registration types that map into social network events, the event might have one or more pre-fixed registration types.
8) One or more event templates can be assigned to certain levels of control.
9) Later, events could be limited to a preset list of venues.
10) Later, events could be assigned to bookable resources.
A subset of these administrative roles and scope can be assigned to individual members, members of a group, or to members of a membership level.
This is not a trivial set of ideas but most of the UI for these controls amount to managed subsets of the existing controls available at the event manager administrative level.
Events are the heart of what an organization does. With the possible exception of serving as a repository of information for members, events are the primary reason why organizations exist. Events work best if they percolate up from the membership.
A few more comments:
1) There need to be more fields than the ones proposed even if this is a first pass at a solution to the problem. Using the information presented under the current proposal if an event is submitted the administrator would still know nothing about the planned fee structure, attendance, or space requirements for the proposed event.
2) Part of why a member will put forward an event is to recruit potential participants and to judge interest in the event. I would suggest allowing such proposed events to have visibility to the membership and to allow members to quickly indicate their interest in such an event, even if this interest does not constitute a formal registration in the event. Going further I would allow the organizer the ability to send an email message to those parties interested in the potential event: scheduling happens not just on the administrator side but on the members' side as well.
I say these comments knowing that this is a first pass at the problem, and matters such as workflow and setting registration levels will be addressed in a later version. My long term advice is to figure out a way to map events and certain event registration levels into Meetup or to socialize Wild Apricot similar to how Meetup copied what Facebook did.
In the long run your competition is not ClubExpress, Tendenci, or MemberClicks....it's Meetup.