Build an event sign-up system in SharePoint without overbooking

If two people can see the last available seat, both can press Register.

That is the part most SharePoint event-registration tutorials skip. A seat check in Power Apps improves the form, but it does not reserve a place. Another registration can arrive between the check and the save.

For a modest internal event, you can still build a useful registration system with Microsoft Lists, Power Apps and Power Automate. The safe design treats every new request as Pending until a back-end process accepts, waitlists or rejects it.

It is not a ten-minute build, and SharePoint is not a ticketing database. This guide shows what the Microsoft 365 approach can do, where it can fail, and when to use a product with capacity management already built in.

The short answer

Use two SharePoint lists:

• Events stores the date, capacity, registration window and current confirmed count.
• Registrations stores one person's request and a status such as Pending, Confirmed, Waitlisted or Cancelled.

Use Power Apps to present the form and warn when an event appears full. Use one Power Automate flow to make the final decision after submission. For controlled internal demand, setting that flow's trigger concurrency to one reduces race conditions because only one run processes at a time.

There are still important limits. Microsoft documents a finite queue when trigger concurrency is enabled. With degree of parallelism set to one, 11 additional runs can wait. Later triggers may not become runs if that queue stays full. Separate flows, direct list edits and partial flow failures sit outside that single-file line.

So the honest rule is:

A Power Apps seat check is advisory. A serial acceptance flow is a practical control for low-volume internal events. Neither turns SharePoint into a transactional booking engine.

If the number of seats must be guaranteed during a burst, use Microsoft Bookings, Dynamics 365 Customer Insights - Journeys or a specialist event platform after testing it against your exact requirements.

Choose the right Microsoft tool first

Do not start with Power Apps merely because it is flexible. Start with the event and the failure you cannot tolerate.

Option	Good fit	Where it stops fitting
Microsoft Forms	A simple RSVP, expression of interest or survey where you mainly need to collect responses	You must design any capacity, waitlist, cancellation and acceptance process around the form
Microsoft Bookings	Appointment-style or group sessions tied to staff calendars	It is less suitable when you need a highly customised internal workflow, complex approvals or a multi-session conference model
SharePoint + Power Apps + Power Automate	Internal events requiring custom fields, organiser views, approvals and Microsoft 365 integration	Capacity protection is an application design, not a native transaction; bursts and partial failures need explicit handling
Dynamics 365 Customer Insights - Journeys	Customer-facing events, sessions, marketing journeys, registration records and check-in	It introduces a larger product, implementation and licensing commitment
Specialist event platform	Paid tickets, public scale, venue plans, scanning, refunds or contractual capacity guarantees	Extra cost, procurement, integration and data-governance work

Microsoft Forms is designed for registrations and other forms, but a response is not the same thing as an accepted seat.

Microsoft Bookings supports group services with a maximum number of attendees. It also manages the appointment against staff availability and can send confirmations and reminders. If that matches the job, use it before building your own counter.

Dynamics 365 Customer Insights - Journeys has a formal event-registration model, including event and session registrations. That is a more natural fit for customer events, tracks and check-in journeys.

The SharePoint architecture

The key design choice is to separate the event from the registration requests.

One event can have many registrations. Keeping those records apart gives you an auditable status for each person and prevents attendee details from being copied into the event record.

1. Events list

Create a standard list called Events. Suggested columns are:

Column	Type	Purpose
Title	Single line of text	Event name
Start	Date and time	Start date and time
End	Date and time	End date and time
Time zone	Choice or text	Time-zone context for display and calendar messages
Capacity	Number	Maximum confirmed attendees
Confirmed count	Number	A working counter maintained by the acceptance process
Registration opens	Date and time	Earliest accepted submission
Registration closes	Date and time	Cut-off for new requests
Registration state	Choice	Draft, Open, Closed or Cancelled
Waitlist enabled	Yes/No	Whether excess requests may wait
Location or join URL	Text or hyperlink	Venue or online meeting details
Event owner	Person	Person responsible for decisions and attendee data

Index columns used by organiser views and flows, particularly registration state and dates, once the list becomes busy. Do not use the Events list to store a growing collection of attendee names.

2. Registrations list

Create a second list called Event Registrations:

