Explain whether Add to calendar creates a copy or a subscription

Name the delivery contract

Microsoft’s documentation for Outlook.com and Outlook on the web, checked 7 November 2026, distinguishes imported calendar snapshots from subscriptions that refresh. It warns that subscription updates can take more than twenty-four hours. This is documented product behavior, not a universal calendar-client guarantee. A campaign should not describe either route as an instantaneous alert service.

Write the button’s contract in ordinary language: add this event as it stands now, follow this public schedule, or enter a separately managed invitation workflow. Record the actual action behind the button rather than inferring it from an icon or an .ics suffix. A visitor should not need to understand calendar protocols to know whether later changes will reach the copy they just created.

Choose the promise from the campaign’s change risk

List the changes that might matter: revised start, canceled session, moved venue or added occurrence. Decide whether the calendar is a convenience copy or an important route for ongoing information. If a snapshot is sufficient, tell the reader where to check the current schedule. If future refresh matters, verify that the implementation really creates a subscription in the intended client.

Keep attendance confirmation separate. A saved calendar entry is not evidence that the organizer has reserved a place, received an RSVP or knows whom to contact. The campaign should point to its actual registration process where one exists. Likewise, a public schedule subscription should not be used as a reason to expose a private calendar or include attendee details in a downloadable feed.

Prepare a two-client change fixture

Use a synthetic schedule with one unmistakable initial title and a later controlled change. Document the steps a reader follows in each intended client, including whether a file is downloaded, an import dialog appears or a subscription address is retained. Capture the resulting calendar type and the visible entry, not merely the successful download response.

For each route, write an expected update result and a realistic observation window. Preserve the initial state so a second download cannot be mistaken for automatic refresh. If the tester manually reimports a file, record that intervention. A changing subscription and a manually replaced snapshot can look identical in the final screenshot while providing very different promises to a real reader.

Resolve unsupported paths without misleading fallback

Classify failures as incorrect button routing, unsupported client action or delayed refresh. If a client falls back from subscription to import, the copy should explain that the resulting entry is a snapshot. Do not silently keep the stronger update promise after weakening the delivery method. Provide the current event page as the reference point rather than inventing a refresh deadline.

The acceptance record should name the tested product, account context, route and observation date. Keep client-specific results separate instead of declaring that all calendar software behaves the same way. Agree who maintains the public schedule and who approves corrections if it changes. This exercise creates a truthful distribution contract; it neither subscribes real users nor sends invitations or reminders on their behalf.

Make the reasoning concrete.

A fictional conference offers a button labeled Stay updated in your calendar. In the tested flow it downloads a file that visitors import once. The venue changes a week later.

The conference retains a clearly labeled snapshot while reviewing a subscription option separately. The current event page remains the reference for changes, and registration is not inferred from saving the entry.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Action

   What does the button actually create in the target client?

2. Promise

   Which future changes does the campaign claim it will carry?

3. Fixture

   What synthetic change distinguishes refresh from reimport?

4. Delay

   What client-specific observation window avoids an instant-update promise?

5. Fallback

   How will an import fallback be explained honestly?

Watch for the wrong conclusion.

• Calling a downloaded snapshot a live schedule.
• Treating a calendar save as registration or RSVP.
• Mistaking manual reimport for successful automatic refresh.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. This work performs no real invitations, profile changes, delivery changes or production actions.

• Import or subscribe to a calendar in Outlook.com or Outlook on the web →Primary platform documentation · Supports: Supports the product-specific import/subscription distinction and delayed refresh caveat. The button contract and synthetic acceptance fixture are original.