Feature Parity
Feature parity with the Connect version
Calendar Sync for Jira has been rebuilt on Atlassian's Forge platform, replacing the earlier Connect version. This page sets out what is the same, what has changed, and what is not available yet.
Atlassian is retiring the Connect framework, which is why the app has moved. The rebuild is not a port - it is a new implementation on a different platform, and a few things are necessarily different as a result.
At a glance
The same
The app does the same job in the same way. You still create feeds; each feed is still a JQL query plus rules for turning work items into events; each feed still produces a calendar at a unique URL that any iCalendar-capable application can subscribe to. Every time type, the timezone handling, repetition, the composable event summary and description, saved-filter selection, query testing and export-preview testing are all present.
Better
No data leaves Atlassian. On Connect, some calendar data was stored on external servers, and errors were reported to an external endpoint. On Forge, everything stays inside your Atlassian cloud environment, and the app declares no external hostnames at all.
Feed URLs can be rotated. Each feed has an Auth Key that an administrator can regenerate at any time, immediately invalidating every existing subscription. Connect had no equivalent.
More visible feed status. The feeds list adds Next Refresh and JQL columns, and refreshes itself while you watch.
Configurable sync schedule. A site-wide on/off switch and a choice of which days sync may run - useful for maintenance windows and non-production sites.
More field types are supported in event contents, including rich text converted to plain text with @mentions preserved.
Not available yet
Grouping and per-user calendars.
Export and import of feed configurations.
A per-feed manual refresh button.
Copy-to-clipboard.
One-time download on My Calendars.
The in-app help link.
Each is planned for a future update, and each is called out where it matters in the rest of this documentation.
Watch out for
Three differences will affect people migrating:
The refresh cadence is 12-hourly, not minutes.
A feed is capped at 2,000 work items, down from 5,000.
Feed configurations do not carry over - they must be recreated.
Feature comparison
Status values:
Yes - equivalent behaviour ·
Yes, changed - present but works differently
Not in this release - planned for a future update.
Feeds list
Connect feature | Forge equivalent | Status | Notes for users |
|---|---|---|---|
Feeds list with per-feed export status | Feeds list on Calendar Sync Admin Page | Yes, changed | Adds Next Refresh and JQL columns; auto-refreshes every 30 seconds. Status is shown as |
Create new feed | Create new Feed | Yes | Queued for building immediately |
Edit feed | Edit action on the row | Yes | Connect opened the feed by clicking its name; Forge uses a row action |
Duplicate feed | Duplicate action | Yes | Copy is named |
Delete feed | Delete action | Yes | Confirmation dialog before deletion |
Error detail on a failed export | Feed status plus Test Query | Yes, changed | Connect showed error detail behind the ERROR badge. On Forge, diagnose the cause with Test Query on the feed's JQL Query tab |
Edit feed - tabs
Connect used six tabs: Name, Query, Event date/time, Event contents, Grouping, Access control. Forge uses six: Basic Info, Event Date & Time, Event Contents, JQL Query, Security, Test Configuration.
Connect feature | Forge equivalent | Status | Notes for users |
|---|---|---|---|
Save changes / discard changes | Create Calendar / Update Calendar, and Cancel | Yes | Saving queues the feed for rebuilding |
Name tab | Basic Info tab | Yes, changed | Same three fields - Feed Name, Calendar Title, Organisation Name - plus a new Organisation Email, used in the event organiser. Shows a read-only Calendar ID when editing |
Query tab - manual JQL | JQL Query tab, Manual JQL | Yes | - |
Query tab - copy from filter | JQL Query tab, Copy from filter | Yes | Search saved filters by name, or leave the search empty to list all of them, including your favourites |
Query tab - test query | Test Query | Yes, changed | Connect reported a match count. Forge lists the matching work items alongside the actual values of your mapped date, duration and repetition fields - more useful for verifying a mapping |
Query tab - link to product documentation | - | Not in this release | The in-app help link will be added once this documentation is published |
Event date/time tab | Event Date & Time tab | Yes | Appears before the JQL Query tab, so you can set your mapping and then see it in the query results |
Time type - all day | All day | Yes | - |
Time type - date with time | Date time | Yes | End time from a fixed duration, a duration field in minutes, or an end date/time field |
Time type - date range | Date range | Yes | Start and end date fields; spans multiple days |
Timezone handling | Default Timezone | Yes, changed | Connect could also read the timezone from a per-work-item field. |
Repetition on consecutive days | Number of days | Yes | A number field on the work item: positive integers |
Event contents tab | Event Contents tab | Yes, changed | Same idea - an ordered list of static text and Jira field values making up the Summary and the Description - with a live preview, a Reset fields button, reordering, and a limit of 10 items each. Default Description adds Assignee alongside the Issue URL and Description |
Supported field types in event contents | - | Yes, changed | Broader than Connect: text, numbers, dates, users, priority, options, project, work item type, progress, time tracking, team, status, status category, votes, watchers, comment count and multi-value fields. Rich text is converted to plain text with @mentions preserved |
Test the configuration before saving | Test Configuration tab, Test My Feed Configuration | Yes, changed | Connect placed a Test button at the bottom of the form. |
Grouping tab - no grouping | Implicit | Yes | Every feed produces exactly one calendar, which is what "no grouping" did |
Grouping tab - one calendar per user | - | Not in this release | Planned for a future update. See Common use cases for what to do meanwhile |
Grouping tab - one calendar per field value | - | Not in this release | Planned for a future update |
Grouping tab - an extra "All" calendar | - | Not in this release | Depends on grouping |
Access control tab - no one can access all calendars | Security tab, No one | Yes | - |
Access control tab - all Jira users | Security tab, All users | Yes | - |
Access control tab - specific groups | Security tab, Users in specific group(s) | Yes | A user sees the feed if they are in any named group |
Access control tab - specific project roles | Security tab, Users with specific role(s) | Yes, changed | Each rule must name both a project and a role. Jira's API cannot resolve a user's roles across all projects at once, so the pairs are nominated explicitly rather than discovered |
Access control tab - each user sees only their own events | - | Not in this release | Depends on the grouping. Planned for a future update |
- | Auth Key, with regeneration | New in Forge | Rotate the key to revoke a URL that has been shared too widely |
My Calendars
Connect feature | Forge equivalent | Status | Notes for users |
|---|---|---|---|
My calendars page listing the calendars you can see | My Calendars global page | Yes, changed | Under Apps in the Jira sidebar, rather than the user profile menu, because the personal-settings placement is not yet generally available on Forge |
Calendar URL shown per calendar | Calendar URL column | Yes | Read-only field, you select and copy |
Copy to clipboard button | - | Not in this release | Select the URL from the field and copy it. Planned for a future update |
One-time Download of an | - | Not in this release | Subscribe by URL instead, which is the recommended approach in any case. Planned for a future update |
Calendar hidden until the feed has data | BUILDING badge, no URL issued | Yes | No URL is given out until the first export succeeds, so a user cannot subscribe to an empty calendar |
Feed URL and security
Connect feature | Forge equivalent | Status | Notes for users |
|---|---|---|---|
Unauthenticated, unguessable calendar URL over HTTPS | Same model | Yes | Necessary because calendar clients cannot sign in. Treat a calendar URL as a secret |
URL format | New format | Yes, changed | Connect URLs were paths under your Jira site. Forge URLs are Forge web-trigger addresses carrying a token. Connect URLs do not carry over - users re-subscribe |
Ability to rotate the credential in a URL | Auth Key regeneration | New in Forge | Connect had no way to invalidate a leaked URL |
Data stored outside Atlassian | - | Improved | On Forge, nothing leaves Atlassian's infrastructure and the app declares no external hostnames |
Error reports sent to the vendor, with an opt-out | - | Not applicable | Forge does not send error reports to the vendor, so there is nothing to opt out of |
Jira access via an app user account | Declared Forge permissions | Yes, changed | No app user account is created. The app declares the four permissions it needs, and Atlassian enforces them. Project role reads are read-only |
Administration and platform
Connect feature | Forge equivalent | Status | Notes for users |
|---|---|---|---|
- | Global calendar configuration - site-wide on/off and allowed days | New in Forge | Confine sync to business days, or pause it entirely |
Feed refresh cadence | Hourly check, 12-hour rebuild | Yes, changed | See Differences that change behaviour below |
Per-feed manual refresh | - | Not in this release | Saving a feed re-queues it. A refresh button is planned |
Export / import of feed configurations | - | Not in this release | Planned for a future update |
Licensing | Marketplace licensing | Yes | Trial banner, trial-ended and licence-required states. While the licence is inactive, feeds are not rebuilt and calendar URLs return |
Product documentation | This documentation set | Yes | Replaces the Connect documentation, which described a different UI and different limits |
Differences that change behaviour
These are the ones a migrating customer will actually notice.
Refresh cadence: 12 hours, not minutes
The Connect documentation stated that feed data was served within 5 minutes of a change in Jira. On Forge, each feed is rebuilt every 12 hours, and the app checks hourly for feeds that are due.
In practice, this changes very little of what users see, because calendar applications were always the bottleneck: Google Calendar takes up to 12 hours to collect subscribed data and Outlook.com more than 24, in both cases with no manual refresh available. Rebuilding more often than clients collect would not have made anyone's calendar more current.
What it does change: a newly created or newly edited feed takes up to an hour to appear, rather than minutes. Set expectations accordingly when rolling out a new feed.
2,000 work items per feed, down from 5,000
A feed exports at most 2,000 work items. Beyond that, results are truncated.
Bound your queries by date, which is good practice regardless:
created >= -365d AND type = Epic
This also aligns the feed with what clients display - Outlook does not show subscribed events older than roughly 365 days.
Configurations do not carry over
There is no migration path from the Connect version. Feeds must be recreated through the admin page.
This is unavoidable: the Connect app has no facility for exporting a feed configuration, so there is nothing to import from. Before switching, note down each feed's query, date mapping, event contents and access rules so you can rebuild them.
Users will also need to resubscribe because the URL format is different, and Connect URLs do not work against the Forge app.
Grouping and per-user calendars are not yet available
Each feed produces exactly one calendar containing all of its events. The Connect feature that generated one calendar per assignee - and, with it, the half of the access control tab that let each user see only their own events - is not in this release.
This is the most significant gap. See /wiki/spaces/GIHD/pages/5175443624 for the approaches available meanwhile.
Role-based access requires naming the project and the role together
On Connect, granting access to a role applied across projects, and each calendar then contained only the events from projects where that user actually held the role.
On Forge, each rule names a project and a role together, and access is all-or-nothing per feed - a user who matches any rule sees all of the feed's events. Jira's API cannot report which roles a person holds across every project at once, so the pairs must be nominated. Per-project event filtering depends on grouping and is not in this release.
If your query spans several projects, add one rule per project whose members should have access.
Timezone is set per feed, not per work item
Connect could read an event's timezone from a field on the work item, overriding the feed default.
On Forge, the timezone is a per-feed setting. If you have work items that genuinely span time zones, create one feed per timezone.
Data no longer leaves Atlassian
An improvement rather than a caveat, but it is a real change worth telling your security team about: the Forge app stores everything inside your Atlassian cloud environment, declares no external hostnames, and sends no error reports to the vendor. The Connect documentation's statements about external storage and vendor error reporting no longer apply.
Not yet available
Everything in this list is planned for a future update.
Feature | What to do meanwhile |
Grouping - one calendar per user, or per field value | Create one feed per group of people, restricted with access control. See Common use cases |
Per-user event filtering in access control | Scope the query per feed instead |
Export and import of feed configurations | Recreate feeds through the admin page; note down settings before migrating |
Per-feed manual refresh | Save the feed, which re-queues it for the next hourly check |
Copy to clipboard on My Calendars | Select the URL from the read-only field |
One-time calendar download | Subscribe by URL, which is recommended in any case |
In-app link to this documentation | Reach it from your app listing or your internal documentation index |