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. In the normal Power Automate Outlook setup, keep the configured body in its original shape: the app automatically wraps it for new preview/sync commands, and the compatible flow unwraps it before applying the original schema and matching expressions. Do not paste a command envelope into the custom-body editor. Original queued events retain their unwrapped format; optional outer identity is for correlation, not a replacement for customer matching. See flow preparation and upgrade.
Template roots
|
Root |
Meaning |
|---|---|
|
|
Aliases for the outgoing payload after orchestration. They are not separate guaranteed full Tempo API records. |
|
|
|
|
|
Best-effort Jira enrichment, such as key, summary and URL. |
|
|
Best-effort Jira-user enrichment, such as displayName and email. Lookup failure can leave only the ID. |
|
|
Source webhook event ID when present. Do not use it as the calendar occurrence key. |
Daily calendar fields
|
Expression |
Use |
|---|---|
|
|
Complete occurrence identity. Match the same appointment for create, update and delete. |
|
|
Parent plan reference; not a unique daily calendar key. |
|
|
Individual occurrence date. |
|
|
Same-day time window when provided/enriched by the chosen preset. |
|
|
Combined local datetime for a flow that expects startDateTime; use the matching endTime expression too. |
|
|
Optional Jira details; allow missing values. |
|
|
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
-
In Power Automate, open My flows, select the receiving flow and open the relevant run in its run history.
-
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.
-
Compare
eventType,occurrenceId, dates and JSON types with the schema. Check create, update and delete separately; delete requests may omit time fields. -
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 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.
{
"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
{
"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:
{
"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
Optional date-only delivery
When Send plans without a start time as date-only is enabled for daily plan events, the app adds top-level dateOnly (boolean) and plannedSeconds (planned duration in seconds). The original time fields and full occurrence identity remain unchanged. This metadata is also added to custom JSON objects; arrays are not supported with this option.
dateOnly: true means the recovered daily start is midnight. Other daily starts receive false. Tempo exposes date-and-duration plans and deliberate midnight starts identically. The option is off by default and adds no fields while off; it does not change worklog payloads or previously prepared requests. Receiving flows must implement the indicator. Our Outlook recipe maps it to an all-day appointment and includes the planned hours in its body.