How do I build team scheduling with shared calendars?

To build team scheduling with shared calendars, think of it as 4 parts:

1. A shared source of truth for availability
2. A way to create and update events
3. Rules for conflicts, permissions, and time zones
4. A UI that makes scheduling easy

Here’s a practical way to design it.

---

1) Define the core use case

Decide which of these you need:

• Shared team calendar: everyone can see and add events
• Resource booking: book rooms/equipment
• Availability scheduling: find a meeting time for people across calendars
• Assignment scheduling: assign shifts/tasks to team members

Most apps combine these, but the data model differs a bit.

---

2) Model the data

A simple starting schema:

Users

• id
• name
• email
• timezone
• role

Calendars

• id
• name
• owner_type (team, user, resource)
• owner_id
• visibility (private, team, public)
• color

Calendar members

• calendar_id
• user_id
• permission (read, write, admin)

Events

• id
• calendar_id
• title
• description
• start_at
• end_at
• all_day
• location
• status (confirmed, tentative, cancelled)
• created_by
• updated_at

Attendees

• event_id
• user_id
• response_status (needs_action, accepted, declined, tentative)

Availability / working hours

• user_id
• day_of_week
• start_time
• end_time
• is_available

---

3) Shared calendar behavior

A shared calendar usually means:

• Multiple users can view
• Some can edit
• Events can belong to a team calendar instead of a single person
• Users may still have personal calendars hidden from others

Common rules:

• Team members can see team calendar events
• Only admins/editors can modify team events
• Personal events can optionally “block availability” without exposing details

---

4) Handle availability and conflicts

This is the important part.

To find open times:

1. Pull busy events for all required users
2. Merge busy time ranges
3. Compare against working hours
4. Return candidate slots

Conflict detection:

When creating an event:

• Check if the time overlaps an existing event on the same calendar
• Check attendees’ existing commitments if the event requires them
• Optionally allow double-booking with warnings

Overlap logic:

• Two events conflict if new_start < existing_end and new_end > existing_start

---

5) Time zones and recurrence

These can break scheduling if ignored.

Time zones

Store event timestamps in UTC

• Save original timezone separately if needed
• Convert for display in the user’s local timezone

Recurring events

If you need weekly meetings:

• Store a recurrence rule, e.g. RRULE
• Keep exceptions for skipped or changed occurrences

Example:

• Every Tuesday at 10 AM
• Exception: cancel next Tuesday

---

6) Integrate with external calendars

If users already use Google Calendar / Outlook:

• Import events via API
• Sync availability from external calendars
• Optionally export your team calendar

Typical integrations:

• Google Calendar API
• Microsoft Graph Calendar API

Important:

• Use OAuth for consent
• Refresh tokens securely
• Handle sync delays and webhook updates

---

7) Design the API

Example endpoints:

• GET /calendars
• POST /calendars
• GET /calendars/:id/events
• POST /events
• PATCH /events/:id
• DELETE /events/:id
• GET /availability?users=...&start=...&end=...

For scheduling assistance:

• POST /scheduling/suggest-times
  • input: attendees, duration, date range
  • output: available slots ranked by suitability

---

8) Build the UI

Useful screens:

• Month/week/day calendar view
• Team availability view
• Event creation modal
• Attendee picker
• Suggested times panel
• Conflict warnings

Good UX features:

• Drag-and-drop rescheduling
• Color-coded calendars
• “Free/busy” display
• Optional “find a time” assistant

---

9) Permissions and privacy

This is critical for team calendars.

Possible permission model:

• Owner: full control
• Admin: manage members and events
• Editor: create/edit events
• Viewer: read-only
• Free/busy only: see blocks, not titles/details

For privacy:

• Personal events can be hidden except for busy time
• Sensitive calendars should redact event names

---

10) Notifications and collaboration

You’ll likely want:

• Email/push notifications on invite changes
• Reminders before events
• RSVP tracking
• Comments or notes on events
• Audit logs for changes

---

11) Suggested implementation stack

A common stack:

• Frontend: React + calendar UI library
• Backend: Node.js / Python / Go
• DB: PostgreSQL
• Cache: Redis for availability queries
• Jobs: background workers for sync/notifications
• Auth: OAuth / SSO

Calendar UI libraries:

• FullCalendar
• React Big Calendar
• DayPilot

---

12) Start simple

MVP approach:

1. Team calendars
2. Create/edit/delete events
3. Basic conflict checking
4. Shared visibility and permissions
5. Time zone support
6. Availability search

Then add:

• Recurrence
• External calendar sync
• Room/resource booking
• Smart suggestions

---

Example workflow

1. Manager creates “Engineering Team Calendar”
2. Adds team members with editor/viewer permissions
3. Schedules a meeting on the team calendar
4. System checks conflicts against member availability
5. Sends notifications
6. Members RSVP
7. Calendar updates in real time

---

If you want, I can also provide:

• a database schema
• an API design
• a conflict-checking algorithm
• or a sample implementation in React + Node.js