Power Automate group calendar timezone errors: the safe fix

An event that should start at 9:00 appears at 10:00, 14:00 or on the wrong day. The tempting response is to add another conversion, strip the Z, or abandon the connector for Microsoft Graph.

Pause before doing any of those things.

The first job is to establish whether your value represents a real instant in UTC or a local wall-clock time with no offset. Most repeat timezone errors happen because a flow converts the value correctly, then another action interprets the converted text as if it were still UTC.

The short answer

For a Microsoft 365 group calendar, start with the Office 365 Groups connector's current Create a group event (V2) action. Microsoft lists that connector as Standard.

Then follow this rule:

• If the input ends in Z, it is already UTC. Do not convert it to local time and then present the result as UTC.
• If the input is a local time without Z or an offset, convert it from its real source timezone to UTC before giving it to the group action.
• Use a Windows timezone name such as GMT Standard Time, not an abbreviation such as BST.
• Test normal timed events, daylight-saving boundaries and all-day events separately.

Only move to a direct Graph request when you have a requirement the group action cannot represent, such as retaining an explicit source timezone in the event's start and end objects.

Do not create an app registration with Group.ReadWrite.All application permission for this job. Microsoft's current Graph documentation says application permission is not supported for creating an event in a Microsoft 365 group calendar.

Use the right connector

There are two similarly named actions:

Target	Connector and action	What it is for
Microsoft 365 group calendar	Office 365 Groups — Create a group event (V2)	Creates an event in the selected group calendar.
User or shared mailbox calendar	Office 365 Outlook — Create event (V4)	Creates an event in a calendar accessible through the Outlook connection.

There is no current Create a group event (V4) action in Microsoft's Office 365 Groups connector reference. The older unversioned group action is deprecated; Microsoft directs makers to V2.

That naming matters. Changing an Outlook V4 action will not repair a flow that should be writing to a group calendar.

Diagnose the timestamp before changing it

Open a failed or incorrect run in Power Automate and inspect the trigger or action output that supplied the start time. Record the exact string, not the value shown in a friendly date picker.

These three values look similar but do not mean the same thing:

Value	Meaning	Safe next step
2026-08-07T08:00:00Z	A precise instant at 08:00 UTC	Keep it as UTC. For a UK user in August, Outlook should display the equivalent local time.
2026-08-07T09:00:00+01:00	A precise instant with an explicit one-hour offset	Preserve the offset or normalise it to UTC once.
2026-08-07T09:00:00	A wall-clock time with no timezone information	Identify the intended source timezone, then convert it to UTC.

Microsoft's Power Automate timezone guidance confirms that a trailing Z means UTC. It also warns that connectors can differ in the formats and timezones they return.

This is why a blanket instruction to “strip the Z” is dangerous. It removes information from the timestamp. The same text can then be interpreted as a different instant.

Fix path 1: normalise to UTC and use Create a group event (V2)

This is the first route to test because it uses the action designed for Microsoft 365 group calendars and avoids a custom authentication design.

When the source already returns UTC

If the inspected value ends in Z, map that value to Start Time or End Time without converting it to local time first.

You may format it for consistency, but formatting is not conversion. Preserve an ISO 8601 UTC value and its Z suffix.

When the source is a local wall-clock time

Suppose the source contains 2026-01-15T09:00:00 and the business rule says that means 9:00 in the UK.

Use the built-in Convert time zone operation, or the convertToUtc() expression, with GMT Standard Time as the source timezone. Microsoft documents the expression as:

convertToUtc('<timestamp>', '<sourceTimeZone>')

For dynamic content, the shape is:

convertToUtc(<your local start value>, 'GMT Standard Time')

The result is an ISO 8601 UTC timestamp. Map that result to the group event's Start Time. Repeat the same conversion for End Time.

Do not hard-code addHours() or subHours() as a timezone conversion. A fixed offset does not follow daylight-saving changes.

Configure the group action

Add Office 365 Groups — Create a group event (V2) and set:

1. Group Id: the target Microsoft 365 group.
2. Subject: a short event title.
3. Start Time: the verified UTC start value.
4. End Time: the verified UTC end value.
5. Optional fields such as body, location, importance and show-as status.

