---
language: "en"
---
# Welcome to the Krosoft Wiki
Lean software for Jira and Confluence.
Krosoft builds focused tools that solve real workflow problems for Atlassian teams --- without the bloat.
We combine AI-orchestrated development, short feedback loops, and direct customer support to ship practical products that save time.
*** ** * ** ***
## What Krosoft is about
Krosoft is a small, focused software studio building practical apps for Jira and Confluence.
Our approach is simple:
* Build tools with a clear job to do
* Stay close to real customer problems
* Keep products lean and easy to adopt
* Use fast iteration instead of heavy process
That means fewer unnecessary features, faster improvements, and software that earns its place in your workflow.
*** ** * ** ***
## Products
### Related Issues for Jira Cloud
**Jira Cloud**
Surface related Jira issues directly in the issue view using configurable JQL logic.
Documentation and release notes are available in this knowledge base.
### RSVP for Confluence Cloud
**Confluence Cloud**
Add lightweight sign-up and attendance tracking directly to Confluence pages.
Documentation and release notes are available in this knowledge base.
### RSVP for Confluence Data Center
**Confluence Data Center**
Run RSVP forms in your own environment.
Documentation is available in this knowledge base.
### Planning Sync for Jira
**Jira + Tempo**
Keep Jira work item fields aligned with Tempo plan data and downstream integrations.
Documentation is available in this knowledge base.
### Legacy Assets Macro Finder for Confluence
**Migration tooling**
Find legacy Insight and Assets macros after migration to Confluence Cloud.
Documentation is available in this knowledge base.
*** ** * ** ***
## Trust \& support
We want customers to be able to evaluate Krosoft quickly, use our products confidently, and get help when needed.
Trust, privacy, DPA, SLA, and product support information are available in this space.
Support: [support@krosoft.nl](mailto:support@krosoft.nl)
*** ** * ** ***
## Why teams choose Krosoft
* Focused apps instead of bloated platforms
* Fast iteration and practical improvements
* Direct support from the people close to the product
* Clear documentation and transparent trust information
---
language: "en"
---
# 2025-04-29 - 1.0.10
This hotfix improves the stability of the uninstall process and ensures clean lifecycle handling in Jira Cloud. Minor debug logs have been removed, and internal dependencies have been updated for better reliability.
---
language: "en"
---
# 2025-04-28 - 1.0.9
We've replaced the deprecated JQL search endpoint in this update to ensure continued compatibility with upcoming Atlassian platform changes.
We also introduced dark theme support for a more comfortable experience in low-light environments.
To make configuring JQL templates easier, we've added a new code block editor.
Finally, we've made various UI improvements to polish the overall look and feel of the app.
---
language: "en"
---
# 2025-05-04 - 1.0.11
This update introduces a new *Getting Started* page to help users quickly onboard and configure the app, now accessible directly from the Manage Apps section. It also adds a centralized configuration landing page within the UPM for easier access to key settings. These improvements enhance the user experience, streamline setup, and simplify ongoing configuration management.
---
language: "en"
---
# 2025-05-19 - 1.0.12
This release brings a smoother user experience to the issue list view by fixing a bug where the "Show more" button could persist incorrectly when switching between issues. The footer rendering was unified and simplified across views, improving consistency and maintainability. Visual spacing was adjusted for better alignment, and tooltip behavior was corrected. Pagination logic was also updated to rely on more reliable indicators, ensuring a more accurate and responsive interface.
---
language: "en"
---
# Data Processing Agreement (DPA)
This DPA applies to all paid apps offered by Krosoft on the Atlassian Marketplace, including but not limited to the following:
* [Related Issues for Jira Cloud](https://marketplace.atlassian.com/manage/apps/1212247)
* [RSVP for Confluence Cloud](https://marketplace.atlassian.com/manage/apps/1212218)
* [RSVP for Confluence Data Center](https://marketplace.atlassian.com/manage/apps/1213905)
*** ** * ** ***
## 1. **Parties**
This Data Processing Agreement ("DPA") is entered into between:
* **Customer**: The Atlassian customer who installs and uses one or more Krosoft apps ("Controller")
* **Krosoft**: Located in the Netherlands, developer of the apps ("Processor")
*** ** * ** ***
### 2. **Subject Matter and Scope**
This DPA governs Krosoft's processing of End-User Data on behalf of the Controller in relation to any Krosoft app offered on the Atlassian Marketplace, in accordance with the General Data Protection Regulation (GDPR).
*** ** * ** ***
### 3. **Nature and Purpose of Processing**
Krosoft processes End-User Data solely to deliver the core functionality of its apps. This may include (depending on the app):
* Configuration data (e.g. JQL templates, macro settings)
* Project- or tenant-level identifiers
* Form submissions or structured inputs (e.g. RSVP responses)
Krosoft does **not** collect or store issue content, comments, attachments, or personal data such as user email addresses or names, unless explicitly required by the app's purpose.
*** ** * ** ***
### 4. **Duration**
Processing continues for the duration of the app installation. Upon uninstallation, customer data is retained for up to 30 days unless earlier deletion is requested.
*** ** * ** ***
### 5. **Sub-Processors**
Krosoft uses **Heroku (Salesforce)** for cloud hosting. Data is stored in Heroku's EU data centers (e.g., Germany, Ireland). Salesforce provides GDPR-compliant Standard Contractual Clauses (SCCs) for international data transfers.
🔗
*** ** * ** ***
### 6. **Security Measures**
Krosoft implements appropriate technical and organizational measures to protect End-User Data, including:
* Full encryption in transit and at rest
* Logical tenant-level data separation
* Access restrictions and internal audit logging
*** ** * ** ***
### 7. **Data Subject Rights**
The Controller is responsible for handling data subject requests (access, rectification, erasure). Krosoft will support the Controller with such requests upon request, in accordance with GDPR.
*** ** * ** ***
### 8. **Data Transfers**
When End-User Data is transferred outside the EEA (e.g., to Heroku's US-owned infrastructure), such transfers are covered by GDPR-approved mechanisms (SCCs).
*** ** * ** ***
### 9. **Termination**
Upon app uninstallation or termination of the agreement, all End-User Data is deleted within 30 days unless an earlier deletion request is submitted.
*** ** * ** ***
### 10. **Contact**
Questions or data-related inquiries can be directed to:
📧 [**support@krosoft.nl**](mailto:support@krosoft.nl)
---
language: "en"
---
# Data Security and Privacy Statement
**Effective Date:** 2026-10-04
This statement describes privacy and security practices for Krosoft applications and the public documentation site at [https://wiki.krosoft.nl](https://wiki.krosoft.nl/). The application practices below remain separate from optional wiki analytics. Visiting the wiki does not grant analytics consent.
## 1. **Personal Information Collection**
Our applications do not collect personal information such as names, email addresses, or payment information. Optional analytics for the public wiki is described under Cookies and Tracking below.
### 2. **Use of Information**
The application practices described above do not involve collecting or sharing personal information. With your consent, we use optional wiki analytics to understand how public documentation is used and improve its usefulness.
### 3. **Data Storage and Security**
While using our apps, some data may be temporarily stored in app logs. These logs are used solely for support, such as resolving bugs or incidents. Importantly, these logs do not contain any personalized information and are not retained beyond what is necessary to resolve the issue. We take reasonable measures to secure any data processed, including applying industry-standard practices to safeguard against unauthorized access or disclosure.
### 4. **User Rights**
You can refuse optional wiki analytics or withdraw your consent at any time. Contact us using the details below for privacy questions and requests concerning your data.
### 5. **Cookies and Tracking**
The wiki uses a cookie notice to distinguish necessary cookies from optional analytics cookies. Necessary cookies support the site and your saved preferences. Optional analytics is disabled until you accept analytics cookies.
#### Optional wiki analytics
With your permission, we use Google Analytics 4 to understand visits to public documentation article pages on wiki.krosoft.nl. We record page views and engagement, the public page title and URL path, broad referral information, browser and device details, and a cookie identifier. These measurements describe documentation use, not completed bookings or support submissions. We also record clicks that open the company website, using a fixed navigation direction label.
We do not send URL query strings or fragments, search text, AI Console messages, form entries, email addresses, user IDs, or referrer paths to Google.
Your saved cookie choice expires after 182 days, about six months. Analytics cookies are stored only on wiki.krosoft.nl for up to 180 days. Returning visits do not extend their expiry.
Google Analytics user and event data is retained for two months. Returning visits do not reset that retention period. Standard aggregated reports retain their history separately.
Use Manage cookie preferences in the footer to change your choice. Rejecting analytics prevents Google analytics scripts and collection requests. Withdrawing consent stops collection, removes this integration's analytics cookies, saves your refusal, and reloads the page.
### 6. **Third Party Services**
Google receives the optional wiki analytics data as our analytics service provider. Google also processes technical connection information when receiving analytics requests. We do not use this integration for advertising personalization or Google Signals.
### 7. **Children's Privacy**
Our website and services are not intended specifically for children. Optional wiki analytics follows the consent and data limits described in this statement.
### 8. **Changes to This Statement**
We may update this statement when our practices or applicable requirements change. The current statement and effective date are published on this page.
### 9. **Contact Information**
If you have any questions or concerns regarding this Data Security and Privacy Statement, please get in touch with us at:
* **Email:** [support@krosoft.nl](mailto:support@krosoft.nl)
* **Support Portal:** [Krosoft Support Portal](https://krosoft.atlassian.net/servicedesk/customer/portal/1)
---
language: "en"
---
# Delivery status and recovery
Use this guide when delivery fails, a sync remains unfinished, or Outlook is incorrect after webhook acceptance.
**Controlled staging evaluation.** Contact [Krosoft support](https://krosoft.atlassian.net/servicedesk/customer/portals) for availability on your installation. Discovery coverage must be checked against your expected Tempo planning before production rollout.
## Read the status
| Status | What to do |
|---------------------|--------------------------------------------------------------------------------------------------|
| Discovery | Wait for discovery to finish. Resolve an incomplete-discovery result before confirming coverage. |
| Pending | Delivery is waiting. Check that the connection is enabled. |
| Retrying | A temporary error has a scheduled retry. Check the error and allow that retry to run. |
| Accepted by webhook | Check flow run history and Outlook; the endpoint has acknowledged the request. |
| Failed | Correct the reported cause, then retry the failed items. |
| Blocked | Resolve the earlier failed request for this plan and connection. Later changes must wait. |
| Skipped | Review the reason and compare it with the planning you expected to export. |
Review accepted, failed and blocked counts separately. Accepted requests can still have unfinished downstream Outlook work.
## Recover a failed delivery
1. Open the connection's **Sync existing planning** panel. Choose **Show failures** and use **Next details** to read additional pages. Use **Show skipped planning** to inspect exclusions.
2. Match the error to Planning Sync audit entries and, where present, the Power Automate run. Use the table below to correct the cause.
3. Choose **Retry failed items**. Accepted items stay accepted; failed items receive a fresh set of attempts and keep their position ahead of later changes.
4. Check the run again, then verify the final Outlook state. Discovery must also finish successfully if it was incomplete.
**Retries use the stored request.** Editing the outbound template or other nonsecret connection settings affects subsequent batches, not an already prepared request. Fix the receiving schema or routing where appropriate; contact [Krosoft support](https://krosoft.atlassian.net/servicedesk/customer/portals) if the stored request itself needs correction. Do not delete and recreate the connection to bypass failed work.
A failed request holds later changes for that plan and connection. Other plans can continue. Do not manually replay an older create after deletion or send a later update to bypass the failure.
## Before webhook acceptance
| Symptom | Action | Expected result |
|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------|
| HTTP 400 / schema rejection | Inspect the resolved body and align the receiver schema with required IDs, nullable metadata and daily date/time fields. Escalate if the stored payload is wrong. | After correction and retry, the endpoint accepts the same request. |
| HTTP 401/403 or no flow run | Verify the saved endpoint, enabled flow and trigger authentication requirements with the integration administrator. | The request reaches the intended flow and is accepted. |
| Endpoint returns HTTP 429 | Let the destination cooldown and scheduled retry run; review receiving-flow capacity. | Delivery resumes after the endpoint's retry delay. |
| User or calendar not found | Correct the explicit routing map and connector permissions. Verify the intended mailbox and calendar; do not route an unknown user to another calendar. | The flow reaches the intended writable calendar. |
| Incomplete discovery | Check Tempo/Jira visibility, saved authentication and reported pagination/API errors with the administrator or support. | Discovery finishes and the expected plans are accounted for. |
| Duplicate matches / HTTP 409 | Identify the managed duplicates and agree a scoped cleanup. Fix the receiver's correlation/concurrency design before retrying. | Exactly one managed appointment matches the full occurrence key. |
## After webhook acceptance
An Outlook connector's downstream HTTP 429 does not automatically become an HTTP 429 response to Planning Sync. The app's destination cooldown applies when its endpoint returns 429. Once accepted, downstream retries and monitoring belong to your flow.
| Symptom | Action | Expected result |
|--------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| Accepted but no appointment | Open the accepted flow run and inspect Outlook actions, target calendar and full occurrence-key lookup. | The downstream run completes and the intended appointment exists. |
| Outlook connector HTTP 429 | Allow or configure downstream connector retries and review Microsoft limits. Do not resend accepted requests as the first remedy. | The flow recovers the failed Outlook action without duplicate appointments. |
| Wrong dates, times or calendar | Check daily date/time expressions, planning timezone and explicit calendar routing. | Managed appointments match the expected planning in the intended calendar. |
Advanced receiving patterns: durable inbox and multi-user routing
| Pattern | Responsibilities |
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Synchronous response | Return 2xx after calendar processing succeeds; return an error when it fails. Keep processing within the HTTP timeout. In our tested flow, synchronous Response actions required trigger concurrency control to remain off. Overlapping runs still need receiver-side serialization or an atomic occurrence-key mapping. |
| Durable inbox | Persist the request before returning 2xx, then process Outlook separately. Serialize each occurrence stream, upsert by its complete ID and retain failed downstream work for retry. Planning Sync considers the request accepted once the inbox acknowledges it; downstream monitoring and connector retries belong to your flow. |
Use the simple synchronous recipe for a controlled test setup. For a large initial sync or multiple writers, validate a durable receiver design and Microsoft connector limits before rollout.
### Multi-user routing example
This is an illustrative design, not a validated multi-user recipe. Add the stable Jira assignee ID to your custom request and map it to a calendar the Outlook connection is authorized to write to. Do not use a display name as the routing key.
| Assignee identifier | Approved target |
|-------------------------------|----------------------------------------|
| jira-account-A (illustrative) | Calendar A |
| jira-account-B (illustrative) | Calendar B |
| Unmapped identifier | Reject clearly; report missing routing |
Store the full occurrence key together with its current calendar and Outlook event ID. On reassignment: read the previous binding, resolve and authorize the new target, remove the old managed appointment, upsert in the new calendar, then save the new binding. Retain recovery state if any step fails so retries converge on one appointment. Validate the removal-before-create gap and failure recovery before rollout. Adding attendees instead is an invitation workflow and needs separate consent and testing.
Technical details: automatic retries, retention and replay
### Automatic retries
| Result | Delivery behavior |
|----------------------------------------------|--------------------------------------------------------------------------------------------------|
| Network error, timeout, HTTP 408, 429 or 5xx | Retry, up to eight HTTP attempts in total. |
| HTTP 429 | Honor valid Retry-After seconds or HTTP dates; apply a cooldown to the destination. |
| Other 4xx | Fail without automatic retry. Correct the cause, then retry manually. |
| HTTP 2xx | Save acceptance. Recovery completes any remaining local steps without resending a saved success. |
Backoff begins at 30 seconds, doubles to a 30-minute base cap and adds up to 20% jitter. A valid Retry-After can delay it further. Requests are paced at least one second apart per destination. These controls do not guarantee Outlook connector capacity; the flow must also handle its own throttling. See [Microsoft's throttling guidance](https://learn.microsoft.com/en-us/power-automate/guidance/coding-guidelines/understand-limits).
### Connection changes and retention
Disable a connection to pause delivery. Deleting it leaves affected work visibly failed; contact support rather than recreating it to bypass the queue. Existing batches retain their prepared payload and nonsecret settings; configuration edits apply to subsequent batches. Signing uses the current secret.
Pending and failed records are kept until resolved. Completed delivery records are retained for 30 days after completion and source acknowledgement; occurrence-ID history remains. Background recovery checks durable work every five minutes, so progress may resume without a manual restart.
### Timeouts and safe replay
The receiver can update Outlook and then time out before the app saves acceptance. A retry can therefore repeat the request. Upsert and delete must be idempotent, using the full occurrence key. For concurrent or large-volume processing, use durable receiver-side correlation and serialization; a lookup followed by create is not an atomic uniqueness check.
For legacy appointments created with parent-only IDs or incorrect dates, pause the integration and agree a scoped cleanup with support. Preserve unrelated appointments. After correcting correlation, use manual sync on supported preview installations to repopulate eligible existing planning; there is no need to edit every plan just to trigger it.
## Contact support
Send the site, installed version, destination label, plan/occurrence ID, captured date/timezone, status counts, sanitized audit result and flow error. Include whether the issue is before webhook acceptance or inside Outlook processing. Omit tokens, full signed webhook URLs and private calendar content.
## Related guides
* [Set up the Outlook flow](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md)
* [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md)
* [Outbound payload reference](https://wiki.krosoft.nl/ekb/outbound-payload-reference.md)
---
language: "en"
---
# Expected changes as RSVP moves to Forge
RSVP for Confluence Cloud is moving to Atlassian Forge, Atlassian's cloud app platform.
This page explains what site admins, page owners, and attendees should expect as RSVP moves from the legacy Cloud app platform to Forge.
Last reviewed: 2026-05-31
## Summary
For most users, RSVP continues to work on the same Confluence pages. Existing RSVP macros remain in page content, and the main workflow stays familiar: view responses, respond, edit or remove your own response, and export responses when you are an organizer.
The important change is behind the scenes: the Forge version stores RSVP data in Atlassian Forge SQL and uses Forge app infrastructure. The rollout is controlled so historical RSVP data is not silently lost or shown as an empty RSVP list before it has been verified or imported.
## What is changing
* RSVP runs on Atlassian Forge instead of the legacy Cloud app platform.
* RSVP data for the Forge app is stored in Forge SQL.
* The macro UI is more Confluence-native and may look slightly different.
* Some admin and migration actions are handled in the **RSVP Migration Console**.
* Existing Cloud and Server/Data Center migration paths are handled separately.
## What is not changing
* Existing RSVP macros stay on their Confluence pages.
* Page links and normal page editing are unchanged.
* Attendees can still submit, update, or remove their own RSVP where allowed.
* Organizers can still view and export responses.
* Historical RSVP data is protected during migration instead of being treated as missing just because it is not yet in Forge.
## What most users may notice
After a site is using the Forge version, users may see:
* A refreshed RSVP macro layout.
* Response statuses such as **Attending** , **Declined** , and **Waitlisted**.
* Capacity and remaining-spot indicators when configured.
* Standard or compact response rows, depending on macro settings.
* Custom RSVP questions when an organizer has configured them.
* Search and status filters when enabled for the response list.
Organizers may also see additional controls such as CSV export, check-in, **Ask Rovo** , and **Notify**. Some organizer-only controls are visible only to page managers, page authors, or Confluence admins.
## Historical data protection
Forge does not assume that an old RSVP macro is empty simply because no Forge rows have been imported yet.
During rollout, an existing legacy macro can be in one of these states:
* Historical responses have already been imported and the macro shows them normally.
* The macro is known to have had no historical responses and can show the normal empty state.
* The macro may still have historical responses to verify or import.
When RSVP cannot yet prove that a legacy macro is safe to show as empty, the macro may show a migration or pending-import message instead of a misleading empty response list. In that state, unsafe changes can be blocked until the data is verified or imported.
New Forge-native RSVP macros can work normally even while older legacy macros on the same site are still being checked.
## Migration paths
### Existing Cloud customers
Existing Cloud customers using the legacy RSVP app are moved through a controlled Connect-to-Forge path.
For reviewed sites, historical RSVP rows and legacy macro information may be imported as part of the staged rollout. If a site or macro needs manual attention, the app or Krosoft Support may direct a Confluence admin to the **RSVP Migration Console**.
Do not delete and recreate RSVP macros to fix missing historical responses. Contact Krosoft Support first.
### New Cloud installs
New Forge installs do not have legacy Cloud RSVP data to import.
Admins normally do not need to use the migration console unless they are importing from Server/Data Center or Krosoft Support asks them to check migration state.
### Server/Data Center to Cloud
Server/Data Center to Cloud migration is a separate workflow.
At a high level:
1. Export RSVP migration data from the Server/Data Center app.
2. Open the Cloud **RSVP Migration Console**.
3. Upload the migration artifact.
4. Review suggested Cloud page mappings.
5. Accept or skip mappings.
6. Import the accepted RSVP data into Forge.
Ambiguous or unresolved page mappings can be skipped and handled later.
## What Site Admins may need to do
Most users do not need to take action. A Confluence admin may need to act only when the app or Krosoft Support indicates that migration attention is required.
Admin actions can include:
* Opening the **RSVP Migration Console** from Connected Apps or Confluence administration.
* Initializing Forge RSVP storage for the site.
* Reviewing migration status for the installation.
* Importing historical Cloud RSVP data when instructed.
* Uploading and reviewing Server/Data Center migration files.
* Confirming that migrated macros show the expected responses.
If a macro shows a pending-import or migration message, review the migration console or contact Krosoft Support before editing affected RSVP pages.
## Licensing and migration messages
If the app license is inactive, existing responses remain visible, but new sign-ups, exports, and other mutation actions can be disabled until the license is restored.
If a macro shows a migration message, it means RSVP is protecting historical data or waiting for migration state to be verified. The message should be resolved through the migration console or Krosoft Support rather than by recreating the macro.
## Historical data tetention
Historical legacy Cloud RSVP data can be retained for migration during the support window communicated by Krosoft. If you need historical data imported, or if you want retained legacy data removed early, contact Krosoft Support.
## When to contact Support
Contact Krosoft Support before editing affected pages if:
* Historical RSVP responses appear to be missing.
* A macro shows a pending-import or migration message and you are unsure why.
* A migration import fails or page mappings look wrong.
* You need help importing Server/Data Center RSVP data.
* You need confirmation that a site has completed its RSVP migration.
* You want retained legacy RSVP data removed early.
For help, contact [support@krosoft.nl](mailto:support@krosoft.nl) or visit the [Krosoft Support Portal](https://krosoft.atlassian.net/servicedesk/customer/portals).
---
language: "en"
---
# Legacy Assets Macro Converter for Confluence
Scan, map, and convert legacy Insight and Assets macros after migrating from Confluence Server or Data Center to Confluence Cloud.
Legacy Assets Macro Converter helps Confluence administrators clean up migration leftovers. It finds pages that still contain deprecated Insight/Assets macros and converts supported macros to native Confluence Cloud Assets tables after the required Jira Service Management Assets data has been migrated to Cloud.
*** ** * ** ***
## Who this is for
* Confluence administrators managing Server/Data Center to Cloud migrations
* Teams replacing legacy Insight or Assets macros with native Cloud Assets tables
* Organizations that need a controlled cleanup workflow instead of manual page-by-page conversion
## What it does
* **Scan:** searches accessible Confluence spaces for legacy `assets-objects-macro` and `insight-objects-macro` content
* **Review:** shows affected spaces and pages so administrators can choose what to convert
* **Convert:** replaces supported legacy macros with native Confluence Cloud Assets table blocks
* **Map:** supports manual mappings and optional Jira Data Center auto-lookup for legacy schema IDs, object type IDs, object keys, and display columns
* **Repair:** moves or replaces native Assets tables that were placed inside unsupported embedded content such as `scroll-ignore`
* **Resume:** saves scan and conversion progress so longer cleanup work can continue safely
*** ** * ** ***
## Start here
* [User Manual](https://wiki.krosoft.nl/ekb/legacy-assets-macro-converter-for-confluence-user-manual.md)
* [End User License Agreement (EULA)](https://wiki.krosoft.nl/ekb/insight-assets-macro-finder-for-confluence-terms-o.md)
* Support: [support@krosoft.nl](mailto:support@krosoft.nl)
---
language: "en"
---
# Legacy Assets Macro Converter for Confluence - End User License Agreement (EULA)
**Effective Date:** 2024-08-30
## 1. Acceptance of Terms
By installing, accessing, or using the Legacy Assets Macro Converter ("the App"), you agree to comply with and be bound by these Terms of Use. If you do not agree to these terms, you may not use the App.
### 2. License
The App is licensed, not sold, to you by Krosoft for use strictly in accordance with these terms. Krosoft grants you a limited, non-exclusive, non-transferable, revocable license to use the App for your internal business purposes only.
### 3. Restrictions
You agree not to:
* Modify, decompile, reverse-engineer, disassemble, or otherwise attempt to derive the source code of the App.
* Use the App to infringe upon the intellectual property rights of others.
* Use the App for any unlawful purpose.
### 4. User Data and Privacy
The App does not collect, store, or transmit any personal data from your Confluence instance. It only processes the data necessary to identify and manage deprecated Insight and Assets macros. You are responsible for ensuring that your use of the App complies with applicable data protection laws.
### 5. Updates and Changes
Krosoft may provide updates to the App that enhance functionality or fix bugs. These updates are subject to these Terms of Use. Krosoft reserves the right to modify or discontinue the App at any time without prior notice.
### 6. Termination
Krosoft may terminate your use of the App at any time if you violate these Terms of Use. Upon termination, you must cease all use of the App and destroy all copies of it.
### 7. Limitation of Liability
To the maximum extent permitted by law, Krosoft shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising out of or related to your use of the App.
### 8. Governing Law
These Terms of Use shall be governed by and construed in accordance with the laws of The Netherlands. Any legal action or proceeding related to your use of the App shall be brought exclusively in the courts located within The Netherlands.
### 9. Contact Information
If you have any questions about these Terms of Use, please contact us at support@krosoft.nl.
### 10. Changes to Terms
Krosoft reserves the right to modify these Terms of Use at any time. Your continued use of the App after any such changes constitutes your acceptance of the new terms.
---
language: "en"
---
# Jira Automation Rules recipes
## Purpose
Use this reference when you want Planning Sync for Jira to forward Tempo plan events to Jira Automation and let Jira Automation send Slack notifications or update Slack status. This is documentation for building Jira Automation rules; it is not a native Slack integration, Slack OAuth setup, or importable Automation package.
The pattern is:
1. Planning Sync receives a Tempo plan event.
2. Planning Sync forwards the existing Automation webhook payload to a Jira Automation incoming webhook.
3. Jira Automation reads the webhook smart values and branches by event type.
4. Jira Automation performs the customer-owned Slack action, such as sending a channel message or calling a Slack/status webhook.
Planning Sync forwards payloads only. Jira Automation and Slack own Slack authorization, channel access, user mapping, status permissions, and the final action behavior.
## Prerequisites
Before setup, confirm that you have:
* Planning Sync Advanced edition, because Automation webhook forwarding is an Advanced feature.
* Administrator access to the Planning Sync configuration in Jira.
* Permission to create or edit Jira Automation rules.
* A Jira Automation incoming webhook URL.
* A Jira Automation Slack action, Slack connection, or customer-owned webhook action that is already permitted to perform the desired Slack operation.
* A decision about which Tempo plan events should trigger Slack behavior: `plan.created`, `plan.updated`, `plan.deleted`, or a subset.
* For Slack status updates, a tenant-specific way to map the Tempo plan assignee to a Slack user. Use `{{webhookData.tempoPlan.assigneeId}}` only when your Jira Automation or Slack setup can map that value.
## Planning Sync Automation webhook setup
1. In Jira, create a Jira Automation rule that starts with an incoming webhook trigger.
2. Copy the incoming webhook URL generated by Jira Automation.
3. In Jira, open **Apps** , then **Planning Sync** , then **Settings** , then **Advanced settings**.
4. Expand **Automation webhook**.
5. Enable Automation webhook forwarding.
6. Paste the Jira Automation incoming webhook URL.
7. Select the Tempo plan events to forward, such as `plan.created`, `plan.updated`, and `plan.deleted`.
8. Optionally store a webhook token if your Automation rule validates `X-Automation-Webhook-Token`.
9. Save the Automation webhook configuration.
10. Use **Send test webhook** to verify that Jira Automation receives the payload.
11. Open **Show rule templates** in Planning Sync for the in-app transition and Slack recipe snippets.
For runtime Tempo plan events, Planning Sync appends Jira Automation's `issue` query parameter when a related Jira issue key or id is available. Manual test deliveries use the same envelope with `test: true`, but they do not require a fake Jira issue.
## Common Automation smart values
Use these Jira Automation smart values from the incoming webhook payload:
| Smart value | Purpose |
|----------------------------------------|-----------------------------------------------------------------------------------|
| `{{webhookData.eventType}}` | Tempo plan event type, such as `plan.created`, `plan.updated`, or `plan.deleted`. |
| `{{webhookData.jiraIssue.key}}` | Related Jira work item key. |
| `{{webhookData.jiraIssue.summary}}` | Related Jira work item summary. |
| `{{webhookData.tempoPlan.startDate}}` | Tempo plan start date. |
| `{{webhookData.tempoPlan.endDate}}` | Tempo plan end date. |
| `{{webhookData.tempoPlan.assigneeId}}` | Tempo plan assignee id. Use only with customer-owned user mapping. |
| `{{webhookData.payload}}` | Raw Tempo payload for advanced Automation branches. |
## Recipe 1: Send a Slack channel notification
Use this recipe when a shared Slack channel should receive planning updates.
### Jira Automation rule outline
1. **Trigger: Incoming webhook**
* Use the Jira Automation incoming webhook URL saved in Planning Sync.
* Let the rule use the issue passed by the webhook when Jira Automation prompts for issue handling.
2. Optional **condition: Event type**
* Add a condition where `{{webhookData.eventType}}` equals one of:
* `plan.created`
* `plan.updated`
* `plan.deleted`
* Use separate branches if one rule should handle multiple events differently.
3. **Action: Send Slack message**
* Use Jira Automation's Slack message action.
* Choose the Slack channel from the Jira Automation and Slack connection available in your tenant.
* Paste or adapt the message example below.
Recommended Slack message:
{{webhookData.eventType}} for {{webhookData.jiraIssue.key}}: {{webhookData.jiraIssue.summary}} from {{webhookData.tempoPlan.startDate}} to {{webhookData.tempoPlan.endDate}}
Use this for operational notifications, planning channels, or project-specific channels where a simple event summary is enough.
## Recipe 2: Update a Slack status from Tempo planning
Use this recipe when a Tempo plan should drive a person's Slack status through customer-owned Jira Automation and Slack configuration.
Slack status updates are tenant-specific. Planning Sync does not store Slack users, request Slack OAuth, or call Slack APIs. Your Jira Automation rule, Slack app, or webhook endpoint must own the user lookup and status mutation.
### Jira Automation rule outline
1. **Trigger: Incoming webhook**
* Use the Jira Automation incoming webhook URL saved in Planning Sync.
2. **Condition: Created or updated plan**
* Run the status update when `{{webhookData.eventType}}` equals `plan.created` or `plan.updated`.
* Optionally add a separate `plan.deleted` branch to clear or reset status.
3. **Map the Slack user**
* Use `{{webhookData.tempoPlan.assigneeId}}` if your Jira Automation or Slack setup can map Tempo assignee ids to Slack users.
* Otherwise use a customer-owned mapping table, Automation lookup, or webhook service.
4. **Action: Customer-owned Slack/status action**
* Use a Jira Automation Slack action when it supports the desired status behavior in your tenant.
* Or use a Jira Automation webhook action that calls a customer-owned Slack integration endpoint.
* Configure Slack authorization, scopes, user mapping, and status permissions outside Planning Sync.
Recommended status text:
Planned on {{webhookData.jiraIssue.key}} until {{webhookData.tempoPlan.endDate}}
For deleted plans, decide whether the rule should clear the Slack status, set a fallback status, or do nothing. That behavior depends on your Slack status policy and how many active plans a person may have.
## Representative Automation webhook payload
Planning Sync sends a stable JSON envelope. The Slack recipes use the existing payload fields only; no Slack-specific fields are added.
JSON
{
"eventType": "plan.updated",
"forwardedAt": "2026-05-18T09:30:00.000Z",
"source": "planning-sync",
"tempoPlan": {
"id": "123456",
"startDate": "2026-05-18",
"endDate": "2026-05-20",
"planItemId": "10001",
"assigneeId": "557058:example"
},
"jiraIssue": {
"id": "10001",
"key": "TEST-1",
"projectKey": "TEST",
"issueTypeName": "Task",
"summary": "Example planned task"
},
"payload": {
"id": 123456,
"startDate": "2026-05-18",
"endDate": "2026-05-20",
"planItem": {
"id": "10001",
"type": "ISSUE"
},
"assignee": {
"id": "557058:example",
"type": "USER"
}
}
}
## Test checklist
Before considering the rule live, verify that:
* Automation webhook forwarding is enabled in Planning Sync.
* The saved webhook URL is the current Jira Automation incoming webhook URL.
* The intended Tempo event types are selected in Planning Sync.
* The matching Tempo plan listeners are enabled in Planning Sync.
* **Send test webhook** reaches the Jira Automation rule.
* A real created or updated Tempo plan triggers the rule.
* The Slack channel notification posts to the expected channel, if using the channel recipe.
* The Slack status action targets the expected Slack user, if using the status recipe.
* The `plan.deleted` branch clears, resets, or skips status exactly as your policy requires.
* Planning Sync audit logs show successful Automation webhook delivery, or failures that match Jira Automation responses.
## Troubleshooting
| Symptom | What to check |
|-------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Automation rule never starts | Confirm the Planning Sync Automation webhook URL is the current Jira Automation incoming webhook URL, forwarding is enabled, and the selected Tempo event type matches the test event. |
| Rule starts but no issue is selected | Test sends omit the Jira Automation `issue` query parameter. Use a real Tempo plan event linked to a Jira issue when validating issue-specific rule behavior. |
| Slack message does not send | Confirm the Jira Automation Slack connection, channel access, and rule actor permissions. Planning Sync only delivers the webhook payload. |
| Slack status updates the wrong user | Review the customer-owned mapping from `{{webhookData.tempoPlan.assigneeId}}` to Slack user id. Planning Sync does not manage Slack identity mapping. |
| Status is not cleared after plan deletion | Add or verify a `plan.deleted` branch, and decide whether deletion should clear status, set fallback text, or do nothing. |
| Smart values are empty | Confirm the Tempo event includes the expected Jira issue and Tempo plan fields. Use `{{webhookData.payload}}` for advanced fallback mapping when needed. |
| Delivery fails in Planning Sync | Review the Planning Sync audit logs and Jira Automation webhook response. Failed Automation webhook delivery is recorded for investigation. |
## Listener, Handling and scope checks
Enable the matching Tempo plan listener for every event selected in Automation webhook forwarding. The plan **Handling** toggle controls built-in Jira field updates, assignee mapping and approval requests; it can remain off when Jira Automation owns the downstream action. Turning Handling off does not replace the listener requirement.
The work item must also pass the configured global project/work-item-type scope. If a manual test reaches Automation but a real plan does not, check listener selection, global scope and the app's audit skip reasons before changing the rule or Slack connection.
Automation forwarding uses its own payload envelope and token configuration. The Outlook outbound-destination recipe uses a different custom body and daily occurrence preset; do not copy its payload expressions into these Automation smart values.
---
language: "en"
---
# Krosoft Trust Center
We're committed to transparency, data privacy, and responsible development. This page provides quick access to our security and data protection documentation for all paid Krosoft apps listed on the Atlassian Marketplace.
*** ** * ** ***
## Security \& Privacy Practices
Learn how we protect your data, what we collect (and don't), and how our architecture is built with security by design.
[View our Data Security \& Privacy Statement](https://wiki.krosoft.nl/ekb/data-security-and-privacy-statement)
*** ** * ** ***
### Data Processing Agreement (DPA)
We act as a GDPR-compliant data processor for our Atlassian apps and limit data storage to configuration-level data only. The DPA outlines how we handle and protect your data.
[Read the DPA](https://wiki.krosoft.nl/ekb/data-processing-agreement-dpa)
*** ** * ** ***
### Responsible Disclosure
If you discover a security vulnerability in one of our apps, please report it responsibly. We're a small team, but we take every report seriously and respond quickly.
Report to: [support@krosoft.nl](mailto:support@krosoft.nl)
*** ** * ** ***
### Covered Apps
This Trust Center applies to all paid Krosoft apps on the Atlassian Marketplace:
* [Related Issues for Jira Cloud](https://marketplace.atlassian.com/apps/1212247)
* RSVP for Confluence Cloud
* RSVP for Confluence Data Center
*** ** * ** ***
**Location:** The Netherlands
**Support \& Privacy Contact:** [support@krosoft.nl](mailto:support@krosoft.nl)
---
language: "en"
---
# Legacy Assets Macro Converter for Confluence - User Manual
Use this manual to configure and operate **Legacy Assets Macro Converter for Confluence** after a Confluence Server or Data Center migration to Confluence Cloud.
Last reviewed from the product repository: **May 31, 2026**.
## Overview
Legacy Assets Macro Converter for Confluence helps administrators find and clean up old Insight/Assets macros left behind after migration to Cloud.
The app can:
* Scan Confluence Cloud pages for legacy `assets-objects-macro` and `insight-objects-macro` storage macros.
* Show affected spaces and pages.
* Convert selected pages to native Confluence Cloud Assets table blocks.
* Repair native Assets tables that were placed inside unsupported `scroll-ignore` content.
* Map legacy Assets schema IDs, object type IDs, object keys, and display columns to Cloud equivalents.
* Resume long-running scans and conversions from saved state.
The app does **not** migrate Assets data. The relevant Jira Service Management Assets schemas, object types, objects, and attributes must already exist in Cloud.
## Before You Start
Confirm the following before running a production cleanup:
* Jira Service Management Assets is available in Cloud.
* The Cloud Assets data has already been migrated.
* The user or app can read the target Confluence spaces and pages.
* The user or app can edit pages that will be converted.
* The user or app can read the relevant Cloud Assets workspace, schemas, object types, attributes, and objects.
* You have tested conversion on a small sample page before running larger batches.
The app is available from Confluence global settings as **Legacy Assets Macro Converter**.
## Run Modes
Select a run mode before checking permissions, scanning, or converting.
| Mode | Use when | Behavior |
|-------------|-------------------------------------------------------------------------|--------------------------------------------------------------|
| Run as User | Content is restricted and should follow the current user's permissions. | Confluence and Assets calls run as the user opening the app. |
| Run as App | You want a consistent app-level permission set for bulk cleanup. | Confluence and Assets calls run as the Forge app. |
Use the same mode for the environment check, scan, and conversion unless you intentionally want separate results.
## Conversion Settings
Open **Mapping settings** before converting pages.
### Manual Mappings
Use **Manual mappings** when you know the Cloud equivalents for legacy IDs.
* **Schema ID map:** legacy schema ID to Cloud schema ID.
* **Object type ID map:** legacy object type ID to Cloud object type ID.
* **Legacy key attribute:** Cloud Assets attribute that stores old object keys. Default: `ORIGINAL_KEY`.
Use **Refresh schemas** to list visible Cloud schemas for the selected run mode.
### Data Center Auto-Lookup
Use **Data Center auto-lookup** when the original Jira Data Center Assets/Insight metadata is available.
First open **Source settings** and configure:
* Data Center URL, for example `https://jira.example.com`.
* Authentication method: username/password or personal access token.
* Username when using username/password.
* Password or token, stored as a Forge secret.
Click **Test connection** before saving. A successful test confirms Jira authentication and Data Center Assets schema access. Auto-lookup can then resolve legacy schemas, object types, numeric attribute IDs, and object keys by reading Data Center metadata and matching it to Cloud data.
Because Data Center lookup uses backend egress to the configured URL, the app does not qualify for the Runs on Atlassian badge while wildcard backend egress is present.
### Test Mapping
Use **Test mapping** before production conversion. Test with a known legacy schema, object type, object key, or display attribute. Treat failures as blockers and warnings as items to review before converting many pages.
## Scan Workflow
1. Select **Run as User** or **Run as App**.
2. Click **Check space permissions**.
3. Wait until the app reports accessible spaces.
4. Click **Start Scan**.
5. Review the space results table.
6. Click **View Pages** for a space to inspect affected pages.
The scan reads Confluence page storage and detects:
| Content type | Meaning |
|------------------------|-----------------------------------------------------------------------------------|
| Legacy macros | Pages containing `assets-objects-macro` or `insight-objects-macro`. |
| Embedded Assets tables | Native Assets tables inside unsupported `scroll-ignore` content that need repair. |
Scans are batched and resumable. If you reload or leave the page, the app can restore scan state and cached results. Use **Clear cached results** to remove stored scan data while keeping conversion settings.
## Convert Pages
Conversions start from the **View Pages** modal.
1. Select one or more pages.
2. Click **Convert selected pages**.
3. Watch batch progress, warnings, and failures.
4. Review converted pages in Confluence.
5. Rerun the scan to confirm cleanup.
For each page, the app prepares replacements first and updates the page once. It also checks the page version before writing. If someone edits the page during conversion, the app stops and asks you to restart that page's conversion.
The conversion uses:
* The original `iql` or `aql` macro parameter.
* Resolved Cloud Assets workspace and schema IDs.
* Rewritten object keys when old keys can be mapped to Cloud keys.
* Resolved display columns. The `Key` column is always included if missing.
If a column or mapping is ambiguous, the app records a warning instead of guessing.
## Unsupported `scroll-ignore` Content
Cloud Assets tables cannot remain inside unsupported `scroll-ignore` content. When this is detected, conversion pauses and asks what to do.
| Choice | Result |
|------------------------|-------------------------------------------------------------------------------------------------|
| Place outside | Move the converted or repaired Assets table outside the unsupported block. This is the default. |
| Convert to inline URL | Replace a simple single-object legacy macro with an inline Assets object link, when available. |
| Skip page and continue | Leave the page unchanged and continue the batch. |
Inline URL fallback is available only for a block with exactly one legacy Assets macro using a simple query such as `Key = ...` or `Key IN (...)`, and only when the app can resolve it to one Cloud Assets object.
## Data Storage
The app stores operational state so work can resume safely.
Stored in Forge app storage:
* Environment check result.
* Scan state and results.
* Conversion settings, excluding secrets.
* Page conversion job status, warnings, and errors.
Stored as a Forge secret:
* Data Center password or personal access token.
Stored in browser local storage:
* Last run mode.
* Client-side cached scan and batch conversion state.
## Rollback
The app updates pages by creating a new Confluence page version. If a result is not acceptable, restore the previous page version from Confluence page history.
## Troubleshooting
| Symptom | What to check |
|--------------------------------|--------------------------------------------------------------------------------------|
| **Start Scan** is disabled | Select a run mode and run **Check space permissions**. |
| No spaces found | Check Confluence permissions for the selected user/app. |
| Assets workspace error | Check Jira Service Management Assets access for the selected run mode. |
| Schema cannot be loaded | Add a manual schema mapping or configure Data Center auto-lookup. |
| Object type or columns fail | Check object type mappings, Data Center metadata, and Cloud Assets attribute access. |
| Page update fails | Check page edit restrictions and space/page permissions. |
| Page changed during conversion | Restart conversion for that page. |
| Batch pauses | Choose how to handle unsupported `scroll-ignore` content, or skip the page. |
| Data Center connection fails | Verify URL, credentials/token, REST access, and Assets schema permissions. |
For support, include the Cloud site URL, space key, page URL, run mode, mapping mode, relevant schema/object type/object key values, and the exact error or warning shown by the app.
Contact [support@krosoft.nl](mailto:support@krosoft.nl).
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration) - End User License Agreement (EULA)
Effective Date: 2025-06-01
## 1. Acceptance of Terms
By installing, accessing, or using **Planning Sync for Jira (Tempo Integration)** for Jira Cloud ("the App"), you agree to comply with and be bound by these Terms of Use. If you do not agree to these terms, you may not use the App.
## 2. License
The App is licensed, not sold, to you by Krosoft for use strictly in accordance with these terms. Krosoft grants you a limited, non-exclusive, non-transferable, revocable license to use the App for your internal business purposes only within your authorized Jira Cloud instance.
## 3. Restrictions
You agree not to:
* Modify, decompile, reverse-engineer, disassemble, or attempt to derive the source code of the App.
* Use the App to infringe upon the intellectual property rights of others.
* Use the App for any unlawful or unauthorized purpose.
* Circumvent or disable any security features of the App or Atlassian's platform.
## 4. User Data and Privacy
The App processes and stores only the data necessary to fulfill its functionality (for example, user-configured field mappings and Tempo webhook data via the Jira and Tempo APIs). All data remains within your Jira Cloud environment and is handled according to Atlassian's security and privacy model. The App does not transmit any data externally or store personal information beyond what is already present in your Jira site. You are responsible for ensuring compliance with applicable data protection regulations.
## 5. Updates and Changes
Krosoft may release updates to improve functionality, enhance compatibility, or resolve issues. Such updates are governed by these Terms of Use. Krosoft reserves the right to modify, suspend, or discontinue the App or any part of it at any time without prior notice.
## 6. Termination
Krosoft may terminate your access to the App if you violate these Terms of Use. Upon termination, your license will be revoked, and you must cease all use of the App.
## 7. Limitation of Liability
To the fullest extent permitted by applicable law, Krosoft shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from or related to your use of the App, even if Krosoft has been advised of the possibility of such damages.
## 8. Governing Law
These Terms of Use shall be governed by and construed in accordance with the laws of The Netherlands. Any disputes arising out of or relating to the App shall be subject to the exclusive jurisdiction of the Dutch courts.
## 9. Contact
Questions or concerns about this agreement may be directed to: [support@krosoft.nl](mailto:support@krosoft.nl)
## 10. Changes to Terms
Krosoft reserves the right to revise these Terms of Use at any time. Continued use of the App after changes become effective constitutes your acceptance of the revised terms.
---
language: "en"
---
# Outbound payload reference
Use this reference when building a custom outbound body or diagnosing missing values. It describes outbound destinations; Jira Automation has a separate envelope and smart values.
## Template roots
| Root | Meaning |
|--------------------|----------------------------------------------------------------------------------------------------------------|
| `payload` / `plan` | Aliases for the outgoing payload after orchestration. They are not separate guaranteed full Tempo API records. |
| `eventType` | `plan.created`, `plan.updated` or `plan.deleted`. Manual sync sends `plan.created`. |
| `issue` | Best-effort Jira enrichment, such as key, summary and URL. |
| `assignee` | Best-effort Jira-user enrichment, such as displayName and email. Lookup failure can leave only the ID. |
| `eventId` | Source webhook event ID when present. Do not use it as the calendar occurrence key. |
## Daily calendar fields
| Expression | Use |
|-------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
| `{{payload.id}}` | Complete occurrence identity. Match the same appointment for create, update and delete. |
| `{{payload.planId}}` | Parent plan reference; not a unique daily calendar key. |
| `{{payload.date}}` | Individual occurrence date. |
| `{{payload.startTime}}` / `{{payload.endTime}}` | Same-day time window when provided/enriched by the chosen preset. |
| `{{payload.date}}T{{payload.startTime}}` | Combined local datetime for a flow that expects startDateTime; use the matching endTime expression too. |
| `{{issue.key}}`, `{{issue.summary}}`, `{{issue.url}}` | Optional Jira details; allow missing values. |
| `{{assignee.displayName}}`, `{{assignee.email}}` | Optional display/routing inputs. Email may be hidden or absent; do not require it as identity. |
Keep IDs opaque. For example, `77.3`, `77.5` and `77.11` can all be valid retained identities. Suffixes are not current day positions. Removing and re-adding a date can reuse its historical identity; never renumber it. A genuine Tempo child allocation ID must also be preserved.
## Inspect a resolved request
1. In Power Automate, open **My flows**, select the receiving flow and open the relevant run in its run history.
2. Expand **When an HTTP request is received** and inspect its inputs/body. For this recipe, also inspect **Parse_JSON** inputs. These are resolved values, not the template expressions saved in Planning Sync.
3. Compare `eventType`, `occurrenceId`, dates and JSON types with the schema. Check create, update and delete separately; delete requests may omit time fields.
4. Share only a sanitized example: replace personal details and private planning text, and remove authentication headers, tokens and the full signed trigger URL.
If no run exists, check Planning Sync audit results and trigger/schema rejection first. Send the site, connection label, plan ID and approximate time to [Krosoft support](https://krosoft.atlassian.net/servicedesk/customer/portals) for help correlating the request. Do not assume that no flow run means no delivery attempt.
## Why a field becomes null
A value containing only one expression preserves the resolved JSON type. If the path is missing, the result is `null`, even when the expression is written inside JSON quotes. Embedded expressions in a longer string are interpolated as text; missing values contribute an empty string.
JSON
{
"seconds": "{{payload.plannedSeconds}}",
"optionalField": "{{payload.missingField}}",
"label": "Plan {{payload.id}}"
}
The result can contain a number for `seconds`, `null` for `optionalField`, and a string for `label`. Match the receiver schema to the actual resolved types; JSON quotes around a full expression do not force a string.
## Plan descriptions and user details
`{{plan.description}}` and `{{payload.description}}` address the same outgoing field. Switching between those roots does not recover a missing description. Daily orchestration or a source event may omit it. Inspect a sanitized resolved request for each event type before making the field required; description availability is not guaranteed in the current implementation. There is no confirmed general workaround for a missing description; contact Krosoft support if your integration depends on it. Do not infer a different nesting path from the destination's JSON output structure.
A missing Jira user lookup does not create a Microsoft identity. Generic-resource assignees must be routed explicitly and may have no Jira user name or email. Keep optional metadata out of correlation keys. Configure the receiver to reject an unknown route clearly instead of silently using another person's calendar.
## Create, update and delete
JSON
{
"sourceKey": "jira-test-outlook",
"eventType": "plan.created",
"occurrenceId": "46.3",
"parentPlanId": "46",
"date": "2026-10-07",
"startTime": "15:00",
"endTime": "17:00",
"issueKey": "TEST-123",
"assigneeName": null
}
This is a representative resolved daily request, not a guarantee that every optional field is present. An update to a retained planned date keeps the same `occurrenceId` and changes the relevant values. A date-range change can emit `plan.deleted` for removed dates before `plan.updated` for current dates. Retained dates keep their recorded keys; newly added dates receive a distinct key, or reuse their historical key if re-added. A receiver updates an exact existing match and creates an appointment when that current-date key is absent. Moving a single planned day to another date can therefore delete the old daily appointment and create the new one. This is different from deleting and recreating an appointment for every update. A minimal delete requires only the source key, event type and occurrence key:
JSON
{
"sourceKey": "jira-test-outlook",
"eventType": "plan.deleted",
"occurrenceId": "46.3"
}
Handle deletion before validating time fields. Both create and update must create the appointment when absent or update the exact match when present. A delete with no match is already complete; multiple matches need investigation.
## Choose the right mode
The daily strict preset is the basis of the Outlook recipe. Raw/whole-plan payloads are a different contract and may contain historical dates or recurrence metadata. Do not copy daily expressions into a whole-plan integration without inspecting its payload. For repeating daily planning, create individual appointments and leave Outlook recurrence off. Live unbounded recurrence and manual sync's 12-month expansion are different behaviors; use an explicit Until date for normal live calendar tests.
## Related guides
* [Set up the Outlook flow](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md)
* [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md)
* [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md)
---
language: "en"
---
# Partners
.png?cb=5f9d7260f7ecad92a585936d4a6d9a88)
Communardo Netherlands, Platinum Solution Partner
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration)
Planning Sync helps Jira admins automate data synchronization, workflow updates, Client Work Rate (CWR) reporting, approvals, auditability, and controlled outbound integrations across Jira Cloud and Tempo.
*** ** * ** ***
## Who this is for
* Jira administrators using Tempo products
* Teams that need Jira work items to reflect current planning data
* Organizations that want to automate plan-driven field updates with auditability and control
## What it does
* Syncs Tempo plan data into Jira fields based on configured mappings
* Supports webhook-driven updates for relevant plan events
* Provides configurable listeners, scope controls, and approval logic
* Can forward events to external destinations in Advanced scenarios
* Includes audit logging for operational visibility
*** ** * ** ***
## Start here
* [User Manual](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-user-manu.md)
* [Release Notes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-release-notes.md)
* Support: [support@krosoft.nl](mailto:support@krosoft.nl)
## Notes
Planning Sync requires a Tempo product and setup by a Jira administrator. Advanced capabilities depend on edition and configuration.
## Choose your setup
For practical integration instructions, open [Recipes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-recipes.md). Start with the [User Manual](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-user-manu.md) for installation, Tempo authentication, listeners and access.
For Outlook setup, initial sync, payloads and troubleshooting, choose your task in [Recipes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-recipes.md).
| Capability | Edition guidance |
|---------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| Tempo-to-Jira field mapping and plan-driven updates | Core setup; available controls depend on your installed edition and configuration. |
| Outbound destinations, Jira Automation forwarding, Compliancy, Hours rollup, Work attribute sync and Client Work Rate reporting | Advanced edition required. Feature-specific permissions and enable switches still apply. |
Check the app's License status before following an Advanced recipe. Installing Advanced does not automatically enable its integrations or grant calendar/Slack access.
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration)
Planning Sync helps Jira admins automate data synchronization, workflow updates, Client Work Rate (CWR) reporting, approvals, auditability, and controlled outbound integrations across Jira Cloud and Tempo.
*** ** * ** ***
## Who this is for
* Jira administrators using Tempo products
* Teams that need Jira work items to reflect current planning data
* Organizations that want to automate plan-driven field updates with auditability and control
## What it does
* Syncs Tempo plan data into Jira fields based on configured mappings
* Supports webhook-driven updates for relevant plan events
* Provides configurable listeners, scope controls, and approval logic
* Can forward events to external destinations in Advanced scenarios
* Includes audit logging for operational visibility
*** ** * ** ***
## Start here
* [User Manual](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-user-manu.md)
* [Release Notes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-release-notes.md)
* Support: [support@krosoft.nl](mailto:support@krosoft.nl)
## Notes
Planning Sync requires a Tempo product and setup by a Jira administrator. Advanced capabilities depend on edition and configuration.
## Choose your setup
For practical integration instructions, open [Recipes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-recipes.md). Start with the [User Manual](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-user-manu.md) for installation, Tempo authentication, listeners and access.
For Outlook setup, initial sync, payloads and troubleshooting, choose your task in [Recipes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-recipes.md).
| Capability | Edition guidance |
|---------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| Tempo-to-Jira field mapping and plan-driven updates | Core setup; available controls depend on your installed edition and configuration. |
| Outbound destinations, Jira Automation forwarding, Compliancy, Hours rollup, Work attribute sync and Client Work Rate reporting | Advanced edition required. Feature-specific permissions and enable switches still apply. |
Check the app's License status before following an Advanced recipe. Installing Advanced does not automatically enable its integrations or grant calendar/Slack access.
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration) - Recipes
Choose the task you want to complete. Start with the Outlook setup recipe if you do not yet have a receiving flow.
## Tempo plans to Outlook
| I want to... | Guide |
|------------------------|------------------------------------------------------------------------------------------------------------|
| Set up Outlook | [Sync Tempo plans to Outlook with Power Automate](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md) |
| Send existing planning | [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md) --- controlled staging evaluation |
| Understand payloads | [Outbound payload reference](https://wiki.krosoft.nl/ekb/outbound-payload-reference.md) |
| Recover a delivery | [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md) |
For installation, Tempo authentication and access, see the [User Manual](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-user-manu.md).
* [Sync Tempo plans to Outlook with Power Automate](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md)
* [Jira Automation Rules recipes](https://wiki.krosoft.nl/ekb/jira-automation-rules-recipes.md)
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration) - Release Notes
Published production release notes are listed below. Sandbox test deployments are separate and do not establish production availability or customer acceptance.
## Staging preview --- on-demand planning sync
The test deployment on 2026-10-08 adds [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md), queued delivery and failed-item retries for enabled test installations. Webhook acceptance is reported separately from downstream Outlook processing. Full discovery coverage and customer staging acceptance remain rollout checks. This entry does not announce production availability.
## Sandbox validation --- 6 October 2026
The H\&R Sandbox received the ordered plan-delivery and recurrence fixes associated with PSJ-246. Changes cover stable daily occurrence identities, removed-day deletes, rapid edits and finite recurring plans. Customer acceptance remains separate from development test results. Check your installation and the relevant support ticket before assuming these changes are available on your production site.
The latest production release listed in this index is planning-sync-6.4.0. This describes the documentation listing, not a live check of Marketplace or your installed version. For Tempo-to-Outlook configuration and acceptance tests, use the [Power Automate recipe](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md).
## Production release notes
* [Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.4.0 - 2026-06-02](https://wiki.krosoft.nl/ekb/release-notes-planning-sync-for-jira-tempo-integration-planning-sync-6-4-0-2026-06-02.md)
* [Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.3.0 - 2026-05-23](https://wiki.krosoft.nl/ekb/release-notes-planning-sync-for-jira-tempo-integration-planning-sync-6-3-0-2026-05-23.md)
* [Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.3.0 - 2026-05-20](https://wiki.krosoft.nl/ekb/release-notes-planning-sync-for-jira-tempo-integration-planning-sync-6-3-0-2026-05-20.md)
* [Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.2.0 - 2026-05-18](https://wiki.krosoft.nl/ekb/release-notes-planning-sync-for-jira-tempo-integration-planning-sync-6-2-0-2026-05-18.md)
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration) - User Manual
This guide explains how to install, set up, and operate Planning Sync for Jira (Tempo Integration).
It focuses on the configuration experience and the common happy-path setup.
## Audience
This manual is intended for:
* Jira administrators who install the app and manage access
* Users who were granted the Jira global permission to administer Planning Sync
* Project admins who need to understand what the automation does
* Space admins who need to understand what the automation does
* Jira users who view the Advanced edition Hours rollup panel on work items they can access
* Planning Sync administrators who ask the bundled Rovo Agents about retained audit, Compliancy, or Client Work Rate history
## What the app does
Planning Sync keeps Jira work item fields aligned with Tempo plan and worklog data. It can:
* Update Jira date or datetime fields from Tempo plan dates
* Clear Jira fields when plans are removed
* Sync assignee fields based on Tempo plan assignees
* Optionally push Jira fields back to Tempo plan updates
* Aggregate Tempo worklog hours by selected Tempo work attributes and write totals into Jira custom fields
* Relay Tempo plan events to Jira Automation and outbound HTTPS destinations
* Provide operational audit logs and Advanced edition Compliancy cases
* Show an Advanced edition Hours rollup panel in Jira work item views
* Answer Rovo questions about retained Planning Sync audit and Compliancy history through Planning Sync Time Machine
* Provide Client Work Rate reporting and a separate Client Work Rate Reporter Rovo Agent
## Installation and setup wizard
After installation, open Planning Sync from Jira app navigation and follow the wizard. The app appears as **Planning Sync** with the Planning Sync icon in Jira Apps navigation.
If the setup wizard is empty because the app was reinstalled, contact support before saving new configuration. Planning Sync shows a reinstall recovery panel on the first setup step and a compact dashboard card while setup is incomplete. Use **Copy support request** to collect the site ID, current installation ID, app/environment identifiers, and the support request text Krosoft needs to ask Atlassian to relink Forge-hosted storage.
## Prerequisites
Before starting the wizard, make sure you have:
* Access to Planning Sync through Jira admin rights, site admin rights, or the Jira global permission **Administer Planning Sync for Jira (Tempo Integration)**
* Tempo Timesheets or Tempo Capacity Planner installed
* A Tempo API token or OAuth 2.0 client
Planning Sync requires a Tempo product. Install one of these on your Jira Cloud site before setup:
* [Timesheets by Tempo](https://marketplace.atlassian.com/apps/6572/timesheets-by-tempo-jira-time-tracking?hosting=cloud&tab=overview)
* [Capacity Planner by Tempo](https://marketplace.atlassian.com/apps/1211881/capacity-planner-jira-team-resource-management-tempo?hosting=cloud&tab=overview)
## Create a Tempo API token
These steps are written for Tempo Timesheets administrators.
1. In Jira, go to **Apps -\> Tempo -\> Settings**.
2. Open **API Integration** , **Data Access** , or **API tokens**, depending on your Tempo version.
3. Select **Create token** or **Generate token**.
4. Give the token a clear name, for example `Planning Sync token`.
5. Copy the token immediately. Tempo shows it only once.
6. Store the token like a password in a secure vault or password manager.
If you cannot see the API token page, ask a Tempo admin to grant access or generate the token for you.
## Wizard steps
### Step one: Confirm Tempo
The app checks for Tempo Timesheets or Tempo Capacity Planner on the site. If the check is inconclusive, you can still continue and validate later. If Tempo appears unreachable or temporarily down, the app shows a warning and offers **Check again**.
If this is a reinstall, use the recovery panel before reconfiguring. Atlassian-hosted storage recovery is not automatic and must be requested by support.
### Step two: Authentication
Choose one authentication method:
* Tempo API token, which is simple and quick
* OAuth 2.0, which is recommended for longer term use
For a Tempo API token, paste the token into the token field and save.
For OAuth 2.0:
1. In Planning Sync, copy the Callback URL.
2. In Jira, go to **Apps -\> Tempo -\> Settings**.
3. Open **OAuth 2.0 Applications**.
4. Create a new confidential application and use the Planning Sync Callback URL as the redirect URI.
5. Copy the Client ID and Client Secret.
6. Save them in Planning Sync.
7. Select **Authorize** and complete the Tempo consent screen.
8. Confirm that Planning Sync reports an active connection.
### Step three: Webhook URL
Generate or refresh the webhook URL from the app when needed. Enable the required listeners in Planning Sync so the app can create or reconcile its Tempo subscriptions. Planning Sync manages both plan and worklog webhook subscriptions from the app.
### Step four: License status
The app reads your Marketplace license. Advanced features are available only with the Advanced edition.
Once these steps are complete, move to configuration and turn on the required listeners.
## Test instance checklist
Use this checklist to confirm a test or Marketplace review site is ready:
* Tempo Timesheets is installed and active
* A Tempo API token or OAuth connection is saved in the app
* The Planning Sync webhook URL resolves successfully
* Required Tempo plan and worklog listeners are enabled in the app
* At least one Jira project has mapped fields
## Configuration options
### Event listeners
Control which events should be processed:
* Tempo plan events: `plan.created`, `plan.updated`, `plan.deleted`
* Tempo worklog events: `worklog.created`, `worklog.updated`, `worklog.deleted`
* Jira work item events, optional
If a listener is off, the app ignores that event type.
For Tempo plan events, the **Handling** toggle controls built-in Jira field updates, assignee mapping, and plan approval requests only. Automation webhook forwarding can still run when built-in plan handling is off, as long as the matching Tempo listener is enabled, global scope allows the work item, and Automation webhook forwarding is configured for that event.
### Settings: Tempo to Jira
Map Tempo plan data into Jira fields:
* Latest plan end date -\> Jira date or datetime field
* First plan start date -\> Jira date or datetime field
* Plan assignee -\> Jira user picker field
* Work attribute hour aggregates -\> compatible Jira custom field, Advanced edition only
Behavior notes:
* When no plans remain, mapped date fields are cleared.
* For first plan start date, choose either upcoming plans only or all plans.
* Work attribute mappings refresh when an allowed issue view loads, so Jira exports can include stored field values.
* The Tempo work attribute selector is loaded from configured Tempo work attributes. Select the attribute instead of typing its key.
* Static-list filters can match Tempo option IDs, keys, names, labels, display names, or primitive tokens returned by Tempo.
* Work attribute mappings do not support custom JavaScript scripts. Unsupported script fields are discarded on save and never run.
### Settings: Jira to Tempo
Enable Jira to Tempo sync if you want Jira field updates to modify Tempo plans:
* Jira plan start date -\> Tempo plan start date
* Default assignee -\> Tempo plan assignee fallback
This sync runs only when the Jira listener is enabled.
### Global scope
Limit which work items are eligible for automation:
* Allowlist by Jira project
* Allowlist by work item type
When enabled, only allowed projects and work item types are processed.
### Plan approvals
Control when plans need approval:
* Required reviewer
* Threshold for older plan end dates
* Optional auto-approval rules
When approval requirements are not met, the plan is skipped and logged.
## Advanced settings layout
In **Settings -\> Advanced settings**, child sections start collapsed and are ordered as follows:
1. Compliance settings
2. CWR severity thresholds
3. Audit ingress webhook
4. Automation webhook
5. Work attribute sync
6. Hours rollup issue view
7. Global scope allowlist
8. Field availability
9. Assignee update rules
Expand only the section you need. Collapsed sections do not load their settings. Sections with enable switches show that switch first and reveal detailed controls only after the switch is on.
## Automation webhook forwarding
Advanced edition administrators can forward selected Tempo plan events to a native Jira Automation incoming webhook from **Settings -\> Advanced settings -\> Automation webhook**.
Setup steps:
1. Enable Automation webhook forwarding.
2. Paste the incoming webhook URL generated by the Jira Automation rule.
3. Select any combination of `plan.created`, `plan.updated`, and `plan.deleted`.
4. Optionally store a webhook token. Planning Sync sends it as `X-Automation-Webhook-Token`.
5. Use **Send test webhook** to verify the Automation rule receives the structured payload without requiring a sample Jira issue to exist.
6. Open **Automation rule templates** to copy transition and Slack-oriented recipes and payload smart values.
The matching Tempo plan listener must also be enabled. For example, forwarding `plan.deleted` depends on the `plan.deleted` listener being active.
The Tempo plan **Handling** toggle does not need to be enabled for Automation forwarding. Leave Handling off when you want Jira Automation to handle the event without Planning Sync updating built-in Jira fields, assignees, or plan approvals.
Planning Sync forwards payloads only. Jira Automation owns transitions, comments, notifications, Slack actions, permissions, and user mapping. Runtime Tempo plan events include Jira Automation's `issue` query parameter when the related work item key is available. Manual test sends omit that query parameter and mark the payload with `test: true`.
For admin-ready examples, see [Jira Automation Slack planning recipes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-recipes.md).
## Compliance settings
Advanced edition administrators can use **Settings -\> Advanced settings -\> Compliance settings** to:
* Enable Compliancy before destructive audit, case catalog, and alert controls are shown
* Enable or disable the Planning Sync Time Machine Rovo Agent
* Configure destructive audit field selectors and frozen-period governance behavior
* Configure alert settings such as lookback window and thresholds
* Configure alert webhook delivery with an HTTPS URL, optional shared secret, resolved toggle, and manual test send
* Use structured webhook fields such as `compliancyCases` and `ruleCaseBuckets` with JSONPath in Jira Automation
Alert results are reviewed in **Compliancy -\> Alerts**.
## Work attribute sync
Advanced edition administrators can use **Settings -\> Advanced settings -\> Work attribute sync** to aggregate Tempo worklog hours into Jira custom fields by selected work attributes.
Setup steps:
1. Enable Work attribute sync.
2. Select a Tempo work attribute discovered from Tempo work attributes.
3. Optionally filter by a static-list value when Tempo provides values, or type a value for other attribute types.
4. Select a compatible Jira custom field as the target. Compatible targets currently include Jira number/float custom fields and plain text custom fields.
5. Choose number or text output.
When an allowed Hours rollup issue view loads for a Jira user who can view the issue, Planning Sync reloads current Tempo worklogs for the issue, sums the hours that match the selected attribute key and optional value filter, and updates the Jira field. Issue-view refresh uses Jira issue visibility, Advanced edition access, and the Hours rollup project allowlist.
Configuration, compatible field lookup, Tempo metadata lookup, and manual sync stay administrator-only.
If no worklogs match, number output writes `0` and text output writes an empty string. When Work attribute sync is disabled, issue-view and webhook refreshes skip Jira field writes while retaining saved mappings. When Tempo reports that the issue worklog scan was truncated, Planning Sync skips the Jira field write and keeps the previous aggregate value instead of storing a partial total.
## Outbound destinations
Advanced edition administrators can forward Tempo events to external systems.
* Add one or more HTTPS destinations
* Configure an optional shared secret for request verification
* Choose which Tempo events to forward
* Pick payload mode: raw Tempo data or custom JSON
Plan-event delivery is queued in order per parent plan and destination. A failed delivery can hold later requests in that stream while other plans continue. Receivers must handle repeated deliveries safely. **Accepted by webhook** confirms a successful HTTP response; Power Automate processing and Outlook connector retries remain the flow's responsibility. See [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md).
To keep Outlook appointments aligned with Tempo, follow [Sync Tempo plans to Outlook with Power Automate](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md). The recipe covers the daily-event preset, complete occurrence IDs, calendar lookup, create/update/delete actions and a test checklist.
For daily calendar integrations, match each appointment by the complete `payload.id`, and build its times from the daily `payload.date` and time fields. Parent `planId` does not uniquely identify a day. Repeating plans produce separate appointments; leave Outlook recurrence off. Use an explicit Until date and check it after changing Repeat. Existing incorrect appointments need controlled cleanup with support.
### Sync existing planning --- controlled staging evaluation
Send eligible existing planning to one enabled outbound connection and review discovery and delivery results. Contact [Krosoft support](https://krosoft.atlassian.net/servicedesk/customer/portals) for availability on your installation. Follow [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md) for scope, prerequisites and completion checks. The operation does not change Jira fields or approvals.
## Hours rollup issue view
Advanced edition administrators can use **Settings -\> Advanced settings -\> Hours rollup issue view** to:
* Enable or disable the work item view rollup panel globally
* Restrict the panel to specific Jira projects with the project allowlist
* Optionally select a Tempo work attribute, such as `Project code`, to show a grouped breakdown for the same rolled-up issue scope
* Add manual label overrides only when Tempo returns static-list IDs that cannot be resolved from metadata, for example `d8421f91-c947-49da-9a0a-3190271a2106 = 100%`
When enabled and allowlisted, supported parent work item views show an **Hours rollup** panel with **Powered by Planning Sync** shown as secondary header text in the collapsed surface. Unsupported work item views stay hidden.
The top row is always **Total logged** . Parent work items show generation rows such as **Children** , **Grandchildren** , and **Nested grandchildren** , including linked descendants from other Jira projects. Sub-tasks are not shown as separate items except at the lowest non-subtask level, where a **Subtasks** row can appear. If an attribute breakdown is enabled, the panel also shows grouped worklog totals such as project-code totals.
Users do not need the Planning Sync administrator permission to load this issue details panel. They must be able to view the Jira issue, the site must have Advanced edition access, and the issue project must be allowed by the Hours rollup project allowlist.
When Work attribute sync is enabled, the panel also starts a best-effort refresh of configured Work attribute sync fields under the same issue visibility, Advanced edition, and Hours rollup project gates.
When the feature is disabled, or when the current project is not allowlisted, the work item view panel stays visible but explains why rollup data is unavailable.
## Audit logs and Compliancy cases
Advanced edition administrators can review recent actions and webhook activity.
* Admin page: full operational audit log
* Admin page: dedicated Compliancy tab for auditable action cases
* Compliancy cases support free-text search, case-type filtering, acknowledgement filtering, and loading older matching cases with the last applied filters
* Project tab: project-scoped Planning Log for Planning Sync actions
Compliancy cases cover destructive actions, archived items with cached direct and descendant booked hours, frozen-period governance, and tracked field mapping changes.
## Planning Sync Time Machine Rovo Agent
Advanced edition administrators can use **Planning Sync Time Machine** from Rovo chat/sidebar to ask natural-language questions about retained Planning Sync history, such as:
* What happened to TEST-123 last week?
* Show risky compliancy cases in project TEST this month.
* Why did Planning Sync skip updates recently?
* Summarize deleted worklog or issue evidence for TEST-123.
Time Machine is read-only. It searches Planning Sync's retained operational audit entries and Advanced Compliancy cases only. It does not search native Jira changelogs, native Tempo history, Slack, email, or external APIs. Results keep **Operational audit** and **Compliancy case** source labels visible so you can tell runtime telemetry apart from governance findings.
Access and limits:
* You need Planning Sync administration access through the app global permission or Jira admin rights.
* The site needs Advanced edition access, except Forge development environments used for testing.
* An administrator must enable **Settings -\> Advanced settings -\> Compliance settings -\> Enable Planning Sync Time Machine** before the agent can query retained history.
* The action returns compact summaries only, defaults to 10 results, and caps output at 25 entries.
* Raw request bodies, raw webhook payloads, and oversized body fields are intentionally not exposed to Rovo.
## Reporting and Client Work Rate
Advanced edition administrators can use **Reporting** in the Planning Sync admin navigation to configure and verify manager-facing reports. Client Work Rate is the first report available there, and managers can use the separate **Client Work Rate Reporter** Rovo Agent after it is enabled.
By default, only Planning Sync administrators can use the CWR Rovo Agent. Administrators can configure one Jira group whose members may read saved CWR snapshots through Rovo without opening Planning Sync admin pages. Group-only users cannot generate or refresh snapshots.
Client Work Rate is calculated as:
`CWR = Productive hours / Available hours`
Definitions:
* Productive hours are all hours related to client work.
* Available hours are scheduled working hours minus leave, non-working holidays, and configured Account-exclusion worklogs.
* Client work is selected by one source: live Tempo Account Categories or live Tempo Accounts.
* Account exclusions reduce Available hours without being reported as Leave, Productive, or non-productive time.
* Leave can come from selected Leave Accounts, Jira Leave JQL matching, issue-field leave, and Tempo holiday schemes.
In payloads, scheduled working hours before reductions map to `grossAvailableHours`, leave plus non-working holiday reductions map to `leaveHours`, and final availability maps to `availableHours`. Report rows can also include `grossAvailableFte`, `leaveFte`, and `availableFte`.
In **CWR setup**, administrators can:
* Enable or disable Client Work Rate reporting
* Set the report name shown in dashboard summaries and Rovo responses
* Configure a CWR Rovo access group from live Jira group lookup or an exact group name
* Choose Tempo teams to include from a live Tempo Teams multi-select
* Add team-specific Rovo Team Name overrides
* Exclude selected live Tempo team members from calculations without changing Tempo membership
* Choose whether client work is selected by Account Categories or specific Accounts
* Choose Account exclusions for Available hours
* Choose Leave Accounts and Jira Leave JQL rules for Vacation, Sick Leave, and Other Leave
* Enable Tempo team commitment weighting when split-role users should have Available and Leave hours reduced by team commitment
* Choose an Automatic snapshots cadence
In **Monthly report**, administrators can:
* Choose a month and year without expanding setup
* Load a saved report when a snapshot exists
* Generate or refresh a report for the selected period
* Review Snapshot and Rovo status
* Watch queued or running refresh progress with current step, progress bar, and estimated remaining time
* Review formula breakdown, executive exceptions, warning lists, row-level details, and retained source evidence
Below-target exception severity is gradual. With the default target of 75%, CWR below 50% is critical, CWR from 50% to below 75% is warning, and CWR at 75% or higher has no below-target exception. In **Settings -\> Advanced settings -\> CWR severity thresholds**, administrators can turn on custom thresholds.
Use **Client Work Rate Reporter** from Rovo chat/sidebar for prompts such as:
* Generate CWR for May 2026.
* Show people below target for May 2026.
* Generate CWR for Communardo Netherlands for May 2026.
* Explain why Alex's CWR is low.
The month-scoped starter prompts shown by Rovo are generated during app deployment, not at chat runtime. They point at the previous UTC calendar month in `Month YYYY` format, so a June 2026 deployment shows `May 2026`. You can still type a different month when you need another saved CWR snapshot.
Rovo uses saved backend snapshots by default and must not invent CWR calculations. If no saved snapshot exists, ask a Planning Sync administrator to generate or refresh the saved monthly snapshot for the configured Teams to include scope.
## Audit ingress receipts
Advanced edition administrators can configure Planning Sync to receive signed callbacks after an external system successfully submits a Jira worklog.
Setup steps:
1. In **Settings -\> Advanced settings -\> Audit ingress webhook** , select **Get audit webhook config** to generate or fetch the dedicated URL and setup metadata.
2. Rotate the audit ingress shared secret before setup.
3. Configure each sender to sign the raw JSON body with HMAC-SHA256.
4. Send the hex signature in the `x-planning-sync-audit-signature` header.
5. Use the dedicated audit ingress webhook URL only for audit ingress senders. Do not use the Tempo webhook URL.
Planning Sync accepts only `schema_version: planning-sync.audit_event.v1` and `event_type: worklog.submitted`.
Accepted requests return `receipt_id`, `event_id`, `accepted: true`, and `duplicate`. Duplicate `event_id` deliveries return the same receipt with `duplicate: true`.
A missing or mismatched HMAC signature returns HTTP 403. Payload/schema validation failures return HTTP 400 with the validation error in the response body. Planning Sync stores only sanitized Jira/worklog claim metadata and rejects payloads containing raw browser, email, calendar, or evidence fields.
## Daily usage
After setup, normal usage looks like this:
* Tempo plans are created or updated.
* The app updates Jira fields based on your mappings.
* When an allowed Hours rollup issue view is opened by a Jira user who can view the issue, mapped work attribute aggregates refresh into Jira custom fields for export.
* Selected Tempo plan events are forwarded to Jira Automation when Automation webhook forwarding is enabled, even if built-in Tempo plan handling is disabled for that event.
* Tempo worklog events are processed when the related listeners and features are enabled.
* The audit log records changes and skips.
* Planning Sync Time Machine can summarize retained audit and Compliancy records for administrators from Rovo when Advanced access is available.
* Client Work Rate Reporter can answer from saved CWR snapshots when reporting is enabled and access rules allow it.
## Troubleshooting tips
### No updates in Jira
* Confirm the Planning Sync webhook URL resolves and app subscriptions were created successfully.
* Ensure the relevant listener is enabled.
* Check global scope allowlist settings.
* Check audit log entries for errors or skips.
### Audit log is empty
* Confirm the site has Advanced edition access.
* Generate new events after enabling the feature.
### Time Machine cannot find an event
* Confirm **Enable Planning Sync Time Machine** is on in Advanced settings.
* Confirm the event exists in retained Planning Sync audit or Compliancy history.
* Narrow the question with an issue key, project key, date range, or source type.
* Remember that Time Machine does not crawl native Jira or Tempo history outside Planning Sync storage.
### Client Work Rate Reporter cannot produce a report
* Confirm Client Work Rate is enabled in Reporting.
* Confirm the user has Planning Sync administration access or belongs to the configured CWR Rovo access group.
* Confirm a saved monthly snapshot exists for the requested month and configured team scope.
* Ask a Planning Sync administrator to generate or refresh the saved snapshot if needed.
### Webhook verification: check the integration direction
* **Tempo → Planning Sync:** check the current Planning Sync webhook URL, enabled Tempo listeners/subscriptions and the inbound verification settings for that connection. Do not substitute an outbound destination secret.
* **Planning Sync → external destination:** the optional destination secret adds an X-Signature header. The receiving system must verify it against the exact received body. Saving a secret in Planning Sync does not make Power Automate validate it automatically.
* **Audit ingress → Planning Sync:** check the audit-ingress configuration and compute its HMAC over the exact raw JSON body sent to Planning Sync.
* **Planning Sync → Jira Automation:** use the rule's current incoming-webhook URL and, where required, its token sent as X-Automation-Webhook-Token. This token is separate from destination signature secrets.
Never include full webhook URLs, tokens or secrets in customer-facing screenshots or support comments. Share sanitized request fields and error messages instead.
### Empty setup after reinstall
* Stop configuration changes until recovery expectations are confirmed.
* Copy the reinstall recovery support request from the first setup step or dashboard setup-readiness card.
* Send it to support within 21 days of uninstall so Atlassian can process it before the 28-day Forge-hosted storage retention ends.
## Where to find pages
* Planning Sync admin page: Jira app navigation -\> Planning Sync
* Project log: Jira project navigation -\> Planning Log
* Hours rollup issue view: Jira work item view -\> Hours rollup panel, when Advanced edition and project allowlist allow it
* Rovo Agents: Rovo chat/sidebar -\> Planning Sync Time Machine or Client Work Rate Reporter, when enabled and access rules allow it
## Access control
Planning Sync access is controlled through the Jira global permission **Administer Planning Sync for Jira (Tempo Integration)**.
* Jira administrators receive this permission by default on first install.
* Jira administrators can grant or revoke access for individual users or groups in Jira global permissions.
* Users without this permission, and who are not Jira admins or site admins, do not see the Planning Sync entry in the left navigation and cannot use admin/configuration screens.
* Advanced settings, outbound destinations, audit logs, Compliancy, Reporting setup, and Work attribute sync configuration require Planning Sync administration access and Advanced edition access, except in development environments used for testing.
* Planning Sync Time Machine follows the admin access gate plus Advanced edition gate.
* Client Work Rate Reporting setup requires Planning Sync administration access and Advanced edition access.
* Client Work Rate Reporter can allow one configured Jira group to read saved CWR snapshots without granting Planning Sync administration access or refresh rights.
* Work attribute sync configuration, compatible field lookup, Tempo metadata lookup, and manual sync require Planning Sync administration access.
* The Jira issue details **Hours rollup** panel and its best-effort Work attribute field refresh are separate from admin navigation. They can run for non-admin users who can view the issue when Advanced edition access and the configured project allowlist permit it.
## Diagnose outbound delivery
1. Confirm the correct destination is enabled, the expected events are selected, the matching Tempo listeners are active and the work item passes global scope.
2. Find the source plan's audit entries. **Queued plan event for ordered processing** means accepted for background processing; it does not mean Outlook changed.
3. Check subsequent destination delivery entries and skip reasons. **Completed ordered plan processing** can include an intentional skip; confirm successful delivery to the intended destination separately.
4. For pending/failed work, inspect connection errors, 429 throttling, mapping lookup errors or persistence errors. Resolve the cause and allow retries; do not bypass a failed parent event by replaying later changes.
5. Check the receiver's run history and final calendar state. A 202 or early 200 may acknowledge receipt before its actions finish. Match the full occurrence ID and daily dates.
6. If the audit requests controlled resync or IDs are unknown, contact support before cleaning up or replaying. Provide sanitized plan ID, event type, timestamp/time zone, destination label, audit result and receiver error. Preserve unrelated appointments.
Delivery order follows the order accepted by the app; it cannot reconstruct source changes received out of order. Do not manually replay an old create/update after its delete.
---
language: "en"
---
# Planning Sync for Jira (Tempo Integration) - User Manual
This guide explains how to install, set up, and operate Planning Sync for Jira (Tempo Integration).
It focuses on the configuration experience and the common happy-path setup.
## Audience
This manual is intended for:
* Jira administrators who install the app and manage access
* Users who were granted the Jira global permission to administer Planning Sync
* Project admins who need to understand what the automation does
* Space admins who need to understand what the automation does
* Jira users who view the Advanced edition Hours rollup panel on work items they can access
* Planning Sync administrators who ask the bundled Rovo Agents about retained audit, Compliancy, or Client Work Rate history
## What the app does
Planning Sync keeps Jira work item fields aligned with Tempo plan and worklog data. It can:
* Update Jira date or datetime fields from Tempo plan dates
* Clear Jira fields when plans are removed
* Sync assignee fields based on Tempo plan assignees
* Optionally push Jira fields back to Tempo plan updates
* Aggregate Tempo worklog hours by selected Tempo work attributes and write totals into Jira custom fields
* Relay Tempo plan events to Jira Automation and outbound HTTPS destinations
* Provide operational audit logs and Advanced edition Compliancy cases
* Show an Advanced edition Hours rollup panel in Jira work item views
* Answer Rovo questions about retained Planning Sync audit and Compliancy history through Planning Sync Time Machine
* Provide Client Work Rate reporting and a separate Client Work Rate Reporter Rovo Agent
## Installation and setup wizard
After installation, open Planning Sync from Jira app navigation and follow the wizard. The app appears as **Planning Sync** with the Planning Sync icon in Jira Apps navigation.
If the setup wizard is empty because the app was reinstalled, contact support before saving new configuration. Planning Sync shows a reinstall recovery panel on the first setup step and a compact dashboard card while setup is incomplete. Use **Copy support request** to collect the site ID, current installation ID, app/environment identifiers, and the support request text Krosoft needs to ask Atlassian to relink Forge-hosted storage.
## Prerequisites
Before starting the wizard, make sure you have:
* Access to Planning Sync through Jira admin rights, site admin rights, or the Jira global permission **Administer Planning Sync for Jira (Tempo Integration)**
* Tempo Timesheets or Tempo Capacity Planner installed
* A Tempo API token or OAuth 2.0 client
Planning Sync requires a Tempo product. Install one of these on your Jira Cloud site before setup:
* [Timesheets by Tempo](https://marketplace.atlassian.com/apps/6572/timesheets-by-tempo-jira-time-tracking?hosting=cloud&tab=overview)
* [Capacity Planner by Tempo](https://marketplace.atlassian.com/apps/1211881/capacity-planner-jira-team-resource-management-tempo?hosting=cloud&tab=overview)
## Create a Tempo API token
These steps are written for Tempo Timesheets administrators.
1. In Jira, go to **Apps -\> Tempo -\> Settings**.
2. Open **API Integration** , **Data Access** , or **API tokens**, depending on your Tempo version.
3. Select **Create token** or **Generate token**.
4. Give the token a clear name, for example `Planning Sync token`.
5. Copy the token immediately. Tempo shows it only once.
6. Store the token like a password in a secure vault or password manager.
If you cannot see the API token page, ask a Tempo admin to grant access or generate the token for you.
## Wizard steps
### Step one: Confirm Tempo
The app checks for Tempo Timesheets or Tempo Capacity Planner on the site. If the check is inconclusive, you can still continue and validate later. If Tempo appears unreachable or temporarily down, the app shows a warning and offers **Check again**.
If this is a reinstall, use the recovery panel before reconfiguring. Atlassian-hosted storage recovery is not automatic and must be requested by support.
### Step two: Authentication
Choose one authentication method:
* Tempo API token, which is simple and quick
* OAuth 2.0, which is recommended for longer term use
For a Tempo API token, paste the token into the token field and save.
For OAuth 2.0:
1. In Planning Sync, copy the Callback URL.
2. In Jira, go to **Apps -\> Tempo -\> Settings**.
3. Open **OAuth 2.0 Applications**.
4. Create a new confidential application and use the Planning Sync Callback URL as the redirect URI.
5. Copy the Client ID and Client Secret.
6. Save them in Planning Sync.
7. Select **Authorize** and complete the Tempo consent screen.
8. Confirm that Planning Sync reports an active connection.
### Step three: Webhook URL
Generate or refresh the webhook URL from the app when needed. Enable the required listeners in Planning Sync so the app can create or reconcile its Tempo subscriptions. Planning Sync manages both plan and worklog webhook subscriptions from the app.
### Step four: License status
The app reads your Marketplace license. Advanced features are available only with the Advanced edition.
Once these steps are complete, move to configuration and turn on the required listeners.
## Test instance checklist
Use this checklist to confirm a test or Marketplace review site is ready:
* Tempo Timesheets is installed and active
* A Tempo API token or OAuth connection is saved in the app
* The Planning Sync webhook URL resolves successfully
* Required Tempo plan and worklog listeners are enabled in the app
* At least one Jira project has mapped fields
## Configuration options
### Event listeners
Control which events should be processed:
* Tempo plan events: `plan.created`, `plan.updated`, `plan.deleted`
* Tempo worklog events: `worklog.created`, `worklog.updated`, `worklog.deleted`
* Jira work item events, optional
If a listener is off, the app ignores that event type.
For Tempo plan events, the **Handling** toggle controls built-in Jira field updates, assignee mapping, and plan approval requests only. Automation webhook forwarding can still run when built-in plan handling is off, as long as the matching Tempo listener is enabled, global scope allows the work item, and Automation webhook forwarding is configured for that event.
### Settings: Tempo to Jira
Map Tempo plan data into Jira fields:
* Latest plan end date -\> Jira date or datetime field
* First plan start date -\> Jira date or datetime field
* Plan assignee -\> Jira user picker field
* Work attribute hour aggregates -\> compatible Jira custom field, Advanced edition only
Behavior notes:
* When no plans remain, mapped date fields are cleared.
* For first plan start date, choose either upcoming plans only or all plans.
* Work attribute mappings refresh when an allowed issue view loads, so Jira exports can include stored field values.
* The Tempo work attribute selector is loaded from configured Tempo work attributes. Select the attribute instead of typing its key.
* Static-list filters can match Tempo option IDs, keys, names, labels, display names, or primitive tokens returned by Tempo.
* Work attribute mappings do not support custom JavaScript scripts. Unsupported script fields are discarded on save and never run.
### Settings: Jira to Tempo
Enable Jira to Tempo sync if you want Jira field updates to modify Tempo plans:
* Jira plan start date -\> Tempo plan start date
* Default assignee -\> Tempo plan assignee fallback
This sync runs only when the Jira listener is enabled.
### Global scope
Limit which work items are eligible for automation:
* Allowlist by Jira project
* Allowlist by work item type
When enabled, only allowed projects and work item types are processed.
### Plan approvals
Control when plans need approval:
* Required reviewer
* Threshold for older plan end dates
* Optional auto-approval rules
When approval requirements are not met, the plan is skipped and logged.
## Advanced settings layout
In **Settings -\> Advanced settings**, child sections start collapsed and are ordered as follows:
1. Compliance settings
2. CWR severity thresholds
3. Audit ingress webhook
4. Automation webhook
5. Work attribute sync
6. Hours rollup issue view
7. Global scope allowlist
8. Field availability
9. Assignee update rules
Expand only the section you need. Collapsed sections do not load their settings. Sections with enable switches show that switch first and reveal detailed controls only after the switch is on.
## Automation webhook forwarding
Advanced edition administrators can forward selected Tempo plan events to a native Jira Automation incoming webhook from **Settings -\> Advanced settings -\> Automation webhook**.
Setup steps:
1. Enable Automation webhook forwarding.
2. Paste the incoming webhook URL generated by the Jira Automation rule.
3. Select any combination of `plan.created`, `plan.updated`, and `plan.deleted`.
4. Optionally store a webhook token. Planning Sync sends it as `X-Automation-Webhook-Token`.
5. Use **Send test webhook** to verify the Automation rule receives the structured payload without requiring a sample Jira issue to exist.
6. Open **Automation rule templates** to copy transition and Slack-oriented recipes and payload smart values.
The matching Tempo plan listener must also be enabled. For example, forwarding `plan.deleted` depends on the `plan.deleted` listener being active.
The Tempo plan **Handling** toggle does not need to be enabled for Automation forwarding. Leave Handling off when you want Jira Automation to handle the event without Planning Sync updating built-in Jira fields, assignees, or plan approvals.
Planning Sync forwards payloads only. Jira Automation owns transitions, comments, notifications, Slack actions, permissions, and user mapping. Runtime Tempo plan events include Jira Automation's `issue` query parameter when the related work item key is available. Manual test sends omit that query parameter and mark the payload with `test: true`.
For admin-ready examples, see [Jira Automation Slack planning recipes](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-recipes.md).
## Compliance settings
Advanced edition administrators can use **Settings -\> Advanced settings -\> Compliance settings** to:
* Enable Compliancy before destructive audit, case catalog, and alert controls are shown
* Enable or disable the Planning Sync Time Machine Rovo Agent
* Configure destructive audit field selectors and frozen-period governance behavior
* Configure alert settings such as lookback window and thresholds
* Configure alert webhook delivery with an HTTPS URL, optional shared secret, resolved toggle, and manual test send
* Use structured webhook fields such as `compliancyCases` and `ruleCaseBuckets` with JSONPath in Jira Automation
Alert results are reviewed in **Compliancy -\> Alerts**.
## Work attribute sync
Advanced edition administrators can use **Settings -\> Advanced settings -\> Work attribute sync** to aggregate Tempo worklog hours into Jira custom fields by selected work attributes.
Setup steps:
1. Enable Work attribute sync.
2. Select a Tempo work attribute discovered from Tempo work attributes.
3. Optionally filter by a static-list value when Tempo provides values, or type a value for other attribute types.
4. Select a compatible Jira custom field as the target. Compatible targets currently include Jira number/float custom fields and plain text custom fields.
5. Choose number or text output.
When an allowed Hours rollup issue view loads for a Jira user who can view the issue, Planning Sync reloads current Tempo worklogs for the issue, sums the hours that match the selected attribute key and optional value filter, and updates the Jira field. Issue-view refresh uses Jira issue visibility, Advanced edition access, and the Hours rollup project allowlist.
Configuration, compatible field lookup, Tempo metadata lookup, and manual sync stay administrator-only.
If no worklogs match, number output writes `0` and text output writes an empty string. When Work attribute sync is disabled, issue-view and webhook refreshes skip Jira field writes while retaining saved mappings. When Tempo reports that the issue worklog scan was truncated, Planning Sync skips the Jira field write and keeps the previous aggregate value instead of storing a partial total.
## Outbound destinations
Advanced edition administrators can forward Tempo events to external systems.
* Add one or more HTTPS destinations
* Configure an optional shared secret for request verification
* Choose which Tempo events to forward
* Pick payload mode: raw Tempo data or custom JSON
Plan-event delivery is queued in order per parent plan and destination. A failed delivery can hold later requests in that stream while other plans continue. Receivers must handle repeated deliveries safely. **Accepted by webhook** confirms a successful HTTP response; Power Automate processing and Outlook connector retries remain the flow's responsibility. See [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md).
To keep Outlook appointments aligned with Tempo, follow [Sync Tempo plans to Outlook with Power Automate](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md). The recipe covers the daily-event preset, complete occurrence IDs, calendar lookup, create/update/delete actions and a test checklist.
For daily calendar integrations, match each appointment by the complete `payload.id`, and build its times from the daily `payload.date` and time fields. Parent `planId` does not uniquely identify a day. Repeating plans produce separate appointments; leave Outlook recurrence off. Use an explicit Until date and check it after changing Repeat. Existing incorrect appointments need controlled cleanup with support.
### Sync existing planning --- controlled staging evaluation
Send eligible existing planning to one enabled outbound connection and review discovery and delivery results. Contact [Krosoft support](https://krosoft.atlassian.net/servicedesk/customer/portals) for availability on your installation. Follow [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md) for scope, prerequisites and completion checks. The operation does not change Jira fields or approvals.
## Hours rollup issue view
Advanced edition administrators can use **Settings -\> Advanced settings -\> Hours rollup issue view** to:
* Enable or disable the work item view rollup panel globally
* Restrict the panel to specific Jira projects with the project allowlist
* Optionally select a Tempo work attribute, such as `Project code`, to show a grouped breakdown for the same rolled-up issue scope
* Add manual label overrides only when Tempo returns static-list IDs that cannot be resolved from metadata, for example `d8421f91-c947-49da-9a0a-3190271a2106 = 100%`
When enabled and allowlisted, supported parent work item views show an **Hours rollup** panel with **Powered by Planning Sync** shown as secondary header text in the collapsed surface. Unsupported work item views stay hidden.
The top row is always **Total logged** . Parent work items show generation rows such as **Children** , **Grandchildren** , and **Nested grandchildren** , including linked descendants from other Jira projects. Sub-tasks are not shown as separate items except at the lowest non-subtask level, where a **Subtasks** row can appear. If an attribute breakdown is enabled, the panel also shows grouped worklog totals such as project-code totals.
Users do not need the Planning Sync administrator permission to load this issue details panel. They must be able to view the Jira issue, the site must have Advanced edition access, and the issue project must be allowed by the Hours rollup project allowlist.
When Work attribute sync is enabled, the panel also starts a best-effort refresh of configured Work attribute sync fields under the same issue visibility, Advanced edition, and Hours rollup project gates.
When the feature is disabled, or when the current project is not allowlisted, the work item view panel stays visible but explains why rollup data is unavailable.
## Audit logs and Compliancy cases
Advanced edition administrators can review recent actions and webhook activity.
* Admin page: full operational audit log
* Admin page: dedicated Compliancy tab for auditable action cases
* Compliancy cases support free-text search, case-type filtering, acknowledgement filtering, and loading older matching cases with the last applied filters
* Project tab: project-scoped Planning Log for Planning Sync actions
Compliancy cases cover destructive actions, archived items with cached direct and descendant booked hours, frozen-period governance, and tracked field mapping changes.
## Planning Sync Time Machine Rovo Agent
Advanced edition administrators can use **Planning Sync Time Machine** from Rovo chat/sidebar to ask natural-language questions about retained Planning Sync history, such as:
* What happened to TEST-123 last week?
* Show risky compliancy cases in project TEST this month.
* Why did Planning Sync skip updates recently?
* Summarize deleted worklog or issue evidence for TEST-123.
Time Machine is read-only. It searches Planning Sync's retained operational audit entries and Advanced Compliancy cases only. It does not search native Jira changelogs, native Tempo history, Slack, email, or external APIs. Results keep **Operational audit** and **Compliancy case** source labels visible so you can tell runtime telemetry apart from governance findings.
Access and limits:
* You need Planning Sync administration access through the app global permission or Jira admin rights.
* The site needs Advanced edition access, except Forge development environments used for testing.
* An administrator must enable **Settings -\> Advanced settings -\> Compliance settings -\> Enable Planning Sync Time Machine** before the agent can query retained history.
* The action returns compact summaries only, defaults to 10 results, and caps output at 25 entries.
* Raw request bodies, raw webhook payloads, and oversized body fields are intentionally not exposed to Rovo.
## Reporting and Client Work Rate
Advanced edition administrators can use **Reporting** in the Planning Sync admin navigation to configure and verify manager-facing reports. Client Work Rate is the first report available there, and managers can use the separate **Client Work Rate Reporter** Rovo Agent after it is enabled.
By default, only Planning Sync administrators can use the CWR Rovo Agent. Administrators can configure one Jira group whose members may read saved CWR snapshots through Rovo without opening Planning Sync admin pages. Group-only users cannot generate or refresh snapshots.
Client Work Rate is calculated as:
`CWR = Productive hours / Available hours`
Definitions:
* Productive hours are all hours related to client work.
* Available hours are scheduled working hours minus leave, non-working holidays, and configured Account-exclusion worklogs.
* Client work is selected by one source: live Tempo Account Categories or live Tempo Accounts.
* Account exclusions reduce Available hours without being reported as Leave, Productive, or non-productive time.
* Leave can come from selected Leave Accounts, Jira Leave JQL matching, issue-field leave, and Tempo holiday schemes.
In payloads, scheduled working hours before reductions map to `grossAvailableHours`, leave plus non-working holiday reductions map to `leaveHours`, and final availability maps to `availableHours`. Report rows can also include `grossAvailableFte`, `leaveFte`, and `availableFte`.
In **CWR setup**, administrators can:
* Enable or disable Client Work Rate reporting
* Set the report name shown in dashboard summaries and Rovo responses
* Configure a CWR Rovo access group from live Jira group lookup or an exact group name
* Choose Tempo teams to include from a live Tempo Teams multi-select
* Add team-specific Rovo Team Name overrides
* Exclude selected live Tempo team members from calculations without changing Tempo membership
* Choose whether client work is selected by Account Categories or specific Accounts
* Choose Account exclusions for Available hours
* Choose Leave Accounts and Jira Leave JQL rules for Vacation, Sick Leave, and Other Leave
* Enable Tempo team commitment weighting when split-role users should have Available and Leave hours reduced by team commitment
* Choose an Automatic snapshots cadence
In **Monthly report**, administrators can:
* Choose a month and year without expanding setup
* Load a saved report when a snapshot exists
* Generate or refresh a report for the selected period
* Review Snapshot and Rovo status
* Watch queued or running refresh progress with current step, progress bar, and estimated remaining time
* Review formula breakdown, executive exceptions, warning lists, row-level details, and retained source evidence
Below-target exception severity is gradual. With the default target of 75%, CWR below 50% is critical, CWR from 50% to below 75% is warning, and CWR at 75% or higher has no below-target exception. In **Settings -\> Advanced settings -\> CWR severity thresholds**, administrators can turn on custom thresholds.
Use **Client Work Rate Reporter** from Rovo chat/sidebar for prompts such as:
* Generate CWR for May 2026.
* Show people below target for May 2026.
* Generate CWR for Communardo Netherlands for May 2026.
* Explain why Alex's CWR is low.
The month-scoped starter prompts shown by Rovo are generated during app deployment, not at chat runtime. They point at the previous UTC calendar month in `Month YYYY` format, so a June 2026 deployment shows `May 2026`. You can still type a different month when you need another saved CWR snapshot.
Rovo uses saved backend snapshots by default and must not invent CWR calculations. If no saved snapshot exists, ask a Planning Sync administrator to generate or refresh the saved monthly snapshot for the configured Teams to include scope.
## Audit ingress receipts
Advanced edition administrators can configure Planning Sync to receive signed callbacks after an external system successfully submits a Jira worklog.
Setup steps:
1. In **Settings -\> Advanced settings -\> Audit ingress webhook** , select **Get audit webhook config** to generate or fetch the dedicated URL and setup metadata.
2. Rotate the audit ingress shared secret before setup.
3. Configure each sender to sign the raw JSON body with HMAC-SHA256.
4. Send the hex signature in the `x-planning-sync-audit-signature` header.
5. Use the dedicated audit ingress webhook URL only for audit ingress senders. Do not use the Tempo webhook URL.
Planning Sync accepts only `schema_version: planning-sync.audit_event.v1` and `event_type: worklog.submitted`.
Accepted requests return `receipt_id`, `event_id`, `accepted: true`, and `duplicate`. Duplicate `event_id` deliveries return the same receipt with `duplicate: true`.
A missing or mismatched HMAC signature returns HTTP 403. Payload/schema validation failures return HTTP 400 with the validation error in the response body. Planning Sync stores only sanitized Jira/worklog claim metadata and rejects payloads containing raw browser, email, calendar, or evidence fields.
## Daily usage
After setup, normal usage looks like this:
* Tempo plans are created or updated.
* The app updates Jira fields based on your mappings.
* When an allowed Hours rollup issue view is opened by a Jira user who can view the issue, mapped work attribute aggregates refresh into Jira custom fields for export.
* Selected Tempo plan events are forwarded to Jira Automation when Automation webhook forwarding is enabled, even if built-in Tempo plan handling is disabled for that event.
* Tempo worklog events are processed when the related listeners and features are enabled.
* The audit log records changes and skips.
* Planning Sync Time Machine can summarize retained audit and Compliancy records for administrators from Rovo when Advanced access is available.
* Client Work Rate Reporter can answer from saved CWR snapshots when reporting is enabled and access rules allow it.
## Troubleshooting tips
### No updates in Jira
* Confirm the Planning Sync webhook URL resolves and app subscriptions were created successfully.
* Ensure the relevant listener is enabled.
* Check global scope allowlist settings.
* Check audit log entries for errors or skips.
### Audit log is empty
* Confirm the site has Advanced edition access.
* Generate new events after enabling the feature.
### Time Machine cannot find an event
* Confirm **Enable Planning Sync Time Machine** is on in Advanced settings.
* Confirm the event exists in retained Planning Sync audit or Compliancy history.
* Narrow the question with an issue key, project key, date range, or source type.
* Remember that Time Machine does not crawl native Jira or Tempo history outside Planning Sync storage.
### Client Work Rate Reporter cannot produce a report
* Confirm Client Work Rate is enabled in Reporting.
* Confirm the user has Planning Sync administration access or belongs to the configured CWR Rovo access group.
* Confirm a saved monthly snapshot exists for the requested month and configured team scope.
* Ask a Planning Sync administrator to generate or refresh the saved snapshot if needed.
### Webhook verification: check the integration direction
* **Tempo → Planning Sync:** check the current Planning Sync webhook URL, enabled Tempo listeners/subscriptions and the inbound verification settings for that connection. Do not substitute an outbound destination secret.
* **Planning Sync → external destination:** the optional destination secret adds an X-Signature header. The receiving system must verify it against the exact received body. Saving a secret in Planning Sync does not make Power Automate validate it automatically.
* **Audit ingress → Planning Sync:** check the audit-ingress configuration and compute its HMAC over the exact raw JSON body sent to Planning Sync.
* **Planning Sync → Jira Automation:** use the rule's current incoming-webhook URL and, where required, its token sent as X-Automation-Webhook-Token. This token is separate from destination signature secrets.
Never include full webhook URLs, tokens or secrets in customer-facing screenshots or support comments. Share sanitized request fields and error messages instead.
### Empty setup after reinstall
* Stop configuration changes until recovery expectations are confirmed.
* Copy the reinstall recovery support request from the first setup step or dashboard setup-readiness card.
* Send it to support within 21 days of uninstall so Atlassian can process it before the 28-day Forge-hosted storage retention ends.
## Where to find pages
* Planning Sync admin page: Jira app navigation -\> Planning Sync
* Project log: Jira project navigation -\> Planning Log
* Hours rollup issue view: Jira work item view -\> Hours rollup panel, when Advanced edition and project allowlist allow it
* Rovo Agents: Rovo chat/sidebar -\> Planning Sync Time Machine or Client Work Rate Reporter, when enabled and access rules allow it
## Access control
Planning Sync access is controlled through the Jira global permission **Administer Planning Sync for Jira (Tempo Integration)**.
* Jira administrators receive this permission by default on first install.
* Jira administrators can grant or revoke access for individual users or groups in Jira global permissions.
* Users without this permission, and who are not Jira admins or site admins, do not see the Planning Sync entry in the left navigation and cannot use admin/configuration screens.
* Advanced settings, outbound destinations, audit logs, Compliancy, Reporting setup, and Work attribute sync configuration require Planning Sync administration access and Advanced edition access, except in development environments used for testing.
* Planning Sync Time Machine follows the admin access gate plus Advanced edition gate.
* Client Work Rate Reporting setup requires Planning Sync administration access and Advanced edition access.
* Client Work Rate Reporter can allow one configured Jira group to read saved CWR snapshots without granting Planning Sync administration access or refresh rights.
* Work attribute sync configuration, compatible field lookup, Tempo metadata lookup, and manual sync require Planning Sync administration access.
* The Jira issue details **Hours rollup** panel and its best-effort Work attribute field refresh are separate from admin navigation. They can run for non-admin users who can view the issue when Advanced edition access and the configured project allowlist permit it.
## Diagnose outbound delivery
1. Confirm the correct destination is enabled, the expected events are selected, the matching Tempo listeners are active and the work item passes global scope.
2. Find the source plan's audit entries. **Queued plan event for ordered processing** means accepted for background processing; it does not mean Outlook changed.
3. Check subsequent destination delivery entries and skip reasons. **Completed ordered plan processing** can include an intentional skip; confirm successful delivery to the intended destination separately.
4. For pending/failed work, inspect connection errors, 429 throttling, mapping lookup errors or persistence errors. Resolve the cause and allow retries; do not bypass a failed parent event by replaying later changes.
5. Check the receiver's run history and final calendar state. A 202 or early 200 may acknowledge receipt before its actions finish. Match the full occurrence ID and daily dates.
6. If the audit requests controlled resync or IDs are unknown, contact support before cleaning up or replaying. Provide sanitized plan ID, event type, timestamp/time zone, destination label, audit result and receiver error. Preserve unrelated appointments.
Delivery order follows the order accepted by the app; it cannot reconstruct source changes received out of order. Do not manually replay an old create/update after its delete.
---
language: "en"
---
# Products
* [Planning Sync for Jira (Tempo Integration)](https://wiki.krosoft.nl/ekb/planning-sync.md)
* [Related Issues for Jira Cloud](https://wiki.krosoft.nl/ekb/related-issues-for-jira-cloud.md)
* [RSVP for Confluence Cloud](https://wiki.krosoft.nl/ekb/rsvp-for-confluence-cloud.md)
* [RSVP for Confluence Data Center](https://wiki.krosoft.nl/ekb/rsvp-for-confluence-data-center.md)
* [Legacy Assets Macro Converter for Confluence](https://wiki.krosoft.nl/ekb/insight-assets-macro-finder.md)
---
language: "en"
---
# Related Issues for Jira Cloud
## Related Issues for Jira Cloud
Surface related Jira issues directly in the issue view using configurable JQL logic.
Related Issues helps Jira admins and power users show the right connected work without forcing users to run manual searches or maintain issue links by hand.
*** ** * ** ***
### Who this is for
* Jira administrators who want project-specific related issue logic
* Support and operations teams that need faster context in the issue view
* Teams that use custom fields, organizations, components, or other metadata to define what counts as related
### What it does
* Displays related issues inline in the Jira issue view
* Uses configurable JQL templates per project
* Supports named templates for reuse across projects
* Allows admins to preview and refine related issue logic before rollout
* Keeps all app data within Jira Cloud
*** ** * ** ***
### Start here
* [User Manual](https://wiki.krosoft.nl/ekb/related-issues-for-jira-cloud-user-manual.md)
* [Release Notes](https://wiki.krosoft.nl/ekb/related-issues-for-jira-cloud-release-notes.md)
* Support: [support@krosoft.nl](mailto:support@krosoft.nl)
### Notes
This app is designed to stay lightweight and configurable. If no template is configured for a project, the related issues panel will not appear.
---
language: "en"
---
# Related Issues for Jira Cloud - End User License Agreement (EULA)
Effective Date: 2025-04-16
## 1. Acceptance of Terms
By installing, accessing, or using this Krosoft app for Jira Cloud ("the App"), you agree to comply with and be bound by these Terms of Use. If you do not agree to these terms, you may not use the App.
### 2. License
The App is licensed, not sold, to you by Krosoft for use strictly in accordance with these terms. Krosoft grants you a limited, non-exclusive, non-transferable, revocable license to use the App for your internal business purposes only within your authorized Jira Cloud instance.
### 3. Restrictions
You agree not to:
* Modify, decompile, reverse-engineer, disassemble, or attempt to derive the source code of the App.
* Use the App to infringe upon the intellectual property rights of others.
* Use the App for any unlawful or unauthorized purpose.
* Circumvent or disable any security features of the App or Atlassian's platform.
### 4. User Data and Privacy
The App processes and stores only the data necessary to fulfill its functionality (e.g., user-configured JQL templates and display of issue data via the Jira API). All data remains within your Jira Cloud environment and is handled according to Atlassian's security and privacy model. The App does not transmit any data externally or store personal information beyond what is already present in your Jira site. You are responsible for ensuring compliance with applicable data protection regulations.
### 5. Updates and Changes
Krosoft may release updates to improve functionality, enhance compatibility, or resolve issues. Such updates are governed by these Terms of Use. Krosoft reserves the right to modify, suspend, or discontinue the App or any part of it at any time without prior notice.
### 6. Termination
Krosoft may terminate your access to the App if you violate these Terms of Use. Upon termination, your license will be revoked, and you must cease all use of the App.
### 7. Limitation of Liability
To the fullest extent permitted by applicable law, Krosoft shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from or related to your use of the App, even if Krosoft has been advised of the possibility of such damages.
### 8. Governing Law
These Terms of Use shall be governed by and construed in accordance with the laws of The Netherlands. Any disputes arising out of or relating to the App shall be subject to the exclusive jurisdiction of the Dutch courts.
### 9. Contact
Questions or concerns about this agreement may be directed to: [support@krosoft.nl](mailto:support@krosoft.nl)
### 10. Changes to Terms
Krosoft reserves the right to revise these Terms of Use at any time. Continued use of the App after changes become effective constitutes your acceptance of the revised terms.
---
language: "en"
---
# Related Issues for Jira Cloud - Release Notes
[Related Issues Public Changelog](https://krosoft.releasedhub.com/products-public-changelod/changelog)
* [2025-05-19 - 1.0.12](https://wiki.krosoft.nl/ekb/2025-05-19-1-0-12.md)
Improved issue list UI with cleaner rendering and resolves several footer-related bugs.
* [2025-05-04 - 1.0.11](https://wiki.krosoft.nl/ekb/2025-05-04-1-0-11.md)
Improved onboarding and centralized configuration for a smoother setup experience.
* [2025-04-29 - 1.0.10](https://wiki.krosoft.nl/ekb/2025-04-28-1-0-10.md)
Improved app lifecycle stability and updated dependencies for enhanced reliability.
* [2025-04-28 - 1.0.9](https://wiki.krosoft.nl/ekb/2025-04-28-1-0-9.md)
JQL search endpoint deprecation, dark theme, code block editor, UI improvements.
---
language: "en"
---
# Related Issues for Jira Cloud - User Manual
## Introduction
Related Issues for Jira Cloud helps you surface related issues directly within the Jira issue view. Whether you're handling support tickets, tracking bugs, or managing recurring requests, this app gives you full control over what "related" means --- powered by JQL and configurable per project. This guide explains how to use the Related Issues app once it is installed on your Jira Cloud instance.
## Key Features
* Display related issues inline on the issue view
* Configure relevance logic per project using JQL templates
* Support any use case: from customer support to development workflows
* Use custom fields (like organization, product, etc.) to define relations
* Lightweight and intuitive UI, built for clarity
* Secure by design --- no data leaves your Jira site
## Getting Started
1. In Jira, go to **Apps → Manage your apps**.
2. Find **Related Issues for Jira Cloud** and open the configuration page.
3. Alternatively, open **Apps → Related Issues → Get started** in Jira.
4. Click **Configure Now** and select your target project.
5. The Project Configuration page will open with a JQL editor and a preview panel.
## Configuring a Project
* **JQL Template**: Write or paste the JQL that defines how issues are related. Use the documentation table to insert dynamic fields.
* **Named Templates** : Select a reusable template from the drop-down and press **Load** . Save changes with **Save**.
* **Preview** : Enter an issue key and click **Preview** to see example results.
## Example Configurations
Here are some sample JQL templates you can use:
project = XYZ AND "Customer" = {{issue.Customer}} AND issue {{ne issue.key}}
project = {{issue.project}} AND component = {{issue.component}} AND issue {{ne issue.key}}
reporter = {{issue.reporter}} AND statusCategory != Done AND issue {{ne issue.key}}
Each `{{issue.field}}` is replaced by the current issue's value. The `issue {{ne issue.key}}` clause ensures the current issue is excluded.
## Global Settings
Under **Apps → Related Issues → Global settings**, you can:
* View every project and see whether it uses a named template or custom JQL.
* Apply a named template to multiple projects in bulk.
* Manage all templates in the **Named templates** section.
## Issue View Panel
When browsing an issue, the Related Issues panel appears on the right side:
* Lists issues matching the JQL template for the project.
* Use the link icon next to an issue to create or remove an issue link.
* Click **Show more** at the bottom to open the full search in Jira.
* The gear icon opens the Project Configuration for quick edits.
## User Interaction
Once set up, users will see the Related Issues section directly on the issue page. Issues matching the template appear with key, summary, and status. Clicking an issue opens it in a new tab. The list updates dynamically if the issue is edited (for example, if the customer field changes). No extra permissions or actions are required --- it just works.
## Data Storage \& Security
* No external data storage; all data stays within your Jira Cloud instance.
* JQL templates are stored securely using Atlassian's storage APIs.
* The app requests only minimal read permissions for issue data.
* Fully compliant with Atlassian's cloud security standards.
## Admin Notes
* JQL Templates must be added manually for each project.
* Templates support all standard and custom fields.
* If no template is defined for a project, the Related Issues section will not appear.
* Templates can be updated anytime without reinstallation.
## Performance \& Compatibility
* Built to be lightweight and responsive; loads instantly on the issue view.
* Optimized for high usage across many projects.
* Compatible with all modern Jira Cloud project types (team-managed and company-managed).
## Support \& Help
If you get stuck, reopen **Apps → Related Issues → Get started** for a quick refresher. You can also contact support by email at [support@krosoft.nl](mailto:support@krosoft.nl), or visit our [Support Portal](https://krosoft.atlassian.net/servicedesk/customer/portal/1/group/-1). We'd love to hear your use case --- your feedback helps shape future versions.
---
language: "en"
---
# Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.2.0 - 2026-05-18
## Summary
This release makes worklog and webhook syncing more reliable, reducing the chance of missing or partial sync results. It also improves handling of Tempo worklog attributes so synced data is more accurate and consistent.
## New Features
No new features in this release.
## Improvements to existing features
* No improvements listed for this release.
## Bug fixes
* [PSJ-153](https://krosoft.atlassian.net/browse/PSJ-153) Forward Automation webhooks independently of plan handling toggles
* [PSJ-152](https://krosoft.atlassian.net/browse/PSJ-152) Avoid truncating webhook worklog aggregate sync to first 500 worklogs
* [PSJ-151](https://krosoft.atlassian.net/browse/PSJ-151) Bind issue-view sync to context issue key
* [PSJ-150](https://krosoft.atlassian.net/browse/PSJ-150) Include endDate fallback when parsing worklog dates
* [PSJ-149](https://krosoft.atlassian.net/browse/PSJ-149) Bound parallel worklog fetches per issue list
* [PSJ-148](https://krosoft.atlassian.net/browse/PSJ-148) Parse results envelopes in Tempo attribute payloads
* [PSJ-147](https://krosoft.atlassian.net/browse/PSJ-147) Handle structured Tempo attribute values before epic rollup grouping
* [PSJ-146](https://krosoft.atlassian.net/browse/PSJ-146) \[P2\] Validate malformed plan payloads before disabled-handler skip
* [PSJ-145](https://krosoft.atlassian.net/browse/PSJ-145) Avoid serial per-worklog attribute fetches in issue scans
* [PSJ-144](https://krosoft.atlassian.net/browse/PSJ-144) Ignore client-supplied issueId for issue-view worklog sync
* [PSJ-143](https://krosoft.atlassian.net/browse/PSJ-143) Fix automated PR review findings for fallback selectors and prepare hook
* [PSJ-141](https://krosoft.atlassian.net/browse/PSJ-141) \[P1\] Expose issue-view attribute sync to non-admin viewers
* [PSJ-140](https://krosoft.atlassian.net/browse/PSJ-140) Handle primitive static-list arrays in attribute matching
* [PSJ-139](https://krosoft.atlassian.net/browse/PSJ-139) Fall back to worklog ID when Tempo attributes.self is invalid
* [PSJ-138](https://krosoft.atlassian.net/browse/PSJ-138) Drop unpermitted Tempo EU endpoint from worklog fetch fallback list
* [PSJ-133](https://krosoft.atlassian.net/browse/PSJ-133) Propagate failed automation webhook config saves
* [PSJ-132](https://krosoft.atlassian.net/browse/PSJ-132) Bound Tempo worklog detail hydration fan-out
* [PSJ-131](https://krosoft.atlassian.net/browse/PSJ-131) Preserve dev override when product context omits environment type
* [PSJ-130](https://krosoft.atlassian.net/browse/PSJ-130) Accept values arrays when parsing Tempo worklog lists
* [PSJ-129](https://krosoft.atlassian.net/browse/PSJ-129) Parse values payloads from Tempo work-attributes responses
* [PSJ-128](https://krosoft.atlassian.net/browse/PSJ-128) Preserve raw static-list option tokens in metadata normalization
* [PSJ-127](https://krosoft.atlassian.net/browse/PSJ-127) Match explicit null worklog attribute values distinctly
* [PSJ-126](https://krosoft.atlassian.net/browse/PSJ-126) Return empty Tempo worklog results instead of lookup errors
* [PSJ-125](https://krosoft.atlassian.net/browse/PSJ-125) Preserve script mappings when normalizing worklog config
* [PSJ-123](https://krosoft.atlassian.net/browse/PSJ-123) Continue Tempo worklog fallback when issue-id lookup returns no rows
* [PSJ-122](https://krosoft.atlassian.net/browse/PSJ-122) Gate issue-view worklog attribute sync behind config-access permissions
* [PSJ-121](https://krosoft.atlassian.net/browse/PSJ-121) Keep trying Tempo worklog query fallbacks after empty responses
* [PSJ-120](https://krosoft.atlassian.net/browse/PSJ-120) Preserve saved Automation webhook settings on refresh failures
* [PSJ-119](https://krosoft.atlassian.net/browse/PSJ-119) Preserve static-list UUID values in worklog attribute parsing
* [PSJ-118](https://krosoft.atlassian.net/browse/PSJ-118) Keep saved worklog attribute mappings when option metadata fetch fails
---
language: "en"
---
# Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.3.0 - 2026-05-20
## Summary
* Worklog attribute synchronization is now more complete and reliable, helping teams keep planning data aligned.
* Advanced settings are easier to read and understand, making configuration simpler for administrators.
* Setup recovery after reinstall has been improved to help customers restore configuration more smoothly.
* New documentation is available for the PowerAutomate Outlook integration template.
* Support has been expanded for additional custom fields, with clearer warnings when Tempo is temporarily unavailable.
This release also includes stability improvements and bug fixes for a smoother experience.
## New Features
* [PSJ-117](https://krosoft.atlassian.net/browse/PSJ-117) Complete worklog attribute field sync
* [PSJ-72](https://krosoft.atlassian.net/browse/PSJ-72) Document PowerAutomate template for Outlook integration
* [PSJ-30](https://krosoft.atlassian.net/browse/PSJ-30) Add reinstall recovery workflow for Forge-hosted setup data
* [PSJ-5](https://krosoft.atlassian.net/browse/PSJ-5) Support of other custom fields
* [PSJ-3](https://krosoft.atlassian.net/browse/PSJ-3) Show warning when Tempo is not reachable or down
## Improvements to existing features
* [PSJ-113](https://krosoft.atlassian.net/browse/PSJ-113) Make Advanced settings easier to scan and understand
## Bug fixes
* [PSJ-156](https://krosoft.atlassian.net/browse/PSJ-156) Keep getReinstallRecoveryInfo side-effect free
* [PSJ-155](https://krosoft.atlassian.net/browse/PSJ-155) Honor Worklog attribute sync disable toggle in all sync entrypoints
---
language: "en"
---
# Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.3.0 - 2026-05-23
## Summary
This release strengthens the Auditor Rovo agent reliability and license handling by addressing several high-priority bug fixes around query behavior, caching, and supported Forge License API usage. It also includes attribute mapping UX refinements and exploratory work for future integrations and agent capabilities.
## New Features
* [PSJ-88](https://krosoft.atlassian.net/browse/PSJ-88) Improve attribute mapping UX and terminology
* [PSJ-8](https://krosoft.atlassian.net/browse/PSJ-8) Auditor Rovo Agent
* [PSJ-6](https://krosoft.atlassian.net/browse/PSJ-6) Research Slack integration
## Improvements to existing features
* [PSJ-171](https://krosoft.atlassian.net/browse/PSJ-171) Auditor agent under-reports compliancy source counts when limited
* [PSJ-170](https://krosoft.atlassian.net/browse/PSJ-170) Query the supported Forge License API endpoint
* [PSJ-169](https://krosoft.atlassian.net/browse/PSJ-169) Increase backoff for unverified Time Machine license checks
* [PSJ-168](https://krosoft.atlassian.net/browse/PSJ-168) Read Time Machine action invoker accountId from context.principal
* [PSJ-167](https://krosoft.atlassian.net/browse/PSJ-167) Fail closed when custom permission ARI lookup cannot read app context
* [PSJ-166](https://krosoft.atlassian.net/browse/PSJ-166) Use supported Forge License API endpoint
* [PSJ-164](https://krosoft.atlassian.net/browse/PSJ-164) Match Auditor agent issue keys as exact tokens
* [PSJ-162](https://krosoft.atlassian.net/browse/PSJ-162) Preserve app license fields when Rovo context is partial
* [PSJ-161](https://krosoft.atlassian.net/browse/PSJ-161) Cache unverified Auditor agent license results during throttling
* [PSJ-160](https://krosoft.atlassian.net/browse/PSJ-160) Preserve Auditor agent free-text filtering when issue key is provided
* [PSJ-159](https://krosoft.atlassian.net/browse/PSJ-159) Scope Auditor agent license cache by installation context
* [PSJ-158](https://krosoft.atlassian.net/browse/PSJ-158) Preserve Auditor agent query semantics when truncating long input
## Bug fixes
* [PSJ-171](https://krosoft.atlassian.net/browse/PSJ-171) Time Machine under-reports compliancy source counts when limited
* [PSJ-170](https://krosoft.atlassian.net/browse/PSJ-170) Query the supported Forge License API endpoint
* [PSJ-169](https://krosoft.atlassian.net/browse/PSJ-169) Increase backoff for unverified Auditor agent license checks
* [PSJ-168](https://krosoft.atlassian.net/browse/PSJ-168) Read Auditor agent action invoker accountId from context.principal
* [PSJ-167](https://krosoft.atlassian.net/browse/PSJ-167) Fail closed when custom permission ARI lookup cannot read app context
* [PSJ-166](https://krosoft.atlassian.net/browse/PSJ-166) Use supported Forge License API endpoint
* [PSJ-164](https://krosoft.atlassian.net/browse/PSJ-164) Match Auditor agent issue keys as exact tokens
* [PSJ-162](https://krosoft.atlassian.net/browse/PSJ-162) Preserve app license fields when Rovo context is partial
* [PSJ-161](https://krosoft.atlassian.net/browse/PSJ-161) Cache unverified Auditor agent license results during throttling
* [PSJ-160](https://krosoft.atlassian.net/browse/PSJ-160) Preserve Auditor agent free-text filtering when issue key is provided
* [PSJ-159](https://krosoft.atlassian.net/browse/PSJ-159) Scope Auditor agent license cache by installation context
* [PSJ-158](https://krosoft.atlassian.net/browse/PSJ-158) Preserve Auditor agent query semantics when truncating long input
---
language: "en"
---
# Release Notes - Planning Sync for Jira (Tempo Integration) - planning-sync-6.4.0 - 2026-06-02
## Summary
This release introduces the new **Reporting tab**, focused on making Client Work Rate reporting easier to access, configure, and trust. It brings clearer report setup, improved Tempo-based availability and leave handling, better performance, and more reliable saved report results.
Customers can now work with more accurate Client Work Rate insights across teams, including support for holiday schedules, vacation and sick leave, team member exclusions, split-role availability, and clearer report status information. Several fixes also improve consistency, permissions, terminology, and reliability throughout the reporting experience.
Full details are available in the linked issues in this release.
## New Features
* **Reporting tab for Client Work Rate:** The release centers on the new Reporting tab, giving customers a dedicated place to work with Client Work Rate reporting and review saved report results.
* **More flexible report configuration:** Reports can now account for selected team member exclusions, account exclusions, split-role availability weighting, and configured access for the right Jira group.
* **Expanded leave and availability support:** Client Work Rate reporting now supports Tempo holiday schedules, Tempo Account-based leave matching, and separate vacation and sick leave handling.
## Improvements to existing features
* **Tempo integration:** Tempo worklogs, team memberships, holiday schedules, and account information are handled more consistently, helping reports reflect the correct team and availability data.
* **Leave and vacation handling:** Vacation and sick leave can be reported separately, capped to scheduled days where needed, and mapped more precisely for issue-level and Tempo-based reporting.
* **Performance:** Report refreshes and lookups have been optimized so Reporting tab results can be generated and retrieved more efficiently.
* **Access and permissions:** Reporting access can be aligned with a configured Jira group, helping customers make the feature available to the right users.
* **Documentation and terminology:** Public documentation and in-product wording have been refreshed to better match customer terminology, especially around Available hours and Client Work Rate reporting.
## Bug fixes
* **Reporting reliability:** Fixed issues that could affect saving report settings, loading saved configurations, report availability toggles, saved snapshots, drilldown rows, and refresh retry behavior.
* **Client Work Rate accuracy:** Corrected cases where available hours, leave, source rows, and below-target severity could be reported incorrectly.
* **Tempo data consistency:** Improved handling of larger Tempo worklog and team membership datasets so reports include the expected information before calculations are made.
* **Team and terminology consistency:** Fixed stale team names and improved explanations for account classification and fallback warnings.
* **Navigation polish:** Restored the missing Planning Sync Apps navigation icon.
Issues in this release
| **Issue** | **Summary** |
|-----------------------------------------------------------------------|---------------------------------------------------------------------------------|
| [PSJ-210](https://krosoft.atlassian.net/browse/PSJ-210?src=confmacro) | Prevent CWR threshold save before config loads |
| [PSJ-209](https://krosoft.atlassian.net/browse/PSJ-209?src=confmacro) | Prevent CWR report save before saved config loads |
| [PSJ-208](https://krosoft.atlassian.net/browse/PSJ-208?src=confmacro) | Skip terminal CWR refresh retries |
| [PSJ-207](https://krosoft.atlassian.net/browse/PSJ-207?src=confmacro) | Page Tempo team memberships before filtering CWR worklogs |
| [PSJ-206](https://krosoft.atlassian.net/browse/PSJ-206?src=confmacro) | Cap CWR issue-field leave to scheduled days |
| [PSJ-205](https://krosoft.atlassian.net/browse/PSJ-205?src=confmacro) | Write CWR drilldown rows before exposing saved snapshot |
| [PSJ-204](https://krosoft.atlassian.net/browse/PSJ-204?src=confmacro) | CWR Reporter starter month should default to previous month |
| [PSJ-203](https://krosoft.atlassian.net/browse/PSJ-203?src=confmacro) | CWR Reporter starters should use configured Rovo team name |
| [PSJ-202](https://krosoft.atlassian.net/browse/PSJ-202?src=confmacro) | Configure vacation and sick leave issue-level mappings separately |
| [PSJ-201](https://krosoft.atlassian.net/browse/PSJ-201?src=confmacro) | Do not cap Tempo worklog fetches before CWR calculation |
| [PSJ-199](https://krosoft.atlassian.net/browse/PSJ-199?src=confmacro) | CWR report availability toggle does not persist disabled state |
| [PSJ-198](https://krosoft.atlassian.net/browse/PSJ-198?src=confmacro) | Create intended CWR report lookup indexes |
| [PSJ-197](https://krosoft.atlassian.net/browse/PSJ-197?src=confmacro) | Preserve CWR availability rows before source-row cap |
| [PSJ-195](https://krosoft.atlassian.net/browse/PSJ-195?src=confmacro) | Add CWR Account exclusions that reduce Available hours without leave |
| [PSJ-194](https://krosoft.atlassian.net/browse/PSJ-194?src=confmacro) | Allow CWR Reporter Rovo access for a configured Jira group |
| [PSJ-193](https://krosoft.atlassian.net/browse/PSJ-193?src=confmacro) | Refresh public Planning Sync documentation for 6.4.0 capabilities |
| [PSJ-192](https://krosoft.atlassian.net/browse/PSJ-192?src=confmacro) | Fix stale Client Work Rate team names in Rovo reports |
| [PSJ-188](https://krosoft.atlassian.net/browse/PSJ-188?src=confmacro) | Align CWR manager terminology for Available hours |
| [PSJ-187](https://krosoft.atlassian.net/browse/PSJ-187?src=confmacro) | Separate vacation and sick leave in CWR leave reporting |
| [PSJ-186](https://krosoft.atlassian.net/browse/PSJ-186?src=confmacro) | Support Tempo holiday schemas in CWR available hours |
| [PSJ-185](https://krosoft.atlassian.net/browse/PSJ-185?src=confmacro) | Link Jira issues in CWR Account fallback warnings |
| [PSJ-184](https://krosoft.atlassian.net/browse/PSJ-184?src=confmacro) | Support CWR availability weighting for split-role FTE users |
| [PSJ-183](https://krosoft.atlassian.net/browse/PSJ-183?src=confmacro) | CWR Rovo response labels every below-target person as critical severity |
| [PSJ-182](https://krosoft.atlassian.net/browse/PSJ-182?src=confmacro) | Allow CWR leave to be matched by Tempo Accounts |
| [PSJ-181](https://krosoft.atlassian.net/browse/PSJ-181?src=confmacro) | CWR Rovo explains Account Category classification as specific Account selection |
| [PSJ-180](https://krosoft.atlassian.net/browse/PSJ-180?src=confmacro) | Allow CWR reports to exclude selected team members |
| [PSJ-179](https://krosoft.atlassian.net/browse/PSJ-179?src=confmacro) | Clarify CWR report generation state with snapshot metadata |
| [PSJ-177](https://krosoft.atlassian.net/browse/PSJ-177?src=confmacro) | Optimize CWR report refresh performance |
| [PSJ-176](https://krosoft.atlassian.net/browse/PSJ-176?src=confmacro) | Update CWR wording to match customer terminology |
| [PSJ-175](https://krosoft.atlassian.net/browse/PSJ-175?src=confmacro) | Support Tempo worklog based leave adjustments for CWR POC |
| [PSJ-173](https://krosoft.atlassian.net/browse/PSJ-173?src=confmacro) | Planning Sync Apps navigation entry is missing its app icon |
| [PSJ-157](https://krosoft.atlassian.net/browse/PSJ-157?src=confmacro) | Complete FEATURES.md shipped capability inventory |
---
language: "en"
---
# Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.0 - 2025-04-13
## Summary
**rsvp-cl-1.1.0** was released on 2025-04-13. This update focuses on RSVP app UI stability and cleanup, including improved iframe resizing, macro width handling, AUI-style dropdown actions, footer icon fallback behavior, on-demand inline dialog handling, and better user login/admin override detection.
* **Cleanup and refactoring:** `rsvp.js`, CSS, and `rsvp.php` were reorganized and simplified to remove legacy layout issues, improve dropdown/dialog layering, and pass macro configuration to JavaScript more cleanly.
* **Issue coverage:** 2 new features, 1 improvement, and 4 bug fixes are included in this release.
## New Features
| **Issue** | **Summary** | **Issue Type** | **Components** |
|-------------------------------------------------------------------------|-------------------------------------------------------------------|----------------|-------------------------|
| [RSVPCL-9](https://krosoft.atlassian.net/browse/RSVPCL-9?src=confmacro) | Setup development environment | Story | Testing, Tooling |
| [RSVPCL-3](https://krosoft.atlassian.net/browse/RSVPCL-3?src=confmacro) | As a user of RSVP cloud I want to be able to edit my registration | Story | Testing, User Interface |
## Improvements to existing features
| **Issue** | **Summary** | **Issue Type** | **Components** |
|---------------------------------------------------------------------------|-------------------------|----------------|----------------|
| [RSVPCL-10](https://krosoft.atlassian.net/browse/RSVPCL-10?src=confmacro) | Update macro UI to AUI9 | Story | User Interface |
## Bug fixes
| **Issue** | **Summary** | **Issue Type** | **Components** |
|---------------------------------------------------------------------------|--------------------------------------------------------------|----------------|----------------|
| [RSVPCL-12](https://krosoft.atlassian.net/browse/RSVPCL-12?src=confmacro) | Submitting new RSVP generates two new entries instead of one | Bug | User Interface |
| [RSVPCL-11](https://krosoft.atlassian.net/browse/RSVPCL-11?src=confmacro) | RSVP Name misses email hyperlink | Bug | User Interface |
| [RSVPCL-8](https://krosoft.atlassian.net/browse/RSVPCL-8?src=confmacro) | Attend button nonresponsive | Bug | User Interface |
| [RSVPCL-7](https://krosoft.atlassian.net/browse/RSVPCL-7?src=confmacro) | Macro block layout is broken | Bug | User Interface |
---
language: "en"
---
# Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.1 - 2025-04-14
## Bug fixes
* [RSVPCL-13](https://krosoft.atlassian.net/browse/RSVPCL-13) iFrame resizing when dialog opens no longer working after sanitizing.
---
language: "en"
---
# Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.5 - 2025-05-14
## Summary
This release focuses on improving the user experience and security posture by adding dark mode compatibility, enforcing RSVP ownership via Account ID, improving Server/Data Center import compatibility in the migration console, and addressing a high-priority jQuery XSS advisory.
## New Features
* [RSVPCL-20](https://krosoft.atlassian.net/browse/RSVPCL-20) Make the app dark mode compatible.
* [RSVPCL-15](https://krosoft.atlassian.net/browse/RSVPCL-15) Enforce RSVP Ownership via Account ID.
## Improvements to existing features
* [RSVPCL-28](https://krosoft.atlassian.net/browse/RSVPCL-28) Make the migration console compatible with Server/DC imports.
## Bug fixes
* [RSVPCL-27](https://krosoft.atlassian.net/browse/RSVPCL-27) jquery Cross-site Scripting (XSS) advisory.
---
language: "en"
---
# Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.6 - 2026-05-24
## Summary
This release focuses on improving the RSVP Cloud experience, hardening security, and strengthening Data Center to Cloud migration support. It includes one new feature, several usability and migration improvements, and multiple bug fixes across authentication, UI alignment, legacy macro compatibility, and dependency security.
## New Features
* [RSVPCL-43](https://krosoft.atlassian.net/browse/RSVPCL-43) Add compact attendee card display mode.
## Improvements to existing features
* [RSVPCL-44](https://krosoft.atlassian.net/browse/RSVPCL-44) Remove empty comment placeholder from attendee list.
* [RSVPCL-42](https://krosoft.atlassian.net/browse/RSVPCL-42) Add close control to RSVP update flags.
* [RSVPCL-41](https://krosoft.atlassian.net/browse/RSVPCL-41) Hide macro from migration console while loading.
* [RSVPCL-39](https://krosoft.atlassian.net/browse/RSVPCL-39) Hide email attendee option when feature flag is disabled.
* [RSVPCL-34](https://krosoft.atlassian.net/browse/RSVPCL-34) Refine DC mapping auto-accept behavior.
* [RSVPCL-32](https://krosoft.atlassian.net/browse/RSVPCL-32) Automate Connect-to-Forge RSVP import for same-key migration test.
## Bug fixes
* [RSVPCL-48](https://krosoft.atlassian.net/browse/RSVPCL-48) Strip context path before computing Connect QSH.
* [RSVPCL-47](https://krosoft.atlassian.net/browse/RSVPCL-47) Keep console bundle sourcemaps in sync after post-processing.
* [RSVPCL-46](https://krosoft.atlassian.net/browse/RSVPCL-46) Stop using request environmentType in edit authorization.
* [RSVPCL-40](https://krosoft.atlassian.net/browse/RSVPCL-40) Fix attendee name alignment in RSVP rows.
* [RSVPCL-36](https://krosoft.atlassian.net/browse/RSVPCL-36) Legacy DC rsvps macros without rsvpId do not load imported attendees.
* [RSVPCL-35](https://krosoft.atlassian.net/browse/RSVPCL-35) Support legacy DC RSVP macro key during DC to Cloud migrations.
* [RSVPCL-33](https://krosoft.atlassian.net/browse/RSVPCL-33) Scale Data Center review session creation for larger exports.
* [RSVPCL-30](https://krosoft.atlassian.net/browse/RSVPCL-30) Fix Snyk vulnerability in underscore via @atlassian/aui upgrade.
---
language: "en"
---
# Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.7 - 2026-05-30
## Summary
* Improved Forge macro configuration flows, including a cleaner settings modal, safer config saves, preserved resolver payloads, and more reliable macro identity validation.
* Added and refined custom RSVP capabilities, including custom questions, response statuses, respondents-only counts, correct question ordering, and CSV exports that respect answer visibility rules.
* Strengthened reliability and data safety with safer schema recovery cleanup and compatibility hardening for optional RSVP feature columns in Forge SQL.
* Hardened security-sensitive behavior by deriving capacity checks from trusted server-side configuration and tightening production variables before Marketplace submission.
* Completed key Marketplace migration work for the Forge successor release.
## New Features
* [RSVPCL-55](https://krosoft.atlassian.net/browse/RSVPCL-55) Add respondents-only response count display option.
* [RSVPCL-50](https://krosoft.atlassian.net/browse/RSVPCL-50) Add RSVP response statuses.
* [RSVPCL-49](https://krosoft.atlassian.net/browse/RSVPCL-49) Support custom RSVP questions.
* [RSVPCL-29](https://krosoft.atlassian.net/browse/RSVPCL-29) Execute Big Bang Connect to Forge Marketplace migration.
## Improvements to existing features
* [RSVPCL-62](https://krosoft.atlassian.net/browse/RSVPCL-62) Preserve macro configuration changes more reliably while saving settings.
* [RSVPCL-61](https://krosoft.atlassian.net/browse/RSVPCL-61) Improved the Forge macro settings dialog layout for a clearer editing experience.
* [RSVPCL-60](https://krosoft.atlassian.net/browse/RSVPCL-60) Moved custom question settings into a dedicated flow to simplify the main macro settings experience.
* [RSVPCL-54](https://krosoft.atlassian.net/browse/RSVPCL-54) Improved Forge SQL compatibility for optional RSVP feature columns.
* [RSVPCL-38](https://krosoft.atlassian.net/browse/RSVPCL-38) Strengthened production configuration for the Marketplace successor submission.
## Bug fixes
* [RSVPCL-67](https://krosoft.atlassian.net/browse/RSVPCL-67) Make answer cleanup safer during schema recovery.
* [RSVPCL-66](https://krosoft.atlassian.net/browse/RSVPCL-66) Improve macro identity validation when saving updates.
* [RSVPCL-65](https://krosoft.atlassian.net/browse/RSVPCL-65) Improve follow-up fixes for safer configuration changes.
* [RSVPCL-64](https://krosoft.atlassian.net/browse/RSVPCL-64) Avoid unnecessary question updates when saving regular configuration changes.
* [RSVPCL-63](https://krosoft.atlassian.net/browse/RSVPCL-63) Make macro configuration saves more reliable.
* [RSVPCL-59](https://krosoft.atlassian.net/browse/RSVPCL-59) Base capacity checks on trusted server-side configuration.
* [RSVPCL-58](https://krosoft.atlassian.net/browse/RSVPCL-58) Improve authorization checks and answer indicators for custom questions.
* [RSVPCL-57](https://krosoft.atlassian.net/browse/RSVPCL-57) Ensure CSV exports respect custom question answer visibility.
* [RSVPCL-56](https://krosoft.atlassian.net/browse/RSVPCL-56) Keep custom questions in the correct order after reordering.
---
language: "en"
---
# RSVP Data Center to Cloud Migration
This manual explains how a Confluence administrator exports RSVP data from **RSVP for Confluence Data Center** and imports it into **RSVP for Confluence Cloud**.
The migration is deliberately split into two parts: migrate or create the Cloud pages first, then import RSVP rows into the matching Cloud pages after reviewing page mappings.
*Last reviewed: 19 June 2026*
## Audience and scope
Use this guide if you administer a Confluence Server or Data Center site that uses RSVP for Confluence and you are moving RSVP history to Confluence Cloud.
This guide covers:
* Exporting RSVP data from the Data Center app.
* Uploading the export in the Cloud app migration console.
* Reviewing Data Center page to Cloud page mappings.
* Importing only accepted mappings.
* Verifying the migrated RSVP data.
This guide does not migrate Confluence page content. Move the pages to Cloud first, then use this guide to move RSVP data.
## What migrates
The Data Center export contains a deterministic JSON artifact with:
* RSVP rows, including display name, email address, comment, RSVP timestamp, legacy row ID, Data Center page ID, and RSVP ID.
* Page identity metadata, including Data Center page ID, space key, space name, title, and page URLs.
* Per-page and per-RSVP ID macro manifest summaries.
The Cloud import uses the artifact to create a mapping review session. RSVP rows are imported only for page mappings that an administrator accepts.
## What does not migrate automatically
* Confluence page content.
* Cloud page mappings without administrator review.
* Skipped or undecided pages.
* Notification history.
* Any cleanup after importing rows to the wrong Cloud page.
If any mapping is uncertain, skip it and resolve it before importing. Re-running an accepted import is designed to upsert the same source rows, but importing with the wrong mapping can still place RSVP data on the wrong Cloud page.
## Prerequisites
Before starting, confirm that:
* The Data Center app version includes the **RSVP Migration Console**.
* You are a Confluence administrator or system administrator on the Data Center site.
* RSVP for Confluence Cloud is installed on the target Cloud site.
* You are a Confluence administrator on the Cloud site.
* Target Cloud pages already exist for the Data Center pages you plan to migrate.
* You know whether this is a full migration or a smaller validation import.
* You have a secure place to store the export artifact. The file can contain personal data.
Recommended first pass: run a small validation export for one space or one page, import it into a test Cloud site or a small target set, and verify the result before running a full-site export.
## End-to-end workflow
1. Prepare the Cloud pages.
2. Export RSVP data from Data Center.
3. Open the RSVP Migration Console in Cloud.
4. Initialize Forge storage if it is not already initialized.
5. Upload the Data Center export and generate mapping suggestions.
6. Review and accept only the correct Cloud page mappings.
7. Import accepted mappings.
8. Verify RSVP data on the target Cloud pages.
## 1. Prepare Cloud pages
Migrate or create the Confluence Cloud pages before importing RSVP data. The importer maps each Data Center page to an existing Cloud page. It does not create Cloud pages.
For each migrated page, confirm that:
* The page exists in the target Cloud site.
* The page title and space make it easy to identify during mapping review.
* Any RSVP macro content that should remain visible has been migrated or recreated.
* The page can be opened by the administrators who will verify the import.
## 2. Export from Data Center
Open the Data Center migration console from either location:
* **Confluence administration** \> **Configuration** \> **RSVP Migration**
* Direct URL: `/plugins/servlet/rsvp-admin/migration`
The page is admin-only and generates the migration artifact from Data Center storage.
### Export options
Use no filters for a full migration export. Use filters only for validation, staged migration, or troubleshooting.
| Option | Use when |
|---------------------------|-------------------------------------------------------------|
| Space key | Export one Confluence space. |
| Single page ID | Export one Data Center page. |
| Multiple page IDs | Export a comma-separated list of Data Center pages. |
| Include pages metadata | Keep enabled for Cloud mapping review. |
| Include rows RSVP entries | Keep enabled for data import. |
| Compress export with gzip | Use for large exports, then decompress before Cloud upload. |
Do not combine **Single page ID** and **Multiple page IDs** . At least one of **Include pages metadata** or **Include rows RSVP entries** must remain enabled.
### Download now vs background export
Use **Download now** for small and medium exports.
Use **Queue background export** for full-site or large exports that may take longer. When the job completes, download it from the recent jobs list in the migration console.
### Important gzip note
The Cloud upload expects a JSON file. If the Data Center console downloads a `.json.gz` file, decompress it first and upload the resulting `.json` file in Cloud.
For a direct browser upload to Cloud, the simplest path is to clear **Compress export with gzip** before downloading the Data Center artifact.
### Optional REST export
Administrators can also export through the REST endpoint:
GET /rest/rsvp/1.0/migration/export
GET /rest/rsvp/1.0/migration/export?spaceKey=ABC
GET /rest/rsvp/1.0/migration/export?pageId=123456
GET /rest/rsvp/1.0/migration/export?pageIds=123,456,789
The export schema version starts at `dc-rsvp-export-v1`.
## 3. Open the Cloud migration console
In Confluence Cloud, open **RSVP Migration Console** from the app configuration or Confluence global settings. The Cloud app exposes the console as an admin settings page.
Only Confluence administrators can open the migration console.
Select **Server / Data Center -\> Cloud** before uploading a Data Center export.
## 4. Initialize storage
In the Cloud migration console, run **Initialize schema** if the console says Forge SQL is not initialized for the site.
If the console already shows the schema as initialized, continue to the upload step.
## 5. Upload export and generate mappings
In the **Upload export and generate mappings** step:
1. Choose the Data Center `.json` export file.
2. Confirm the summary: file name, page count, macro count, and RSVP row count.
3. Select **Generate mapping suggestions**.
Generating mappings creates a review session. No RSVP rows are imported at this step.
## 6. Review page mappings
Use **Review page mappings** to decide which Data Center pages should import into which Cloud pages.
For each row, review:
* Data Center page title.
* Data Center page ID.
* Data Center space key.
* RSVP row count.
* Suggested Cloud pages.
Actions available during review:
| Action | Result |
|---------------------------------|---------------------------------------------------------------------------|
| Accept | Uses the suggested Cloud page for this Data Center page. |
| Auto-accept exact title matches | Accepts only mappings with one saved suggestion and an exact title match. |
| Search Cloud pages | Searches manually when no suggestion or multiple suggestions are shown. |
| Select | Uses a manually searched Cloud page. |
| Skip | Leaves this Data Center page out of the import run. |
Only accept mappings you can verify. Skipped and undecided pages are not imported.
## 7. Import accepted mappings
After accepting the mappings you want to import, select **Import accepted mappings**.
The importer writes RSVP rows only for accepted mappings. It leaves skipped and undecided pages out of the run.
After the import completes, note the imported row count and imported page count shown by the console.
## 8. Verify in Cloud
Verify a sample of imported pages before considering the migration complete.
Recommended checks:
* Open each high-value Cloud page with an RSVP macro.
* Confirm attendee names, comments, and counts match the Data Center source.
* Confirm separate RSVP macros on the same page show the expected attendees.
* Export or view attendee data from the Cloud macro if needed for comparison.
* Confirm new RSVP submissions still work on the imported Cloud pages.
* Confirm ordinary Cloud app behavior such as Notify, attendee actions, and settings still works.
For full migrations, validate at least:
* One page from each migrated space.
* One page with multiple RSVP macros.
* One page with comments.
* One page with a larger attendee list.
* One recently updated RSVP.
## Troubleshooting
| Symptom | What to check |
|-------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|
| Data Center console is unavailable | Confirm the installed Data Center app version includes the RSVP Migration Console and that you are a Confluence administrator. |
| Export returns forbidden | Use a Confluence administrator or system administrator account. |
| Export returns bad request | Check that `pageId` and `pageIds` are not combined, page IDs are numeric, and at least one include option is enabled. |
| Cloud upload fails for `.json.gz` | Decompress the file and upload the `.json` artifact. |
| Cloud upload says no rows | Confirm the export scope contains RSVP rows and **Include rows RSVP entries** was enabled. |
| No Cloud mapping suggestion appears | Search manually by Cloud page title, or confirm the target page exists in Cloud. |
| Multiple Cloud suggestions appear | Accept only after opening or identifying the correct Cloud page. |
| Wrong mapping was accepted but not imported yet | Skip or change the mapping before import. |
| Wrong mapping was imported | Stop, record the Data Center page ID and Cloud page ID, and contact support before running more imports for that page. |
| Import button is disabled | Accept at least one page mapping and confirm the review session is still loaded. |
## Screenshot placeholders
Add screenshots at these locations before publishing externally. Until screenshots are attached, the capture locations below identify exactly what should be shown.
| Manual section | Screenshot to add | Capture location |
|-------------------------------------|----------------------------------------------------------------------------------------------|------------------------------------------------------------------------|
| Export from Data Center | Data Center RSVP Migration Console with scope and content options visible. | `/plugins/servlet/rsvp-admin/migration` |
| Export from Data Center | Background export job list with a completed downloadable job. | Same Data Center migration console after queueing an export. |
| Open the Cloud migration console | Cloud RSVP Migration Console mode selector with **Server / Data Center -\> Cloud** selected. | Confluence Cloud global settings \> **RSVP Migration Console** |
| Upload export and generate mappings | Upload field and file summary after choosing a Data Center JSON artifact. | Cloud migration console, **Upload export and generate mappings** step. |
| Review page mappings | Mapping review table with suggested Cloud pages, Accept, Search, Select, and Skip controls. | Cloud migration console, **Review page mappings** step. |
| Import accepted mappings | Completed import success message with imported row and page counts. | Cloud migration console, **Import accepted mappings** step. |
| Verify in Cloud | RSVP macro attendee list after import. | Target Cloud page containing the RSVP macro. |
Existing product screenshots that can help with non-migration verification are available in the Cloud repo at `docs/user-manual/screenshots/`. Existing Data Center product screenshots are available in the Data Center repo at `src/main/resources/images/highlights/`. Migration console screenshots still need to be captured from a running Data Center and Cloud environment.
## Data handling
Treat the export artifact as sensitive. It can contain names, email addresses, RSVP comments, timestamps, and page references.
Recommended handling:
* Store the export in a restricted location.
* Avoid sending the artifact through email or chat unless your organization permits it.
* Delete temporary local copies after validation and support handoff are complete.
* Keep a record of the export scope, timestamp, and administrator who performed the migration.
## Support handoff checklist
When asking Krosoft Support for help, include:
* Source Confluence version and Data Center app version.
* Target Cloud site URL.
* Export scope used: full site, space key, single page ID, or multiple page IDs.
* Whether gzip was used.
* Any Cloud mapping that looked ambiguous.
* Data Center page IDs and Cloud page URLs for problem pages.
* Screenshot of the Cloud migration console error or import result.
---
language: "en"
---
# RSVP for Confluence Cloud
Add lightweight RSVP and attendance tracking directly to Confluence pages.
RSVP for Confluence Cloud helps teams coordinate meetings, events, and sign-ups inside Confluence without introducing external tools or manual tracking.
*** ** * ** ***
## Who this is for
* Confluence administrators using Confluence Cloud
* Teams that coordinate events, attendance, or sign-ups on Confluence pages
* Organizations that want a simple embedded RSVP experience for everyday team coordination
## What it does
* Adds an RSVP macro to Confluence pages
* Collects attendee responses, comments, and timestamps
* Lets users edit or cancel their own response
* Displays responses directly on the page
* Supports lightweight coordination without leaving Confluence
*** ** * ** ***
## Start here
* [User Manual](https://wiki.krosoft.nl/ekb/rsvp-for-confluence-cloud-user-manual.md)
* [Release Notes](https://wiki.krosoft.nl/ekb/rsvp-for-confluence-cloud-release-notes.md)
* Support: [support@krosoft.nl](mailto:support@krosoft.nl)
## Notes
Each page tracks its own RSVP data. A global cross-page overview is not available.
---
language: "en"
---
# RSVP for Confluence Cloud - End User License Agreement (EULA)
Effective Date: 2026-05-30
## 1. Acceptance of Terms
By installing, accessing, or using RSVP for Confluence Cloud (the "App"), you agree to be bound by these Terms of Use. If you do not agree to these Terms of Use, do not install, access, or use the App.
### 2. License
The App is licensed, not sold, by Krosoft. Subject to these Terms of Use, Krosoft grants you a limited, non-exclusive, non-transferable, revocable license to use the App for your internal business purposes within your authorized Confluence Cloud site and related Atlassian cloud environment.
### 3. Restrictions
You agree not to:
* modify, decompile, reverse-engineer, disassemble, or attempt to derive the source code of the App, except to the extent such restriction is prohibited by applicable law;
* use the App in a way that infringes the intellectual property rights or other rights of Krosoft, Atlassian, or any third party;
* use the App for any unlawful, abusive, or unauthorized purpose;
* interfere with, disrupt, or circumvent any security, access control, or usage limits of the App or the Atlassian platform;
* use the App in a way that could damage, disable, overburden, or impair the App or Atlassian services.
### 4. User Data and Privacy
The App processes and stores data needed to provide RSVP functionality in Confluence, including for example macro configuration, attendee names, attendee email addresses, comments, RSVP timestamps, page identifiers, and, where applicable, Confluence account identifiers and profile metadata.
The current version of the App runs on Atlassian Forge and stores operational data using Atlassian-hosted app infrastructure. During migration from the legacy version of the App, Krosoft may also process historical RSVP data in order to export, prepare, and import that data into the Forge-based version of the App when requested by or on behalf of the customer.
Krosoft will handle App data only as reasonably necessary to operate, support, secure, and migrate the App. You are responsible for ensuring that your use of the App complies with applicable privacy, employment, and data protection laws and your organization's internal policies.
### 5. Updates and Changes
Krosoft may release updates, patches, enhancements, or compatibility changes for the App from time to time. These updates are governed by these Terms of Use unless Krosoft states otherwise. Krosoft may modify, suspend, or discontinue the App or any feature of the App at any time.
### 6. Termination
Krosoft may suspend or terminate your right to use the App if you violate these Terms of Use. You may stop using the App at any time by uninstalling it from your Atlassian environment. Upon termination, the license granted under these Terms of Use ends immediately.
### 7. Limitation of Liability
To the fullest extent permitted by applicable law, Krosoft shall not be liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for any loss of profits, revenue, data, goodwill, or business interruption, arising out of or in connection with your use of or inability to use the App, even if Krosoft has been advised of the possibility of such damages.
### 8. Governing Law
These Terms of Use are governed by and construed in accordance with the laws of The Netherlands, without regard to conflict of law principles. Any dispute arising out of or relating to these Terms of Use or the App shall be subject to the exclusive jurisdiction of the competent courts in The Netherlands.
### 9. Contact
Questions about these Terms of Use may be directed to:
[support@krosoft.nl](mailto:support@krosoft.nl)
### 10. Changes to These Terms
Krosoft may revise these Terms of Use from time to time. Updated terms become effective when published or otherwise made available by Krosoft, unless stated otherwise. Your continued use of the App after updated terms become effective constitutes your acceptance of the revised Terms of Use.
### 11. Atlassian Platform Terms
Your use of Confluence Cloud and other Atlassian cloud products remains subject to your agreement with Atlassian. These Terms of Use apply only to the App and do not replace or modify Atlassian's own product terms.
---
language: "en"
---
# RSVP for Confluence Cloud - Release Notes
* [Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.7 - 2026-05-30](https://wiki.krosoft.nl/ekb/release-notes-rsvp-for-confluence-cloud-rsvp-cl-1-1-7-2026-05-30.md)
* [Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.6 - 2026-05-24](https://wiki.krosoft.nl/ekb/release-notes-rsvp-for-confluence-cloud-rsvp-cl-1-1-6-2026-05-24.md)
* [Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.5 - 2025-05-14](https://wiki.krosoft.nl/ekb/release-notes-rsvp-for-confluence-cloud-rsvp-cl-1-1-5-2025-05-14.md)
* [Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.1 - 2025-04-14](https://wiki.krosoft.nl/ekb/release-notes-rsvp-for-confluence-cloud-rsvp-cl-1-1-1-2025-04-14.md)
* [Release Notes - RSVP for Confluence Cloud - rsvp-cl-1.1.0 - 2025-04-13](https://wiki.krosoft.nl/ekb/release-notes-rsvp-for-confluence-cloud-rsvp-cl-1-1-0-2025-04-13.md)
---
language: "en"
---
# RSVP for Confluence Cloud - User manual
**RSVP for Confluence Cloud** adds an interactive RSVP macro to Confluence Cloud pages. Use it for meetings, events, training sessions, internal activities, and any page where people need to register attendance directly in Confluence.
Last reviewed: 2026-06-01
## Key features
* Add an RSVP macro to any Confluence Cloud page.
* Collect attendee name, email address, response status, comments, and RSVP timestamp.
* Support response statuses: **Attending** , **Declined** , and **Waitlisted**.
* Configure capacity limits, including blocking new attending responses or allowing a waitlist.
* Add custom RSVP questions with optional required answers.
* Show responses as standard cards or compact rows.
* Optionally enable response search and status filters.
* Let users edit or remove their own RSVP.
* Let organizers manage responses, export CSV data, check attendees in, use Rovo assistance, and notify selected respondent groups.
* Show a page-level RSVP byline summary in the Confluence title metadata row when a page contains RSVP macros.
## Getting started
1. Open the Confluence page where you want to collect RSVPs.
2. Click **Edit**.
3. Insert the **RSVP** macro from the macro browser, or type `/RSVP` and select the RSVP macro.
4. Publish the page.
The macro has useful defaults, so it can be inserted and published without opening settings first. To customize it, edit the macro and open **RSVP settings**.
RSVP macro overview with response counts, organizer header actions, response filters, and standard response cards.
## Page byline summary
When a Confluence page contains one or more RSVP macros, RSVP adds a compact byline item to the page title metadata row.
* The row shows a compact status such as RSVP: 12 attending, RSVP: 12 / 20 attending, or RSVPs: 2 events.
* Selecting the byline opens a small summary popup with response totals, capacity state, and event summaries.
* For privacy, the popup does not show attendee names, email addresses, comments, or custom question answers.
* After adding or removing the last RSVP macro, reload the page if the byline visibility has not refreshed yet.
Page title byline popup showing aggregate RSVP totals, capacity, and event summaries without attendee details.
## Configure the RSVP macro
Open the macro settings to configure the event and display behavior.
RSVP macro settings for event details, capacity, response counts, row badges, filters, and unique identifier.
### Basic settings
* **Title**: the heading shown above the RSVP macro.
* **Description**: optional supporting text shown below the title.
* **Content width** : the macro width, such as `400`, `600px`, `50%`, or another valid CSS width.
* **Content alignment**: left, center, or right.
* **Attendee display**: standard cards or compact rows.
* **Reply button value**: custom text for the primary response button.
* **Users must be logged in to reply**: controls whether the current Confluence identity is required for replies.
* **Unique identifier**: use only when one page needs multiple independent RSVP macros or when preserving a legacy RSVP identity.
RSVP macro using a narrower content width, showing how controls and response rows adapt in a constrained layout.
### Capacity and response display
* **Maximum attendees** sets the number of attending spots.
* **When maximum attendees is reached** controls whether new attending responses are blocked or added to a waitlist.
* **Response count display** can show a status breakdown or a simple respondent count.
* **Show declined count** and **Show waitlist count** control which status totals appear when using the status breakdown display.
* **Show row status badges** controls whether each response row shows its status.
* **Response filters** controls who can see the search and status filter controls:
* Hidden
* Show to attendees
* Show to signed-in Confluence users
* Show to organizers and admins
## Custom RSVP questions
Use the **Custom questions** tab in RSVP settings to ask for extra information when people respond.
Custom question settings with answer display, answer visibility, required questions, question types, and single-select options.
Supported question types:
* Short text
* Long text
* Single select
* Yes / no
Question behavior:
* Up to 5 custom questions are supported.
* Single-select questions can have up to 10 options.
* Questions can be required.
* Questions can include help text.
* Questions can be reordered or removed.
Answer display options:
* **Icon indicator** shows whether a response has answers without showing all values inline.
* **Inline answers** shows answers directly in the response list.
Answer visibility options:
* **Page viewers**: page viewers can see answers.
* **Managers only**: only organizers and admins can see answers in the macro view.
* **Export / edit only**: answers are hidden in the macro view but remain available when editing a response and in CSV export for authorized users.
Response list with custom question answers displayed inline below each attendee.
## Responding to an RSVP
When a viewer opens a page with an RSVP macro, they can select the response button and submit a response.
The RSVP form can include:
* Name
* Email address
* Status: Attending, Declined, or Waitlisted
* Comment
* Custom question answers, when configured
RSVP form with prefilled profile details, attendee status, comment field, and custom question answers.
For logged-in Confluence users, the form can prefill profile details. Required custom questions must be answered before the response can be saved.
If a maximum attendee limit is configured:
* Attending responses count toward capacity.
* Declined responses do not count toward capacity.
* Waitlisted responses are available only when the macro is configured to allow a waitlist.
## Managing your own RSVP
Users can update or remove their own RSVP from the response list.
Depending on the stored response identity, the action menu may show:
* **Edit my RSVP**
* **Remove my RSVP**
Editing lets the user update their name, email, status, comment, and custom question answers.
Normal attendee view after responding, with personal RSVP state visible and organizer-only Notify hidden.
## Organizer and admin actions
Page managers, page authors, and Confluence admins have organizer-level controls.
Organizers can:
* Edit another attendee's response.
* Remove another attendee's response.
* Mark attendees as checked in, or undo check-in.
* Export responses to CSV.
* Open **Ask Rovo** for RSVP summaries and drafting help.
* Open **Notify** to prepare and send respondent notifications.
Normal attendees can manage only their own RSVP.
## Viewing responses
Responses appear below the RSVP form.
Depending on macro settings, responses may appear as:
* Standard cards
* Compact rows
Compact attendee display showing response rows with status, check-in, and custom-question indicators.
The response list can show:
* Attendee name
* Email/contact details, when available
* Comment
* Status badge
* Check-in badge
* Custom question answer indicators or inline answers
If response filters are enabled, viewers can search responses by name or email and filter by status.
Response filters narrowing the list to a matching attendee and showing the filtered result count.
## Exporting responses
Organizers can select the export icon in the macro header to download a CSV file.
The CSV can include:
* Full name
* Email
* Comment
* RSVP timestamp
* Status
* Custom question answers
* Checked-in timestamp
* Checked-in-by account ID
* Attendee account ID
* Attendee profile URL
Export is disabled when the app license is inactive or when the macro is temporarily blocked by migration/import state.
## Ask Rovo
The **Ask Rovo** action opens the bundled **RSVP Organizer** agent with context from the RSVP macro.
Rovo can help organizers:
* Summarize the current RSVP event.
* Check capacity risk and remaining spots.
* Summarize attendee comments.
* Draft a general RSVP reminder.
* Draft attendee follow-up copy.
* Identify missing custom question answers.
Rovo is read-only. It does not create, update, remove, email, notify, or send anything.
If a Confluence page contains multiple RSVP macros, Rovo may ask which RSVP event to use. Choose the exact macro title, or open Ask Rovo from the specific RSVP macro header.
## Notify respondents
The **Notify** action is available only to page managers, page authors, and Confluence admins.
Notify lets organizers prepare a Confluence comment notification for selected RSVP audiences. Before sending, the macro shows a preview of recipients and requires explicit confirmation.
Supported audiences:
* Attending
* Declined
* Missing a custom question answer
* Non-respondents, when enough information is available
The preview shows:
* Direct recipients with Confluence account IDs
* Manual follow-up rows for respondents without account IDs
* Selected response count
* Missing question-answer counts, when relevant
* Draft notification message
Notify preview showing selected audience, direct recipients, manual follow-up count, missing-answer summary, message draft, and send confirmation.
Notifications are sent through a Confluence footer comment with mention recipients. If the same audience and message were sent recently, the macro asks for an explicit send-again confirmation.
## Licensing and migration messages
If the app license is inactive, existing responses remain visible, but new sign-ups and mutation actions are disabled until the license is restored.
During migration or import, a macro may show a banner that historical RSVP data has not been imported yet. When this happens, the macro prevents unsafe changes until the data is verified or imported.
## Data storage and privacy
RSVP for Confluence Cloud stores RSVP data in Atlassian Forge SQL.
Stored RSVP data can include:
* Confluence page ID
* RSVP macro identity
* Name
* Email address
* Comment
* RSVP timestamp
* Response status
* Custom question answers
* Check-in metadata
* Confluence account ID and profile metadata when available
Data is scoped to the Confluence page and RSVP macro identity. There is no global attendee directory in the user-facing macro.
## Support
For help, contact [support@krosoft.nl](mailto:support@krosoft.nl) or visit the [Krosoft Support Portal](https://krosoft.atlassian.net/servicedesk/customer/portals).
---
language: "en"
---
# RSVP for Confluence Data Center
Add lightweight RSVP and attendance tracking directly to Confluence Data Center pages.
RSVP for Confluence Data Center helps teams coordinate meetings, events, and sign-ups inside their own Confluence environment without introducing external tools or manual tracking.
*** ** * ** ***
## Who this is for
* Confluence administrators running Data Center
* Teams that coordinate events, attendance, or sign-ups on Confluence pages
* Organizations that want RSVP data to remain inside their own infrastructure
## What it does
* Adds an RSVP macro to Confluence pages
* Collects attendee responses, comments, and timestamps
* Lets users edit or cancel their own response
* Supports Data Center-compatible storage and operations
* Keeps RSVP data within your Confluence environment
*** ** * ** ***
## Start here
* [User Manual](https://wiki.krosoft.nl/ekb/rsvp-for-confluence-dc-user-manual.md)
* Release Notes: Coming soon
* Support: [support@krosoft.nl](mailto:support@krosoft.nl)
## Notes
Each page tracks its own RSVP data. A global cross-page overview is not available.
---
language: "en"
---
# RSVP for Confluence Data Center - End User License Agreement (EULA)
**Effective Date:** 2025-04-14
## 1. Acceptance of Terms
By installing, accessing, or using this Krosoft app for Confluence Data Center (the "App"), you agree to comply with and be bound by these Terms of Use. If you do not agree to these terms, you may not use the App.
### 2. License
The App is licensed, not sold, to you by Krosoft for use strictly in accordance with these terms. Krosoft grants you a limited, non-exclusive, non-transferable, revocable license to use the App for your internal business purposes only.
### 3. Restrictions
You agree not to:
* Modify, decompile, reverse-engineer, disassemble, or attempt to derive the source code of the App.
* Use the App to infringe upon intellectual property rights of others.
* Use the App for any unlawful purpose.
### 4. User Data and Privacy
The App processes and stores only the data necessary to fulfill its functionality (e.g., user responses submitted via Confluence pages). All data is stored within your Confluence instance, using Atlassian's Active Objects framework. The App does not transmit data externally or collect personal information beyond what is explicitly submitted by users. You are responsible for ensuring compliance with applicable data protection laws.
### 5. Updates and Changes
Krosoft may provide updates to the App that enhance functionality or fix bugs. These updates are subject to these Terms of Use. Krosoft reserves the right to modify or discontinue the App at any time without prior notice.
### 6. Termination
Krosoft may terminate your use of the App at any time if you violate these Terms of Use. Upon termination, you must cease all use of the App and destroy all copies.
### 7. Limitation of Liability
To the maximum extent permitted by law, Krosoft shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from your use of the App.
### 8. Governing Law
These Terms of Use shall be governed by the laws of The Netherlands. Any legal action related to your use of the App shall be brought exclusively in Dutch courts.
### 9. Contact
Questions about this agreement can be directed to: [**support@krosoft.nl**](mailto:support@krosoft.nl)
### 10. Changes to Terms
Krosoft reserves the right to modify these Terms of Use at any time. Continued use of the App after changes constitutes acceptance.
---
language: "en"
---
# RSVP for Confluence Data Center – User Manual
**RSVP for Confluence** adds interactive RSVP functionality to your Confluence pages. Whether you're organizing meetings, events, or coordinating attendance for internal activities, this app lets users easily respond to invitations right from the page itself.
## Key Features
* Add RSVP blocks to any Confluence page
* Collect attendee names, emails, comments, and timestamps
* View, edit, or cancel responses directly on the page
* Track attendance per page
* Works seamlessly in Confluence Data Center environments
* Supports high concurrency, secure storage, and fast UI
### Getting Started
To begin using RSVP for Confluence:
1. **Navigate to a Confluence page** where you want to collect RSVPs.
2. **Click "Edit"** and insert the **RSVP macro** using the macro browser or by typing `/RSVP`.
3. **Save the page**. The RSVP form will now be embedded.
### User Interaction
Once the page is published:
* **Logged-in users** will see a form to submit their RSVP.
* The form collects:
* Display Name (auto-filled for logged-in users)
* Email address
* Optional comment
* Upon submitting, users will see their RSVP below the form.
Each RSVP entry includes buttons to **edit** or **cancel** the RSVP. Users can change their **own** RSVP at any time. If allowed by permissions, Confluence admins can view and edit all RSVPs.
### Viewing RSVPs
All responses are shown in a clean, sortable table embedded below the form. This allows everyone on the page to track attendance in real time.
### Data Storage \& Privacy
All RSVP data is stored in your Confluence database using **Active Objects** --- a robust, DC-compatible persistence layer. No data ever leaves your system.
* Entries are linked to Confluence page IDs.
* You can safely back up and restore RSVP data using Confluence's native backup tooling.
### Admin Notes
* The RSVP form can be added to multiple pages.
* Each page tracks its own responses --- there's no global RSVP overview (yet).
* App-specific configuration is minimal, ensuring easy rollout and low maintenance.
### Performance \& Compatibility
RSVP for Confluence has passed Atlassian's Data Center App Performance Toolkit tests with:
* High concurrency (200+ users)
* 0% error rate on app-specific actions
* No measurable performance degradation
It supports:
* Confluence DC 6 and above (up to 9.4)
* Dark Theme coming soon
* Compatibility with standard security and backup practices
### Support
Having issues or questions? Contact us at [support@krosoft.nl](mailto:support@krosoft.nl) or visit our [Support Portal](https://krosoft.atlassian.net/servicedesk/customer/portals). We're happy to help!
---
language: "en"
---
# Service Level Agreement (SLA)
This SLA applies to all paid apps offered by Krosoft on the Atlassian Marketplace, including but not limited to the following:
* [Related Issues for Jira Cloud](https://marketplace.atlassian.com/manage/apps/1212247)
* [RSVP for Confluence Cloud](https://marketplace.atlassian.com/manage/apps/1212218)
* [RSVP for Confluence Data Center](https://marketplace.atlassian.com/manage/apps/1213905)
## Contact \& Support
Support requests can be submitted via our [Support Portal](https://krosoft.atlassian.net/servicedesk/customer/portals) or by email at [support@krosoft.nl](mailto:support@krosoft.nl).
### Hours of Operation
Our support team is available every day of the week:
* **Days:** Monday through Sunday
* **Time:** 18:00 -- 22:00 (Europe/Amsterdam, GMT+01:00)
### Response Time
We aim to respond to all support requests within **24 hours** of receipt.
Please note that response times may vary based on ticket complexity, volume, and available information.
### Scope of Support
We provide support for the following:
* Questions about app functionality
* Bug reports and troubleshooting
* Guidance with installation and configuration
* Help with upgrading and compatibility
* Custom development
* Product training or consulting
We do not provide:
* Support for third-party apps or Atlassian product issues unrelated to our apps
---
language: "en"
---
# Sync existing planning
Send existing Tempo planning to one outbound connection when setting up an integration or refreshing its calendar.
**Controlled staging evaluation.** Contact [Krosoft support](https://krosoft.atlassian.net/servicedesk/customer/portals) for availability on your installation. Discovery coverage must be checked against your expected Tempo planning before production rollout.
## Before you start
You need Planning Sync administration access, Advanced edition with an active license, and saved Tempo authentication. Enable the selected outbound connection and subscribe it to `plan.created`. For later live changes, also select `plan.updated` and `plan.deleted` and enable the matching Tempo listeners.
First verify the receiving flow with a test calendar. Both create and update must upsert by the complete occurrence ID. Keep the environment/source key stable and use separate keys for staging and production.
## Which planning is included?
| Planning | Selection |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| Ongoing plans | Included when they have an eligible occurrence today or later, even if they began earlier. |
| Finite plans | Today and future planning, including dates beyond the next 12 months. Full discovery coverage remains part of preview validation. |
| Open-ended repeating plans | Daily occurrences are expanded through 12 calendar months after the captured date. |
| Past-only or excluded plans | Not sent. Existing global project and work-item-type scope applies. |
| Unsupported or invalid plans | Shown with a skip reason. Only supported Jira-issue planning can be exported. Generic resources do not imply Outlook mailbox access. |
"Today" uses the initiating administrator's Jira profile timezone and is captured once at the start. A run crossing midnight keeps that date. Daily modes send eligible dates only, with stable IDs. Whole-plan modes send the original eligible plan, which may include historical dates or unbounded recurrence; use the daily strict preset for the Outlook recipe.
Manual sync sends `plan.created` requests to the selected connection. It does not edit Tempo planning, update Jira fields, change approvals or invoke native Jira Automation. Allocation counts and delivery counts differ: one multi-day allocation can produce several daily requests.
## Start a sync
1. Open **Apps → Planning Sync → Outbound**.
2. On the required connection, choose **Sync existing planning**.
3. Review the receiving-flow warning, choose **Sync existing planning** in the panel, then **Start sync** to confirm.
4. Watch discovery and delivery counts. You can close the panel and return later; processing continues in the background.
Choose Start sync to confirm delivery to this connection.
Repeated starts return the same unfinished run, including a run that needs attention. After a run completes, a new sync can resend the eligible planning. It does not delete unrelated calendar entries or automatically repair older entries created with different keys.
## Verify the result
**Accepted by webhook** means the receiving endpoint returned a successful HTTP response. It does not confirm Outlook processing. Check all five points below:
1. Discovery is complete. If it is incomplete, resolve the reported problem before treating the run as a full export.
2. Review failed and skipped items. Every expected exclusion should have an understood reason; unresolved failures mean work remains.
3. Compare eligible Tempo planning with the exported dates, including ongoing and far-future plans. One allocation can produce several daily requests, so allocation and appointment counts need not match.
4. Check Power Automate run history. Investigate failed or waiting Outlook actions, even when the webhook was accepted.
5. Verify appointments in the target calendar: expected dates and times, full occurrence keys, and no duplicates after a repeat sync.
Two allocations produced four accepted daily requests. Check the receiving flow and Outlook to confirm the calendar result.
An empty result means no eligible planning was found by that run. It does not establish that permissions exposed every expected plan. See [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md) when any check fails.
Staging validation checklist
| Check | Expected result |
|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|
| Initial sync | Expected ongoing, today and future dates appear in the test calendar, including a finite plan beyond 12 months. |
| Repeat sync | The same managed appointments are updated, with no duplicates. |
| Live edit and delete | Change dates/times, remove first and last days, re-add a day, then delete the plan. Outlook follows each change and retained IDs stay stable. |
| Scope and permissions | Excluded planning is not sent; expected users/resources are accounted for. Investigate incomplete discovery. |
| Failure and retry | Fix a test flow error, then retry failed items. Accepted items are not resent by this retry. |
Use fresh disposable test plans. Preserve unrelated calendar items. Before production rollout, verify the installed version, expected planning coverage, receiving-flow capacity and the complete lifecycle in your own environment.
## Related guides
* [Set up the Outlook flow](https://wiki.krosoft.nl/ekb/sync-tempo-plans-to-outlook-with-power-automate.md)
* [Outbound payload reference](https://wiki.krosoft.nl/ekb/outbound-payload-reference.md)
* [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md)
---
language: "en"
---
# Sync Tempo plans to Outlook with Power Automate
Build a customer-managed Power Automate flow that creates one Outlook appointment for each eligible planned Tempo day, then updates or deletes it when planning changes. This reference uses one target calendar and synchronous HTTP responses. You configure the flow and Microsoft permissions in your own tenant; it is not an importable flow package.
After setup: [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md) (staging preview), [Outbound payload reference](https://wiki.krosoft.nl/ekb/outbound-payload-reference.md) and [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md).
## Choose your scenario
| Scenario | Scope of impact |
|-------------------------------------|-----------------------------------------------------------------------------------------------------------|
| Live planning changes | Subscribed create, update and delete events go to matching connections. |
| Sync existing planning | Eligible planning goes to one selected connection. Tempo plans, Jira fields and approvals stay unchanged. |
| Synchronous Outlook recipe | This guide: one configured calendar; the flow responds after calendar processing. |
| Failure before webhook acceptance | The app retries eligible failures. An endpoint HTTP 429 can pause delivery to that destination. |
| Outlook failure after acceptance | The receiving flow handles recovery and Outlook connector throttling. |
| Multi-user routing or durable inbox | Advanced receiver designs requiring separate validation; customers manage calendar access and routing. |
The daily preset sends individual occurrences. Whole-plan payloads can include historical dates or unbounded recurrence; see the [payload reference](https://wiki.krosoft.nl/ekb/outbound-payload-reference.md). **Sync existing planning:** controlled staging evaluation; contact Krosoft support for availability on your installation.
## Before you start
You need Planning Sync Advanced, Planning Sync administration access, an active Tempo connection with plan webhooks enabled, and a Microsoft account allowed to create Power Automate flows and write to the chosen Outlook calendar. Check that your Microsoft licence supports the HTTP request trigger. Start with a separate test calendar and fresh Tempo plans.
This recipe covers appointments with a start and end time on the same day. Choose one target calendar for the first setup. The Office 365 Outlook connection determines which calendars the flow can access. An assignee name or email in the request does not automatically grant access to that person's calendar.
For multiple calendars, durable inboxes or sustained volume, use the [advanced receiving patterns](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md) as design guidance. These require separate implementation and validation. Assignee information does not grant mailbox access, and adding attendees is a separate invitation workflow.
## 1. Create the Power Automate trigger
1. Create a cloud flow with **When an HTTP request is received** and method **POST**.
2. For a direct Planning Sync webhook, select **Anyone** under **Who can trigger the flow?** Planning Sync does not send a Microsoft Entra bearer token. If your organisation requires authenticated tenant-only triggers, ask your Microsoft administrator for an approved intermediary rather than expecting a direct webhook to authenticate.
3. Treat the generated HTTP URL as a secret. Share it only with administrators configuring the destination. A shared secret in Planning Sync adds an `X-Signature` header; it does not validate requests automatically. Enable it only alongside a receiver that actually checks the signature.
4. Paste the exact JSON schema from step 3 into both the HTTP trigger's Request Body JSON Schema and Parse_JSON. Do not generate another schema from the sample. The trigger can reject required-field/type failures before a flow run starts; its response is platform-managed. Save the flow and copy the complete generated HTTP POST URL.
5. Check trigger **Settings** before saving. The synchronous Response pattern below required **Concurrency control** to remain off in our tested Power Automate environment; the designer rejected it with degree 1. Do not assume that lookup followed by create is atomic when runs overlap. For sustained volume, use a durable inbox and serialize processing, with an idempotent occurrence-key mapping. See [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md) for the acknowledgement patterns and retry responsibilities. Validate your chosen configuration in staging.
Microsoft explains the [HTTP trigger authentication options](https://learn.microsoft.com/en-us/power-automate/oauth-authentication) and [flow concurrency limits](https://learn.microsoft.com/en-us/power-automate/limits-and-config).
## 2. Configure Planning Sync
In Jira, open **Apps → Planning Sync → Outbound** and add a connection:
| Setting | Value |
|----------------------|--------------------------------------------------------|
| Name | A recognisable name, such as Outlook planning --- test |
| URL | The complete Power Automate HTTP POST URL |
| Events | `plan.created`, `plan.updated`, `plan.deleted` |
| Orchestration preset | **Strict time-based system** (`TIME_WINDOW_REQUIRED`) |
| Payload mode | **Custom body** |
| Enabled | Enable after the flow is ready |
Use the strict preset so each request represents one day with a usable time window. Raw Tempo passthrough forwards a parent plan and is not suitable for this day-by-day recipe. Check that the required Tempo plan subscriptions are active in Planning Sync setup; do not enable unrelated Jira field updates just to build this calendar integration.
Paste this custom body. Change `sourceKey` to a stable, unique name for this Jira environment and calendar integration; use letters, numbers and hyphens. Keep it unchanged after setup.
JSON
{
"sourceKey": "jira-prod-outlook",
"eventType": "{{eventType}}",
"occurrenceId": "{{payload.id}}",
"parentPlanId": "{{payload.planId}}",
"date": "{{payload.date}}",
"startTime": "{{payload.startTime}}",
"endTime": "{{payload.endTime}}",
"issueKey": "{{issue.key}}",
"issueUrl": "{{issue.url}}",
"assigneeName": "{{assignee.displayName}}"
}
`occurrenceId` is the full daily identity. For example, `46.3` and `46.4` are different appointments, even when they share a parent plan. IDs can also be genuine Tempo child IDs: treat them as opaque strings, keep the complete value, and never calculate or renumber their suffixes. Use `parentPlanId` only as additional information.
Gaps such as `46.3`, `46.5` and `46.11` are expected: retained identities are not consecutive day numbers. See [Outbound payload reference](https://wiki.krosoft.nl/ekb/outbound-payload-reference.md) for ID compatibility and optional descriptions.
Use **date + startTime/endTime from the daily payload** for appointment times. Using the parent plan's start date for every update makes appointments collect on the same day.
Select all three plan events and Custom body. The URL shown is a placeholder: paste your complete generated Flow URL.
Example of the daily identity/date/time fields and Strict time-based system preset. Copy the full JSON example in this guide; optional issue and assignee fields are omitted in this screenshot.
## 3. Parse the request and build the lookup key
First add Scope **Process_request** immediately after the HTTP trigger. Build every processing action below inside this Scope. Add the outer Handle_failure Scope only after completing steps 3--5.
Use this hierarchy as the build order. Action names must match the expressions. Each lookup is in the branch that uses its result; there is no shared Find_events action.
HTTP trigger
Process_request
Parse_JSON
Valid_identity
False: Response 400 → Terminate
True:
Event_subject
Is_delete (eventType equals plan.deleted)
True:
Find_delete_events
Match count: 0 → Response 200
1 → Delete → Response 200
2 → Response 409 → Terminate
False (create or update):
Has_window
False: Response 400 → Terminate
True:
Validate_window (Valid_window)
Reject_window [after Validate_window failed/timed out]
Response 400 → Terminate
Write_calendar [after Validate_window succeeded]
Find_write_events
Match count: 0 → Create → Response 200
1 → Update → Response 200
2 → Response 409 → Terminate
Handle_failure [after Process_request failed/timed out]
Response 500
Add **Parse JSON** , with the HTTP trigger body as Content, and rename the action **Parse_JSON**. This resolved request is a test example, not a schema-generation instruction:
JSON
{
"sourceKey": "jira-prod-outlook",
"eventType": "plan.created",
"occurrenceId": "46.1",
"parentPlanId": "46",
"date": "2026-10-05",
"startTime": "15:00",
"endTime": "17:00",
"issueKey": "PROJ-123",
"issueUrl": "https://your-site.atlassian.net/browse/PROJ-123",
"assigneeName": "Alex Example"
}
`sourceKey`, `eventType` and `occurrenceId` are required strings. A single template expression preserves the resolved JSON type, even inside quotes: `parentPlanId` may be a number, and missing optional metadata may be null. Handle deletes before checking time fields. Deletion needs the occurrence key, not a new appointment window.
Paste this schema into both the HTTP trigger and Parse_JSON. Keep only its three required fields. Optional fields allow null; create/update times are validated separately.
JSON
{
"type": "object",
"properties": {
"sourceKey": {
"type": "string"
},
"eventType": {
"type": "string"
},
"occurrenceId": {
"type": "string"
},
"parentPlanId": {
"type": [
"string",
"number",
"null"
]
},
"date": {
"type": [
"string",
"null"
]
},
"startTime": {
"type": [
"string",
"null"
]
},
"endTime": {
"type": [
"string",
"null"
]
},
"issueKey": {
"type": [
"string",
"null"
]
},
"issueUrl": {
"type": [
"string",
"null"
]
},
"assigneeName": {
"type": [
"string",
"null"
]
}
},
"required": [
"sourceKey",
"eventType",
"occurrenceId"
]
}
After Parse_JSON, add Valid_identity as described below. Inside its true branch, add a **Compose** action named **Event_subject**. In its Expression tab, paste:
concat('Planning Sync | ', body('Parse_JSON')?['sourceKey'], ' | ', body('Parse_JSON')?['occurrenceId'])
Example subject: `Planning Sync | jira-prod-outlook | 46.1`. This recipe uses the entire fixed subject as its lookup key. Keep it on both create and update, and do not manually rename managed events in Outlook. Put the Jira issue and assignee information in the body instead.
### Build validation before the lookup
Inside Process_request, before any Outlook action, add these Conditions. In the Expression tab paste without @, compare the result using "is equal to" and Boolean expression true.
Condition Valid_identity:
and(not(empty(trim(body('Parse_JSON')?['sourceKey']))),not(empty(trim(body('Parse_JSON')?['occurrenceId']))),contains(createArray('plan.created','plan.updated','plan.deleted'),body('Parse_JSON')?['eventType']))
False → Response 400, then Terminate → Succeeded. True → compare eventType with plan.deleted. Deletes bypass time validation and proceed to their lookup/delete/no-op branch. For create/update, add Condition Has_window:
and(not(empty(body('Parse_JSON')?['date'])),not(empty(body('Parse_JSON')?['startTime'])),not(empty(body('Parse_JSON')?['endTime'])))
False → Response 400, then Terminate → Succeeded. True → add Scope Validate_window containing Condition Valid_window:
and(equals(formatDateTime(concat(body('Parse_JSON')?['date'],'T',body('Parse_JSON')?['startTime']),'yyyy-MM-ddTHH:mm'),concat(body('Parse_JSON')?['date'],'T',body('Parse_JSON')?['startTime'])),equals(formatDateTime(concat(body('Parse_JSON')?['date'],'T',body('Parse_JSON')?['endTime']),'yyyy-MM-ddTHH:mm'),concat(body('Parse_JSON')?['date'],'T',body('Parse_JSON')?['endTime'])),greater(ticks(concat(body('Parse_JSON')?['date'],'T',body('Parse_JSON')?['endTime'])),ticks(concat(body('Parse_JSON')?['date'],'T',body('Parse_JSON')?['startTime']))))
False → Response 400 with {"error":"Invalid same-day time window"}, then Terminate → Succeeded. True → leave this branch empty. This validates YYYY-MM-DD and HH:mm with end later than start.
Add two sibling Scopes depending directly on Validate_window: **Reject_window** runs only after failed/timed out and returns 400 with {"error":"Invalid date or time format"}, then Terminate → Succeeded. **Write_calendar** runs only after successful and contains the create/update lookup and writes. Do not chain these sibling Scopes after each other. Date parsing exceptions are therefore rejected before Outlook writes. Keep the delete lookup in its separate branch.
See Microsoft's [expression reference](https://learn.microsoft.com/en-us/azure/logic-apps/expression-functions-reference). Follow every rejection Response with Terminate to prevent subsequent writes or a second response.
## 4. Find the existing appointment
Add Office 365 Outlook **Get events (V4)** twice: **Find_delete_events** inside Is_delete's true branch, and **Find_write_events** inside Write_calendar. Use the same filter and calendar settings for both. Never place a lookup before validation. Select the target calendar you chose for this integration.
In its advanced **Filter Query**, enter an exact subject filter. For the example above, the resolved query is:
subject eq 'Planning Sync | jira-prod-outlook | 46.1'
Build the filter using the **Outputs** dynamic content from **Event_subject** , surrounded by the single quotes shown above. Escape any apostrophe in a custom key as two apostrophes. Do not filter on just the parent ID, and do not restrict the search to the incoming date: a moved appointment may still exist on its old date. Set **Top Count** to **2** so you can detect duplicate matches without scanning the whole calendar.
In the delete branch, count matches with this expression:
length(body('Find_delete_events')?['value'])
In Write_calendar, use the corresponding expression:
length(body('Find_write_events')?['value'])
In each branch use a Switch on this numeric count with cases 0, 1 and 2. The incoming event-type check has already selected delete versus create/update.
* **0:** no managed appointment exists.
* **1:** use the matching Outlook event's `id` for update/delete.
* **2:** stop and report duplicate managed events for cleanup. Do not silently update the first match.
The Outlook event ID is different from `occurrenceId`. The occurrence key finds the appointment; the Outlook connector's `Id` field takes the returned Outlook event ID.
## 5. Create, update or delete
Use the Is_delete Condition and the match-count Switch in each branch from the hierarchy above. Do not add a second event-type Switch. Apply this behavior:
| Incoming event | No match | One match |
|----------------|-------------------------------------|-------------------|
| `plan.created` | Create event (V4) | Update event (V4) |
| `plan.updated` | Create event (V4) | Update event (V4) |
| `plan.deleted` | Finish successfully; already absent | Delete event (V2) |
Sequential replay finds and updates the same appointment; a repeated delete succeeds when the appointment is absent. Overlapping lookup/create actions can still produce duplicates because the lookup is not an atomic uniqueness check. Use receiver-side serialization or durable correlation for concurrent processing. Reject unexpected event types instead of creating an appointment.
Changing only the time or details of a retained planned date keeps its occurrence key and updates the matching appointment. Moving a plan to another date can instead remove one daily occurrence and add another: Planning Sync sends `plan.deleted` for the removed date, followed by `plan.updated` requests for the current dates. The receiving flow creates an appointment for a new date when its occurrence key has no match. Dates retained in both ranges keep their keys and are updated; re-added dates reuse their recorded keys. This does not mean every update deletes and recreates the same appointment, and sharing the create/update branch does not itself trigger deletion. For example, moving a single planned day from 2026-10-05 to 2026-10-09 removes the old daily appointment and creates the new one if absent. Correlate the source change and compare event type, occurrence key and date across the resulting runs.
For Delete event (V2), use this Id expression only in case 1 of the delete match-count Switch:
first(body('Find_delete_events')?['value'])?['id']
For Update event (V4), use this Id expression only in case 1 inside Write_calendar:
first(body('Find_write_events')?['value'])?['id']
Use the same target calendar throughout.
For create and update, first check that `date`, `startTime` and `endTime` are present and represent a valid same-day time window. Then use the following fields on both actions:
| Outlook field | Value |
|-----------------------------------|----------------------------------------------------------------------------------------------|
| Calendar | The integration's target calendar |
| Subject | Outputs of **Event_subject** |
| Start time | Expression below using this occurrence's date |
| End time | Expression below using this occurrence's date |
| Time zone | Your planning time zone, for example the Amsterdam/Berlin option (`W. Europe Standard Time`) |
| Is all day event? | No |
| Recurrence | None |
| Body | Issue key/link and assignee name from Parse_JSON |
| Show as / reminder / other fields | Your chosen values, explicitly set on create and update |
Start time:
concat(body('Parse_JSON')?['date'], 'T', body('Parse_JSON')?['startTime'])
End time:
concat(body('Parse_JSON')?['date'], 'T', body('Parse_JSON')?['endTime'])
For example, these produce `2026-10-05T15:00` and `2026-10-05T17:00`. Use the corresponding planning time zone, not a fixed UTC offset. Planning Sync sends each repeating occurrence separately, so do not also create an Outlook recurring series. Keep attendees empty for ordinary calendar appointments. Microsoft notes that update fields can reset when omitted; supply the intended properties consistently in [Create/Update event actions](https://learn.microsoft.com/en-us/connectors/office365/).
### Error handling and responses
1. Process_request was created in step 3. Keep its actions in the hierarchy shown there; rename actions exactly before pasting expressions.
2. Before the lookup, reject empty sourceKey/occurrenceId or any eventType other than plan.created, plan.updated and plan.deleted. For create/update, reject missing or invalid date/time values and end times that are not later than start times. Use Response **400** with a short error body, then Terminate with status Succeeded to stop this rejected request. A delete does not require date/time validation.
3. After each branch's own lookup (Find_delete_events or Find_write_events), use its matching count expression: **0** enters the create/already-absent branch; **1** enters update/delete; **2** returns Response **409** with an error such as "Duplicate managed events; cleanup required", then Terminate with status Succeeded. Never run a calendar write after an error response.
4. Finish each successful branch with Response **200**, after its Outlook action completes. The zero-match delete also returns 200. For example, use {"status":"ok"} as the response body.
5. Outside Process_request, add a Scope named **Handle_failure** . Open its menu → **Configure run after** for Process_request. Select only **has failed** and **has timed out** ; clear is successful and is skipped. Inside Handle_failure add Response **500**, for example {"error":"Calendar sync failed; check flow run history"}. Parse_JSON failures also reach this handler.
6. For this synchronous recipe, return success after calendar processing, without an early Response or automatic asynchronous acknowledgement. A durable-inbox design may instead acknowledge durable receipt and monitor Outlook separately; see [Delivery status and recovery](https://wiki.krosoft.nl/ekb/delivery-status-and-recovery.md). Keep connector errors visible in run history. Trigger schema failures may receive a platform-managed response before a run starts. Unexpected Parse_JSON failures inside Process_request reach the 500 handler; business validation uses the explicit 400 branches. Do not manually replay an old create/update after its delete.
**Branch checklist:** create/update + 0 → Create event; create/update + 1 → Update event; delete + 0 → 200 without a calendar write; delete + 1 → Delete event; any event + 2 → 409 without a calendar write.
## 6. Enable and test
Save and turn on the flow, then enable its Planning Sync destination. Use fresh disposable plans in the test calendar. Check both Planning Sync audit logs and Power Automate run history before judging the Outlook result; changes can appear after the Tempo edit is saved.
Detailed lifecycle and error tests
| Test | Expected Outlook result |
|--------------------------------------------------------------------|-------------------------------------------------------------------------------|
| Create four consecutive days, 15:00--17:00, 2h/day | Four appointments, one on each date, with four complete occurrence keys |
| Remove the last day | One delete; three retained appointments with unchanged keys |
| Repeat with the first day removed | Same result; retained IDs are not renumbered |
| Reduce to one day, then extend | One appointment first; extension adds the required dates without duplicates |
| Move/change the plan rapidly several times | Only the final dates/times remain after successful processing |
| Delete after rapid changes | No appointments remain for that plan |
| Weekly: 19 October 2026 until 2 November, 15:00--17:00 | Only 19 October, 26 October and 2 November |
| Shorten Until to 26 October; extend again | Only 2 November disappears, then returns with its previous occurrence key |
| Change to Bi-weekly with Until 2 November | Only 19 October and 2 November |
| Delete the repeating series | All its managed appointments disappear |
| Replay create/update before deletion; replay delete after deletion | Create/update replays keep one appointment; repeated deletion keeps it absent |
After changing **Repeat** , check **Until** again: Tempo may reset it to a default three months later. A blank Until in the UI can still be saved as a finite default. Use an explicit end date; a genuinely missing recurrence end date is skipped and shown in the app's audit log. Custom holiday calendars and nonstandard working weeks are outside this recipe.
### Error-branch acceptance tests
Use the resolved sample and disposable calendar. Check HTTP response, run history and calendar contents.
* Missing occurrenceId or numeric occurrenceId: trigger schema rejection, no Outlook action; response is platform-managed.
* Empty occurrenceId or eventType plan.unknown: 400, no lookup/write.
* Create/update missing startTime, date 2026-02-30, time 25:00, or end earlier than/equal to start: 400, no calendar write.
* Delete with only sourceKey/eventType/occurrenceId: 200, delete one match or no-op when absent.
* Create two disposable events with the exact matching subject. Test create/update/delete separately: 409, both events untouched. Remove only these test duplicates afterwards.
* Select an inaccessible test calendar or disconnected test connection: 500 and failed connector action visible in run history. Restore it, replay the current request and verify one correct appointment.
* Replay create/update before deletion; delete twice afterwards: 200, one appointment before deletion and none afterwards.
## Troubleshooting and existing calendars
| Symptom | Check |
|--------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Flow returns 401/403 or never starts | Complete current trigger URL, trigger access setting, enabled destination and selected events |
| Parse JSON fails | Use the same published schema in the trigger and Parse_JSON. Keep three required string fields, nullable optional metadata and a string-or-number parentPlanId. |
| All appointments move to one date | Start/end expressions must use daily `date`, not parent start/end dates |
| Duplicate appointments | Full occurrence key, exact lookup, consistent subject and one matching route. Investigate overlapping runs; the synchronous example does not guarantee sequential flow execution. |
| Wrong calendar | Outlook connection, Calendar selection and any explicit assignee routing |
| Times shift by one or two hours | Match the planning time zone; avoid hard-coded UTC offsets |
| Plans are accepted but Outlook lags | Audit entries and flow run completion; look for waiting runs, 429s or connection failures |
| Audit requests controlled resync | Stop and contact support before replaying or cleaning up existing appointments |
The corrected settings do not repair old appointments created with parent-only IDs or incorrect dates. Pause the affected integration and agree a controlled cleanup with support. Remove only its managed legacy appointments and corresponding old correlation records, then re-enable the corrected flow. Where the staging feature is enabled, [Sync existing planning](https://wiki.krosoft.nl/ekb/sync-existing-planning.md) can repopulate eligible dates without recreating Tempo plans. It does not remove incorrectly keyed legacy appointments. Verify the first deliveries and keep unrelated calendar items.
Optional email notifications
If you want an email instead of a calendar appointment, use **Send an email (V2)** after Parse_JSON, with a fixed recipient or an explicit routing rule. Include `eventType`, `issueKey`, `parentPlanId`, `occurrenceId` and the daily date/times in the message. Email delivery is separate from the calendar create/update/delete logic and does not itself keep calendar appointments in sync.
For app installation and access, see the [Planning Sync User Manual](https://wiki.krosoft.nl/ekb/planning-sync-for-jira-tempo-integration-user-manu.md).