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 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.

Completed run and retry controls in the test UI — Review accepted, failed and blocked counts separately. Accepted requests can still have unfinished downstream Outlook work.

Recover a failed delivery

Open the connection’s Preview planning sync panel. Choose Show failures and use Next details to read additional pages. Use Show skipped planning to inspect exclusions.
Match the error to Planning Sync audit entries and, where present, the Power Automate run. Use the table below to correct the cause.
Choose Retry failed items. Accepted items stay accepted; failed items receive a fresh set of attempts and keep their position ahead of later changes.
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 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

A timed-out response can coexist with a completed calendar write. In Power Automate, check the Response action and calendar action separately.

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.

Connection changes and retention

Disable a connection to pause delivery. Deleting it leaves affected work visibly failed and removes its saved callback and additional credentials; if cleanup fails, the disabled entry remains for retry. Existing batches keep their original request format, payload, settings and credential references through an app update. The original flow and history preview stay compatible. Optional live comparison does not rewrite queued events; its receiver must keep accepting them at the same URL. HMAC webhook signing uses the current signing secret; additional Outlook secrets use the captured credential. Before enforcing an extra-secret gate, finish or reconcile older queued requests that cannot supply it. Do not delete and recreate a connection to bypass its queue.

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 or repeat sync can therefore repeat a request. Upsert and delete must use the same complete occurrence key: update one matching appointment, create only when absent. Updating synchronized fields from Tempo is intended. Sync-history preview does not establish current calendar state or make duplicate prevention unnecessary. 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.