The current connector reference does not expose a timezone field for this action. It accepts start and end date-time values. That is why the input must describe the right instant before it reaches the action.

Also note a group-calendar limitation that the old article missed: Microsoft Graph documents that Outlook does not support reminders for group events. Do not make a production promise based only on the action exposing an Is Reminder On field.

A worked example

A SharePoint-triggered flow must create a group event for 09:00 to 10:00 UK time.

Case A: SharePoint supplies UTC

The run history shows:

Start: 2026-08-07T08:00:00Z
End:   2026-08-07T09:00:00Z

Those are already the correct instants for 09:00 to 10:00 UK daylight time. Pass them to Create a group event (V2). Do not convert them to 09:00 and 10:00 and then let the group action treat those values as UTC.

Case B: the source supplies local wall-clock values

The run history shows:

Start: 2026-08-07T09:00:00
End:   2026-08-07T10:00:00

If the business rule says those values are UK local time, convert each from GMT Standard Time to UTC. In August, the outputs should represent 08:00Z and 09:00Z.

The timezone name GMT Standard Time is a Windows timezone rule, not a promise that the UK is always on GMT. The rule accounts for daylight-saving time for the date being converted.

Fix path 2: use Graph only when you need explicit timezone metadata

Microsoft Graph represents event start and end as dateTimeTimeZone objects. Each object contains both a local dateTime and a timeZone.

That can be useful when preserving the event's original timezone is a real requirement rather than merely displaying the correct instant.

The request body has this shape:

{
  "subject": "Project review",
  "body": {
    "contentType": "HTML",
    "content": "Created from the approved source record."
  },
  "start": {
    "dateTime": "2026-08-07T09:00:00",
    "timeZone": "GMT Standard Time"
  },
  "end": {
    "dateTime": "2026-08-07T10:00:00",
    "timeZone": "GMT Standard Time"
  },
  "transactionId": "use-a-stable-id-for-this-source-event"
}

The group endpoint is:

POST https://graph.microsoft.com/v1.0/groups/{group-id}/events

The timeZone property controls the start and end supplied when the event is created. A Prefer: outlook.timezone="GMT Standard Time" header controls the timezone used for start and end in the response; it is not a substitute for the timezone properties in the request body.

Use a stable transactionId for the same intended event so a retry does not create an unnecessary duplicate. Better still, store the returned event ID against the source record and use an update path when that ID already exists.

The permission boundary is non-negotiable

For a group calendar, Microsoft's create-event permission table currently says:

• delegated work or school account: Group.ReadWrite.All;
• delegated personal Microsoft account: not supported; and
• application permission: not supported.

Group.ReadWrite.All is broad and requires administrator consent. Microsoft does not publish a narrower delegated permission for this group-event operation. Treat that as a design cost: if storing the event's original timezone is not worth the scope, stay with Create a group event (V2) and pass a correct UTC instant.

That means a client secret, certificate or managed identity cannot turn an app-only token into a supported call for this endpoint. Managed identity is safer than a secret for APIs that support application permissions, but this particular group-calendar operation does not.

If you use the Office 365 Groups connector's Send an HTTP request V2 action, it uses the connector's signed-in user connection and supports the /groups segment. The same connector reference warns that its available scopes are limited and that some requests can return Authorization_RequestDenied or Forbidden.

If that happens, stop. Do not paste a tenant-wide app secret into the flow. Ask the Microsoft 365 administrator to review the delegated permission and the target identity. If the built-in action cannot satisfy the approved design, use an administrator-approved delegated custom connector or choose a different calendar target.

Custom connectors and generic HTTP actions can also change Power Platform licensing and data-loss-prevention requirements. Check the current tenant policy and plan before treating them as an implementation detail.

All-day events need a separate test

An all-day event is not an ordinary timed event with the hours hidden.

Microsoft's event resource says that when isAllDay is true, start and end must both be midnight in the same timezone. The end of a one-day event is midnight at the start of the following day.

For an event covering 7 August in the UK, the Graph shape is:

