Any organization that accepts events from artists, partners, or members eventually hits the same wall: getting a submission from someone’s inbox onto a published calendar without retyping it at every stage. This guide covers what a good submission process needs to do, the three approaches organizations typically try, and a seven-step model built around one idea — the event should move through the workflow, not get rebuilt at each step of it.
Any organization that accepts events from artists, partner organizations, or members eventually asks the same question: how do you get a submission from someone’s inbox onto a published calendar without someone retyping it by hand at every stage?
The instinct is to treat this as an intake problem — find a better way to collect information. That’s part of the answer, but not the core of it. The real question is what happens to event information after it’s collected: whether it moves through the organization as one record, or gets rebuilt from scratch every time it reaches a new system.
What Is an Event Submission Workflow?
An event submission workflow is the path a piece of event information follows, from the moment someone reports it to the moment it reaches every channel used to publicize it — a website, a newsletter, a screen, a printed flyer.
A submission form collects information. A submission workflow determines what happens to that information afterward: who reviews it, where it sits while under review, how it becomes public, and how it reaches every other channel.
What a Good Event Submission Process Should Do
A submission process that holds up as volume grows needs to:
- Collect complete, structured information — not a free-text message
- Validate that required fields are present before a submission can be made at all
- Keep submissions private until they’ve been reviewed
- Provide a human moderation step
- Prevent the same event from being entered more than once
- Publish approved events without rebuilding them in a second system
- Distribute published events to every channel the organization uses
- Keep updates synchronized across all of those channels when a detail changes
Missing any one of these is usually where a workflow that looked fine at low volume starts to break.
Three Common Ways Organizations Collect Events
Email or Direct Message Submissions
The starting point for organizations that accept public submissions is email or a direct message. A contributor writes in and describes their event in their own words.
This works as an intake channel. It fails as a workflow, because everything after that message arrives depends on someone manually carrying information from one place to another — reading it, deciding whether it fits, forwarding it, and retyping the details into a calendar. Each handoff is a place a date can be transposed, a message can sit unread, or a missing detail can go unnoticed. None of that requires anyone to be careless. It’s a structural property of a workflow built on retyping information by hand.
Structured Submission Forms
The natural next step is a form — a Google Form or an equivalent — with required fields for date, time, description, and image.
A form solves one specific problem: it stops incomplete submissions from arriving in the first place. A contributor can’t submit without providing what the form requires.
An event submission form collects information. An event submission workflow determines what happens to that information afterward — and a form, by itself, doesn’t answer that. Someone still has to open every response, decide whether anything needs editing, and manually build a calendar entry from it. The input is cleaner. It still passes through a human retyping it into a second system before it becomes a calendar entry.
Calendar-Based Submissions
The third approach changes what the “submission” actually is. Instead of sending a message or a form response for someone else to convert, the contributor creates the event directly on a calendar — a private one, visible only to the organization’s moderators.
The event exists as a real calendar record the moment it’s submitted, not as a message waiting to be converted into one. This is the approach the rest of this guide builds on.
The idea this diagram is built around: the event is never recreated. It moves. It starts as one record on a private calendar, gets edited in place if it needs editing, and is reassigned to the public calendar when it’s approved. Nothing downstream is a second copy — it’s the same record, now visible somewhere new.
How to Build This Workflow, Step by Step
Step 1: Define the required event fields. Decide what a submission needs before it can be considered complete — typically name, date, start and end time, location, description, organizer, contact information, image, and category. Add accessibility or ticketing fields if they’re relevant to your programming.
Step 2: Give contributors a way to create the event record directly. The goal is for the contributor to produce the record itself, not a description someone else has to convert into one. A calendar invite, a shared submission calendar, or an integration that writes directly to one all accomplish this.
Step 3: Route submissions to a private draft calendar. This calendar functions as the moderation queue. Nothing on it is visible outside the organization until someone approves it.
Step 4: Review before publication. A moderator checks whether the submission is relevant, complete, and accurate, whether it conflicts with anything already scheduled, and whether anything needs to be edited or removed before it’s appropriate to publish.
Step 5: Publish by moving the event, not recreating it. Reassign the approved event from the draft calendar to the published one. The record itself relocates — nobody rebuilds it.
Step 6: Distribute the published event automatically. Once an event is on the published calendar, it should be able to reach a website widget, an email newsletter, a venue screen, or a QR code without anyone re-entering it in any of those places individually.
Step 7: Update the record once when details change. If a time, location, or description changes after publication, edit the one record. Every channel drawing from it should reflect the change without a second round of manual updates.
Why a Single Source of Truth Matters More Than Initial Entry
The argument so far has focused on avoiding retyping an event once, at intake. The bigger risk shows up later, when a detail changes.
Consider an event that moves from 7:00 PM to 7:30 PM after it’s already published. In a workflow without a single source of truth, that change has to be applied separately to the calendar, the website, the newsletter that already went out or hasn’t yet, any printed material, and whoever handles social media. Each of those is a separate manual edit, and there is no guarantee all of them happen, or happen correctly. It’s entirely possible for the website to say 7:30 while a printed flyer still says 7:00.
A single source of truth removes that risk by definition. The record only exists in one place. Every channel displaying it is reading from that one place, not from a copy someone made of it. Updating a detail once is not just less work — it’s the only way to guarantee every channel agrees with every other channel.
What “Shared” Calendar Access Actually Means
Describing this as a “shared drafts calendar” can sound like it means giving outside contributors broad access to an organization’s internal systems. In practice, the access involved is narrow and specific:
- Contributors can add an event to the draft calendar. They cannot see other people’s submissions, and they cannot edit or delete events that are already published.
- Moderators are the only people who can move an event from draft to published.
- A contributor doesn’t need a login to the organization’s website or CMS to submit an event — the interaction happens entirely at the calendar level.
- Spam or clearly irrelevant submissions are caught at the review step, the same way they would be with any other intake method — they simply never reach the published calendar.
The word “shared” describes where a submission is reviewed, not a grant of general access to the organization’s systems.
Email vs. Form vs. Calendar-Based Workflow
| Approach | Structured data | Review step | Manual re-entry | Scales well |
| Email / DM submissions | No | Yes | High | No |
| Form -> manual calendar entry | Yes | Yes | Medium | Limited |
| Direct submission to a draft calendar | Yes | Yes | Low to none | Yes |
Automating Submissions Without Removing Human Review
None of this is an argument for removing moderation. A submitted event still needs someone to decide whether it’s relevant, complete, and appropriate to publish — that step doesn’t go away, and it shouldn’t.
What a well-built workflow removes is the repetitive work that tends to surround that decision: copying a date, a time, a description, and a link from one system into another every time an event moves from submitted to published to distributed. Automating that movement doesn’t reduce editorial control. It removes the parts of the process that were never editorial in the first place.
The Principles Behind a Scalable Submission Workflow
- Collect structured data. Don’t require staff to extract event details out of a free-text message.
- Separate submission from publication. A submitted event should not automatically become public.
- Review the event where it will actually live. Don’t make a moderator recreate an event just to approve it.
- Never duplicate the event unnecessarily. Move or edit the original record instead of creating a second copy of it.
- Keep one source of truth. Every channel should read from the same underlying event data.
How Revisual Implements This Workflow
Revisual supports the model above directly. Contributors submit events to a private draft calendar. Moderators review submissions there, with the draft and published calendars viewable together so scheduling conflicts are visible before anything goes live. Approving an event means reassigning it to the published calendar — the record moves, it isn’t recreated. From there, distribution to a website widget, email, venue screens, and QR codes happens automatically from that single published record, and an edit made after publication propagates to every connected channel without a second manual update.
Frequently Asked Questions
Collect event information in a structured format, route submissions into a private review queue, and publish approved events by moving them rather than recreating them in a second system. Treating the submitted event as the primary record — instead of a message that gets converted into one — removes the retyping step at every stage that follows.
A form is an improvement over email because it enforces complete, structured information at intake. It does not remove the need to manually build a calendar entry from each response. A calendar-based submission, where the contributor creates the event record directly, removes that step because the record already exists in its final format from the moment it’s submitted.
Automate the movement of event data between systems, not the decision to publish it. A private draft calendar can hold every submission for review; moderators still decide what gets approved, edited, or rejected. What automation removes is the manual retyping between submission, approval, and distribution — not the review step itself.
Route submissions to a calendar that isn’t publicly visible. A moderator reviews each entry there, checking for relevance, completeness, accuracy, and conflicts with existing programming, and edits the entry directly if anything needs to change before approving it.
Treat the submitted event as the one record that will eventually be published, rather than information that gets copied into a new entry at each stage. If the event is moved — reassigned from draft to published — instead of recreated, there is only ever one copy of it to begin with.
Connect a website widget, email newsletter, venue screen, or QR code to the same published calendar record, rather than entering the event separately into each of those channels. When the underlying record updates, every connected channel updates with it.
Use a workflow where moderation happens entirely at the calendar level. This removes the need to grant or manage website or CMS access for a team that changes membership over time, and it keeps the review step lightweight enough for a volunteer to handle without additional training on other systems.
Reassignment. Moving an event to a different calendar is the more reliable mechanism, because the event’s location is unambiguous — it belongs to whichever calendar it’s currently assigned to. Tags are useful when an event needs to appear on more than one calendar at once, but for a straightforward draft-to-published move, reassignment is the default.
No. Contributors can submit directly to a calendar, and moderators can review and publish from that calendar without either party needing website access. The website is one possible destination for a published event, not a requirement for submission or review.
Yes. The submission and moderation steps happen entirely at the calendar level. A contributor adds an event to a private draft calendar; a moderator reviews and approves it from there. Neither role requires a login to the website or CMS at any point.
About the author
Piotr Pozniak
Piotr’s is the cofounder of Revisual, a dedicated tool for seamlessly sharing events. With over six years of experience developing the platform, he brings extensive expertise in streamlining business processes through technology solutions. Work with partners across industries has honed his ability to optimize event workflows and enhance data accessibility.
Streamline, Sync, and Share Your Events Seamlessly