Column	Type	Purpose
Event	Lookup to Events	The requested event
Attendee	Person	Best choice for an internal-only system
Attendee email	Single line of text	Use only when the design genuinely needs a separate address
Status	Choice	Pending, Confirmed, Waitlisted, Rejected or Cancelled
Submitted at	Date and time	When the request arrived
Processed at	Date and time	When the decision was made
Decision reason	Choice or text	Closed, Full, Duplicate, Invalid or another controlled reason
Confirmation sent at	Date and time	Evidence that the notification step completed
Cancellation requested	Yes/No	Starts the cancellation process without deleting the record

Set Pending as the default status. Do not let the form submit a record as Confirmed.

If this is internal, a Person column is usually safer than asking people to type an email address. It gives you a stable organisational identity and avoids typos. External registration changes the identity, privacy and abuse model; assess Bookings, Forms, Power Pages or a specialist platform before opening a SharePoint-backed app to guests.

Why the form cannot own capacity

Power Apps can look up the selected event, show its confirmed count and disable the submit button when the displayed number has reached capacity.

That is useful feedback. It is not the final control.

The app reads one state, renders it, and waits for a person to act. During that gap, another user or process can change the data. A user might also keep an old form open, lose connectivity, retry a submission or reach the list through another route.

There is a second trap: counting SharePoint rows in the app. Microsoft explains that CountRows and CountIf do not delegate to SharePoint. For a nondelegable query, Power Apps processes only the first 500 records by default, or up to 2,000 if the author raises the limit. A local count can therefore look correct during testing and become wrong as registrations accumulate. See Microsoft's delegation guidance.

For this pattern, show the stored Confirmed count in the app. Treat it as an indication for the user, then recheck it in the acceptance flow.

Build the registration form

You can customise the SharePoint list form or build a standalone canvas app. Microsoft documents the list route as Integrate > Power Apps > Customize forms in the list command bar. See Customize a form for a SharePoint list.

The form should do five jobs:

1. Show only events that appear open.
2. Display the event date, time zone, location and current availability clearly.
3. Capture the minimum attendee details.
4. Save the request as Pending.
5. Tell the person that the request is being processed, not that the seat is confirmed.

Avoid a confirmation screen that says “You are booked” immediately after SubmitForm. At that point, SharePoint has only stored a request.

Use wording such as:

We have received your request. Your place is not confirmed until you receive the confirmation message.

You may disable the button when the event appears full or closed. Keep the server-side rejection path anyway.

The app is not a security boundary

Hiding a field or screen in Power Apps does not secure the underlying SharePoint data.

Microsoft's app-sharing guidance says makers must also manage access to the app's data sources and dependent resources. See Share a canvas app with your organisation.

Use a dedicated site or list with deliberately designed permissions. Test as a normal attendee, not as the owner:

• Can the attendee open the list directly?
• Can they browse another person's registration?
• Can they edit Status or Confirmed count?
• Can they export attendee data?
• Can they use a saved view, API or old link to bypass the intended screen?

If attendees need to create registrations but must not see other records, configure and test the SharePoint permission model for that requirement. Do not assume that an embedded app or hidden navigation protects the list.

Build the acceptance flow

Create one automated cloud flow triggered when a record is added to Event Registrations.

Keep the logic in one controlled path:

1. Read the new Pending registration.
2. Read the linked Event again.
3. Check that the event exists, is Open and is within its registration window.
4. Check for an existing active registration for the same person and event.
5. Read the current Confirmed count and Capacity.
6. If a seat is available, increment the count and mark the registration Confirmed.
7. If no seat is available, mark it Waitlisted or Rejected according to the event setting.
8. Send the appropriate message only after the status update succeeds.
9. Record Processed at, Decision reason and Confirmation sent at.

Do not delete rejected or failed registrations inside the main flow. A status and reason are easier to diagnose, reconcile and retain according to an agreed policy.

Serialise the flow—but understand the boundary

Open the trigger settings, enable Concurrency control, and set Degree of parallelism to 1.

Microsoft's trigger guidance says this allows one instance of the flow to run at a time and can reduce dirty reads. Microsoft also warns that the setting cannot simply be undone; removing it requires recreating the trigger. Make a copy of the flow before changing it.

