How to Find a Shared Calendar ID for Power Automate

To find an Outlook calendar ID in Power Automate, run Office 365 Outlook — Get calendars (V2) with the same connection that will read or create the event. In the run output, match both the calendar name and owner, then use its returned id as the Calendar id custom value.

That answer only applies to Outlook calendars the connection can access. A Microsoft 365 group/Teams calendar uses a group ID and the Office 365 Groups connector. A SharePoint calendar is a list and uses a SharePoint list ID. They are different resources.

The older version of this article mixed those IDs together and suggested unsupported URL/Copilot shortcuts. This guide starts by identifying what you actually own.

Identify the calendar type first

Calendar you mean	Owner/resource	Power Automate starting point	Identifier
Your default or secondary Outlook calendar	The Office 365 Outlook connection user	Get calendars (V2), then Outlook calendar actions	Outlook calendar ID
Another user's shared/delegated calendar	That user, shared with the connection account	Get calendars (V2) after sharing/delegation is accepted	ID returned in the mailbox context you use
Shared mailbox calendar	The shared mailbox, accessed by the connection account	Confirm mailbox permission, then Get calendars (V2) and test the relevant Outlook action	Outlook calendar ID visible to that connection
Microsoft 365 group or Teams-backed group calendar	Microsoft 365 group	Office 365 Groups — Create a group event (V2)	Microsoft 365 group ID
SharePoint calendar/list	SharePoint site/list	SharePoint connector actions	SharePoint list GUID—not an Outlook calendar ID
Room/resource mailbox calendar	Exchange resource mailbox	Access/booking configuration plus Outlook/Exchange route appropriate to the process	Mailbox/calendar context, not a SharePoint GUID

If you cannot name the owner, stop. A display name such as “Marketing Calendar” is not enough; two mailboxes can contain calendars with the same name.

Method 1: use Get calendars (V2)

The current Office 365 Outlook connector documents Get calendars (V2). It returns a list containing each available calendar's id, name and owner.

Build a small discovery flow

1. Create a manual cloud flow.
2. Add Office 365 Outlook — Get calendars (V2).
3. Select or create the same Office 365 Outlook connection that the production calendar action will use.
4. Save and run the flow.
5. Open the successful run.
6. Expand Get calendars (V2) and view its raw outputs.
7. Inspect body.value.
8. Match the required calendar by both name and owner.
9. Copy the matching id exactly.

The output is conceptually like this:

{
  "value": [
    {
      "id": "calendar-id-returned-by-the-connector",
      "name": "Operations",
      "owner": "operations@contoso.com"
    }
  ]
}

Do not copy the placeholder above. Use the ID from your own run.

Use the ID in the calendar action

In Create event (V4), Get events (V4) or the calendar trigger you actually need:

1. Use the same Office 365 Outlook connection.
2. Open the Calendar id field.
3. Select Enter custom value if the picker does not show the calendar.
4. Paste or dynamically supply the id returned by Get calendars (V2).
5. Create a disposable test event.
6. Confirm it appears in the intended calendar and can be read back by the connection.
7. Delete the disposable event.

Read and write are separate proofs. Seeing a calendar does not automatically prove that the connection can create or change events in it.

Why a shared calendar may be missing

Microsoft's connector reference says shared calendars appear in calendar pickers only when the connection user has view and edit access. It recommends Get calendars (V2) to list calendars and access.

Check these boundaries:

1. The owner shared the correct calendar

The calendar owner should share/delegate the actual calendar in Outlook. A forwarded event, shared link or Teams membership is not the same as calendar permission.

2. The connection uses the expected account

Open the connection on each calendar action. Makers often test successfully with their personal connection, then deploy a flow whose owner or connection reference is different.

3. The connection has enough permission for the operation

Viewing a calendar is not the same as editing it. If the flow creates, updates or deletes events, test that operation with the production connection identity.

4. Sharing/delegation has been accepted where required

For another user's shared/delegated calendar, complete the Outlook sharing workflow. Microsoft Graph's shared calendar guidance distinguishes direct access to the owner's calendar from the recipient's local shared copy.

5. The connection is stale

After confirming the permission in Outlook, refresh or recreate the connector connection if the calendar list remains stale. Microsoft documents that permission changes can take time to appear, but do not replace permission diagnosis with a promised fixed waiting period.

Shared and delegated user calendars: mailbox context matters

Microsoft Graph supports calendars that another user has shared or delegated. It also warns that an owner mailbox's calendar ID and a share recipient's local-copy calendar ID can be different.

That means these contexts are not interchangeable:

/users/owner@contoso.com/calendars/{owner-context-id}

/me/calendars/{recipient-context-id}

Use the ID returned from the context in which you will make the later call. Do not discover an ID under one mailbox path and paste it into another path.

For a Power Automate connector flow, this is why using Get calendars (V2) with the same connection is such a good first move: discovery and use stay in one connector identity/context.

Shared mailbox calendars

A shared mailbox has its own calendar. The connection account needs the access required by the intended operation.

Use this sequence:

1. Confirm the exact shared mailbox address.
2. Confirm the flow connection account and its mailbox permissions.
3. Open the shared mailbox/calendar in Outlook with that account and verify the expected access.
4. Run Get calendars (V2) using that same connection.
5. Match the owner and name in the output.
6. Use the returned ID in a disposable read/write test.

