Access is currently limited

manyCalendars is currently at capacity for both free and paid spots. Join the waitlist if you want an email when space reopens. This guide describes the current product and the provider features it can use.

The awkward part of multi client work is not the number of meetings. It is the number of identities. One Outlook account belongs to Client A, another belongs to Client B, your company uses Google Calendar, and your family schedule may arrive through Apple or an ICS feed.

A good setup does not force every calendar through the same connection. It chooses one permitted method per source, labels the source clearly, and uses the least amount of event detail that still prevents a double booking.

Start with a small source map

Before connecting anything, write down one row per calendar. You need only six columns:

  • A neutral source name, such as Client A or Personal.
  • The provider, such as Outlook, Google Calendar, Apple Calendar, or another ICS source.
  • The browser profile or Firefox container where that account is signed in.
  • The connection methods the account owner permits.
  • The detail you are allowed to show outside the source.
  • The person or policy to check if you are unsure.

This quick inventory separates inconvenience from restriction. A calendar that is hard to reach may still have a clean view only sharing option. A calendar that is easy to open may still be prohibited from leaving a managed environment.

Multiple Outlook accounts need separate sessions

Trying to keep two Microsoft 365 tenants in one ordinary browser session tends to produce the wrong account, repeated sign in prompts, or a calendar tab that silently changes identity. Do not solve that by sharing passwords or by constantly signing one client out.

Use a separate browser profile for each company, or use a Firefox container when that level of separation is appropriate. Keep each Outlook tab in the context where it was authenticated. Then choose the least invasive calendar method that tenant permits:

  1. A native view only share, when available.
  2. An ICS subscription, when publishing is permitted.
  3. An approved application, when the tenant accepts it.
  4. A local browser bridge, when you may view the calendar in that session and extension use is allowed.

These methods can coexist. Client A may use an ICS feed while Client B uses a chosen Outlook Web tab. The unified calendar should still show two distinct source colors and two separate freshness states.

Combining Google Calendar and Outlook

Cross provider setups work best when you stop trying to make one provider own the other. Keep Google in its Google account and Outlook in its Microsoft account. Combine read only copies in the viewing layer.

For each source, check native sharing and subscriptions first. Google Workspace administrators can restrict sharing and export. Microsoft 365 administrators can restrict external sharing, publishing, app consent, and extensions. If one provider offers an ICS subscription and the other requires a browser tab, that is still a valid setup.

Remember the difference between an ICS file and an ICS subscription. A downloaded file is a snapshot. A subscription can receive later updates, but the receiving calendar decides when to refresh it. Neither option promises instant changes.

Do not flatten the source labels

A blue block from Client A and a green block from Personal are more useful than ten identical blocks called Work. The color and source label tell you where to open the original event when something changes.

Keep browser sessions separate on purpose

Firefox Multi Account Containers separate cookies and logins between color coded tabs inside one profile. Full browser profiles separate more, including browsing data, extensions, and settings. Chrome and Edge also support multiple profiles.

A simple naming system helps:

  • Use the same neutral client name in the browser and in manyCalendars.
  • Give each client a stable color.
  • Pin only the calendar tab you actually use for that source.
  • Do not reuse one profile for unrelated client accounts.
  • When a contract ends, remove the source and close that browser context.

Session separation reduces accidental account crossover. It does not grant permission to copy data. The client agreement and organization policy still decide what may leave the source.

Choose the smallest useful event payload

Most people do not need meeting descriptions, attendee lists, attachments, or video links in a combined calendar. To answer "Can I take a call at 2?" the useful fields are usually:

  • Start and end time.
  • Busy, free, tentative, or out of office status when available.
  • A source label and color.
  • A refreshed time, so you can spot a stale source.

manyCalendars uses busy only details by default for Cloud Sync. Privacy Mode can also mask event and calendar names as Busy while leaving source colors visible. That is useful on a shared screen, but it is a display safeguard, not permission to transfer restricted data.

How manyCalendars handles local and web access

The browser extension is the main product. It keeps calendar information on that device unless you choose Cloud Sync. Provider passwords and session cookies stay inside their original browser profiles.

The companion web calendar is optional. To show the same combined view on another device, Cloud Sync copies only the calendars you select to your private web account. If you do not need web access, leave Cloud Sync off and the calendar stays in the extension.

The view is read only. manyCalendars does not edit the source calendar, accept meetings, decline invitations, or create duplicate busy blocks inside a client tenant.

Build a setup that fails visibly

Every calendar connection gets stale eventually. A browser can suspend a background tab, a work session can expire, an ICS receiver can refresh slowly, or a provider can change its page. A combined calendar should show which source needs attention instead of quietly presenting old events as current.

Before relying on the view, make three checks:

  1. Change a harmless test event in the original calendar and confirm that the copy updates.
  2. Sign one source out and make sure the combined view labels it as stale or disconnected.
  3. Remove the test source and confirm that its copied events disappear without affecting the original calendar.

A sample connection plan

CalendarPractical methodDetail in the combined view
Personal Google CalendarPermitted sharing, ICS, or a chosen browser tabYour choice
Client Outlook with publishingICS subscriptionBusy time or the published level
Client Outlook visible only in its sessionLocal browser bridge, if allowedBusy only by default
Apple or school calendar with a feedICS subscriptionWhat the feed exposes
Client forbids external toolsReview in the original systemNothing leaves the source

Official sources

Keep the accounts separate. See the week together.

manyCalendars is currently at capacity. Join the waitlist and we will let you know when a free or paid spot becomes available.

Join the waitlist

Facts reviewed August 25, 2026. Calendar providers and organization policies change, so verify the current rules for every account you use.