{
  "isAllDay": true,
  "start": {
    "dateTime": "2026-08-07T00:00:00",
    "timeZone": "GMT Standard Time"
  },
  "end": {
    "dateTime": "2026-08-08T00:00:00",
    "timeZone": "GMT Standard Time"
  }
}

Do not reuse a timed-event conversion without checking the date boundaries in Outlook on the web. Midnight converted carelessly can move the event onto the previous or following date for some viewers.

Production checklist

Do not validate a calendar flow with one event created on today's date.

1. Save a recovery copy. Export the existing solution or save a copy of the flow before changing its date handling.
2. Use a test group. Do not test permission changes and duplicate prevention in a busy production calendar.
3. Record exact inputs. Capture start, end, suffix or offset, source timezone and expected UTC instant.
4. Run four cases. Test a normal winter date, a normal summer date, a date near a daylight-saving change and an all-day event.
5. Check two views. Confirm the event in Power Automate run history and Outlook on the web. If colleagues work in different timezones, ask at least one to check the same event.
6. Confirm identity and ownership. Document which connection creates the event, who can repair it if the owner leaves and how the connection is replaced.
7. Prevent duplicates. Store the created event ID or another durable idempotency key against the source record.
8. Add a failure path. Log the source record ID, group ID, action status and correlation details. Do not log tokens, secrets or sensitive event text unnecessarily.
9. Plan rollback. Be able to disable the new branch, restore the previous flow and remove test events without deleting legitimate calendar content.

If you introduced an app registration while following older advice, verify whether anything else uses it. If not, have an administrator revoke its consent, remove its credentials and delete it under your organisation's normal change process. Do not remove a shared app registration on assumption.

Common mistakes

Mistake	Why it causes trouble
Converting a UTC value to local time, then passing the local text as UTC	The instant is shifted twice.
Removing Z to make an error disappear	The timestamp loses its UTC meaning.
Using addHours() for UK or US time	A fixed offset ignores daylight-saving rules.
Using Create event (V4) for a group calendar	It is the Outlook action, not the current Office 365 Groups event action.
Adding Group.ReadWrite.All application permission	Microsoft does not support application permission for creating a group event.
Storing a client secret in the flow	It adds secret-rotation risk and still does not make the unsupported app-only group call valid.
Retrying Create without an event ID or transaction key	A timeout or replay can create duplicate events.
Testing only in the current month	Daylight-saving and all-day failures remain hidden.

FAQ

Is there a Create a group event (V4) action?

Not in Microsoft's current Office 365 Groups connector reference. The current group-calendar action is Create a group event (V2). Create event (V4) belongs to the Office 365 Outlook connector.

Should I remove the Z from a SharePoint date?

No. A trailing Z says the value is UTC. Inspect the value and convert it only if the business meaning requires a different source timezone. Removing the suffix without changing the instant creates ambiguity.

Which timezone name should I use for the UK?

Use the Windows timezone name GMT Standard Time when a local UK wall-clock value must follow UK daylight-saving rules. Use UTC when the source value is already UTC. Do not substitute GMT, BST or a fixed one-hour calculation without verifying the contract of the action.

Can an app registration or managed identity create a Microsoft 365 group event?

Not through the documented group-calendar create-event endpoint using application permission. Microsoft currently supports delegated Group.ReadWrite.All for this operation and marks application permission as unsupported.

Why does my all-day event span two dates?

All-day events use midnight boundaries. Microsoft requires start and end at midnight in the same timezone, with the end of a one-day event set to midnight on the following day. A UTC conversion at the wrong stage can shift either boundary.

Official sources

• Office 365 Groups connector reference
• Convert a time zone in Power Automate
• Power Automate and Logic Apps expression functions
• Create a calendar event with Microsoft Graph
• Microsoft Graph dateTimeTimeZone resource
• Microsoft Graph event resource and all-day requirements
• Microsoft Graph permissions reference for Group.ReadWrite.All
• Windows default timezone names

Building a group-calendar flow other people must rely on? Join the Power Automate Builders Space for current implementation patterns and practical peer review.