Do not assume that an email trigger's Original Mailbox Address field makes every later calendar action operate in that mailbox. Inspect the connection and each action's documented inputs.

If a connector action cannot perform the required shared-mailbox operation in your tenant, use a governed Graph design with the correct permissions rather than substituting a Microsoft 365 group action. A shared mailbox is not a group.

Microsoft 365 group and Teams calendars

A Team is backed by a Microsoft 365 group, and that group has a default calendar. It is not another user's shared Outlook calendar.

For Power Automate, the current Office 365 Groups connector includes Create a group event (V2).

Use:

• the group's ID in the group action;
• the Office 365 Groups connection and its permissions;
• a disposable group event to prove the route.

Do not paste the group ID into an Office 365 Outlook Calendar id field.

Microsoft Graph exposes group calendar routes such as:

GET /groups/{group-id}/calendar
POST /groups/{group-id}/events

Microsoft's create group event documentation currently lists delegated Group.ReadWrite.All and says application permission is not supported for that operation. An app registration, client secret or managed identity is therefore not an automatic fix for unattended group-event creation.

Graph fallback for Outlook calendars

Use Graph when the connector actions do not cover a governed requirement and you understand the permission model.

Microsoft documents calendar discovery routes such as:

GET https://graph.microsoft.com/v1.0/me/calendars?$select=id,name,owner

GET https://graph.microsoft.com/v1.0/users/shared@contoso.com/calendars?$select=id,name,owner

The exact permission depends on the operation and access type. Reading, creating and updating are not the same permission boundary. Shared/delegated access also depends on the Outlook relationship between owner and delegate.

If you use Graph:

• make the calling identity explicit;
• request only the permissions required;
• match calendar name and owner;
• store the identifier as configuration rather than scattering it across actions;
• log the target owner/calendar during rollout;
• test in the same delegated or application context as production;
• design retries so a timeout cannot create duplicate events.

IDs you should not use

A SharePoint list GUID

A SharePoint calendar/list ID belongs to the SharePoint connector. It is not an Outlook calendar ID and cannot be made into one by removing braces or decoding a URL.

An event ID

An event ID identifies one event, not the calendar that contains it.

An iCalUId

iCalUId helps identify an event across calendars. It is not the containing Outlook calendar's ID.

A browser URL fragment

Outlook web URLs contain routing and encoded state. Microsoft does not document copying a random URL fragment as the supported Power Automate calendar-ID method.

A Copilot answer

Copilot can help explain a flow, but it does not establish the authenticated mailbox context or permission. Use a connector/Graph discovery call and prove the result.

Avoid hard-coding when the calendar varies

If the flow targets one governed calendar, store the verified ID in an environment variable or other controlled configuration.

If users select among several permitted calendars:

1. run Get calendars (V2);
2. present or filter the returned calendars by name and owner;
3. pass the selected id to the calendar action;
4. reject owners/calendars outside the permitted set;
5. record the selected owner and ID for support.

Do not let an untrusted request body provide an arbitrary mailbox or Graph path in a high-privilege flow.

Event acceptance test

After finding the ID, prove the calendar operation:

• create a uniquely named disposable event;
• use an explicit time zone;
• read it back from the intended calendar;
• update one field;
• test an all-day event if required;
• test recurrence if required;
• verify daylight-saving behaviour across a transition date;
• delete the disposable event;
• confirm a normal production user sees the expected result;
• record the connection identity, calendar owner and date tested.

For recurring absence rather than calendar discovery, see our weekly scheduled out-of-office guide. Automatic replies and calendar events are related user experiences but different Exchange settings.

Frequently asked questions

How do I get a shared calendar ID in Power Automate?

Run Office 365 Outlook — Get calendars (V2) using the same connection as the later action. In body.value, match both name and owner, then use the returned id.

Why is my shared calendar missing from the dropdown?

Check that the correct calendar was shared with the connection account and that it has the view/edit permission required by the operation. Then run Get calendars (V2) and inspect the output rather than relying only on the picker.

Is a Teams calendar ID the same as an Outlook calendar ID?

No. A Teams-backed Microsoft 365 group calendar uses the group resource and group ID. Use the Office 365 Groups connector for group events.

Can I use a SharePoint list ID as the Calendar id?

Not in an Office 365 Outlook action. A SharePoint list GUID identifies a SharePoint list; an Outlook calendar ID identifies a mailbox calendar.

Why does a calendar ID work under one Graph path but not another?

Calendar IDs belong to a mailbox context. The owner calendar and a recipient's local shared copy can have different IDs, so discover and use the ID under the same identity/path.

Make identity and ownership explicit

Most “invalid calendar ID” problems are resource or identity problems in disguise. Name the calendar owner, use the production connection, discover the ID in that context, and prove a disposable read/write round trip.

If the flow still fails after those checks, join the Power Automate Builders Space. Bring a redacted Get calendars (V2) output, the target resource type and the connection identity.

How this article was checked

This rewrite was checked on 14 August 2026 against Microsoft's current Office 365 Outlook connector, Office 365 Groups connector, shared/delegated calendar guidance, shared event creation guidance, calendar listing operation and group event operation.