This setting is a mitigation, not a universal lock:

• It serialises runs of this trigger, not every possible writer to the SharePoint lists.
• A second flow or an administrator can still change the same event.
• The update of the event counter and the update of the registration are separate operations. A failure between them can leave the data out of step.
• Power Automate's current limits allow 10 + degree of parallelism waiting runs when trigger concurrency is on. More triggers may be retried, but Microsoft says those retries might not succeed while the queue remains full.

At degree one, that means one run executing and up to 11 waiting. Test a burst above that threshold if your event announcement may cause everyone to register at once.

Handle partial failures

Suppose the flow increments Confirmed count and then fails before marking the registration Confirmed. The counter and the registration records now disagree.

Add an explicit failure branch and an organiser alert. Also create a reconciliation view or scheduled check that compares the stored counter with the actual Confirmed registrations and flags differences. When using Get items for that check, filter on the Event and Status on the server and configure pagination according to the volume; do not quietly process only a default page of results.

For a business-critical system, document which record is the source of truth and how an organiser repairs a mismatch. A silent retry is not a recovery plan.

Cancellations and waitlists are part of capacity

A system that only adds seats is not finished.

When a confirmed attendee cancels:

1. Mark the registration Cancelled rather than deleting it.
2. Reduce the confirmed count through the same controlled processing path.
3. If a waitlist is enabled, select the next eligible Pending or Waitlisted request using a documented ordering rule.
4. Recheck capacity before promoting that request.
5. Send a new confirmation and record when it was sent.

Decide how long a promoted attendee has to accept. If a human organiser chooses who gets a released place, say so in the event terms instead of implying strict first-come, first-served processing.

Also decide what happens when an organiser reduces Capacity below the number already confirmed. The safest response is to flag the event for manual resolution, not automatically cancel people.

Notifications and calendar entries

Send different messages for Pending, Confirmed, Waitlisted, Rejected and Cancelled. Only the Confirmed message should contain language that promises a place.

For internal events, a flow can use the Office 365 Outlook connector to send email or create an event from an organiser mailbox. Test the connection owner, mailbox licensing, data-loss-prevention policies, time zone and daylight-saving cases in the target tenant.

Do not send the notification before the status update. If the email step fails after confirmation, keep the registration Confirmed, record that the notification is missing and give the organiser a resend route. Otherwise, retry logic can create duplicate registrations or calendar entries.

If calendar scheduling, staff availability and reminders are the main requirement, Bookings is likely the simpler design.

Privacy and governance

Names, email addresses, accessibility requirements and dietary information can all be personal data. Collect only what the event team needs.

Before launch, record:

• the purpose for collecting each field;
• who can see attendee data;
• how long registrations are retained;
• how cancellations and deletion requests are handled;
• whether data is exported and where those files go;
• who owns the app, flows, connections and lists when the original maker leaves.

Do not claim that a label, app or Microsoft 365 licence makes the system “GDPR compliant”. Compliance depends on the organisation's purpose, legal basis, controls and operating process. Ask the appropriate privacy or legal owner to review fields and retention for the real event.

Licensing also depends on the tenant's Microsoft 365 and Power Platform plans and on the connectors you use. SharePoint and Office 365 Outlook are listed as standard connectors, but adding Dataverse, custom connectors, premium connectors or unattended automation can change the licence requirement. Verify the design against the current licensing guide before rollout.

Accessibility is a test, not a theme

Power Apps includes an Accessibility checker, but Microsoft says its suggestions still need to be considered in the context of the app. See Review a canvas app for accessibility.

At minimum:

• give every interactive control an accessible label;
• keep a logical keyboard and focus order;
• do not communicate Full, Confirmed or Error by colour alone;
• show validation beside the affected field and in a summary;
• use readable text and sufficient colour contrast;
• test zoom, mobile layout and text expansion;
• complete a keyboard-only run;
• test with the screen-reader combinations your organisation supports.

Include an alternative registration route and a named contact. An event form should not become the reason somebody cannot attend.

Test the failure cases

The happy path proves very little. Run these tests with non-owner accounts:

1. Two people submit for the final seat at nearly the same time.
2. More than 12 requests arrive while the serial flow is still busy.
3. The same person presses Register twice.
4. A form left open overnight submits after registration closes.
5. The event is cancelled while a request is Pending.
6. The counter update succeeds but the registration update fails.
7. The registration is Confirmed but the email fails.
8. A confirmed attendee cancels while someone is waitlisted.
9. An organiser reduces Capacity below the confirmed total.
10. An attendee follows a direct link to the Registrations list.
11. A user works with keyboard navigation, screen reader and 200% zoom.
12. The event crosses a daylight-saving change or includes people in another time zone.

Record the expected result for each test before running it. Keep screenshots or run IDs for failures and repeat the test after any flow or list change.

Check your work before launch

You should be able to answer “yes” to each statement:

• A new request is Pending until the back-end process decides it.
• The form never promises a seat based only on its displayed count.
• Only one controlled flow updates capacity for normal registrations and cancellations.
• Flow concurrency, queue limits and recovery behaviour have been tested.
• Duplicate, closed-event, full-event and cancellation paths have visible outcomes.
• Attendees cannot browse or edit other people's registration data.
• The app and its data source permissions have both been reviewed.
• The flow has more than one owner or a documented service-ownership arrangement.
• The accessibility checker and manual accessibility tests have been completed.
• Retention, exports and event-owner responsibilities are documented.
• A reconciliation route exists when the counter and registrations disagree.
• The team knows the demand or feature threshold that would trigger a move to Bookings, Dynamics or a specialist platform.

When not to build this in SharePoint

Do not use this pattern as the sole booking control when you need:

• paid tickets, refunds or tax handling;
• a contractual guarantee that capacity cannot be exceeded;
• a public launch likely to create a registration spike;
• reserved seating or venue maps;
• multiple sessions, passes or complex attendee journeys;
• anonymous internet access with strong abuse protection;
• on-site scanning, badges or live check-in at scale;
• audited allocation rules that must behave transactionally.

SharePoint is good at internal records, collaboration and configurable workflows. Knowing where it stops is part of building well.

Frequently asked questions

Can SharePoint stop two people taking the last event seat?

Not through a Power Apps button check alone. A single acceptance flow with trigger concurrency set to one can serialise low-volume decisions, but SharePoint list updates are not one atomic booking transaction. Queue limits, other write paths and partial failures still need handling.

Does Power Automate concurrency set to one guarantee no overbooking?

It guarantees that only one run of that trigger executes at a time. It does not lock every other flow, user or process, and Microsoft limits the number of waiting runs when concurrency is enabled. Treat it as a useful control for a bounded internal workload, not a universal guarantee.

Do I need Power Apps Premium for this system?

That depends on the licences and connectors in the final design. SharePoint and Office 365 Outlook are standard connectors, but Dataverse, premium or custom connectors and other capabilities can change the requirement. Check the current tenant entitlements before rollout.

Can external guests use a SharePoint event-registration app?

They need suitable access to the app and its data source, which introduces identity, sharing and privacy decisions. For public or mixed-audience registration, compare Microsoft Bookings, Microsoft Forms, Power Pages, Dynamics 365 Customer Insights - Journeys and specialist platforms before exposing a SharePoint-backed design.

Should attendees be able to open the Registrations list?

Only if the SharePoint permission design prevents them seeing or changing data they should not access. Hiding the list link or fields in Power Apps is not a security control. Test the direct list URL with an attendee account.

Keep your SharePoint and Microsoft 365 decisions current

The hard part is rarely adding another list column. It is knowing which Microsoft 365 mechanism is safe for the job and where a low-code workaround becomes an operational risk.

Join SharePoint & Teams Admins for current, human-audited guidance on SharePoint, Teams and Microsoft 365 administration.

Official Microsoft sources

• Customize a form for a SharePoint list
• Power Apps delegation and query limits
• Use delegation to keep Power Apps data payloads small
• Share a canvas app and manage its data-source permissions
• Optimize Power Automate triggers and concurrency
• Power Automate concurrency and waiting-run limits
• Review a canvas app for accessibility
• Define a Microsoft Bookings service
• Microsoft Forms service description
• Dynamics 365 event and session registration