Outlook as Master – Syncing Absences to Jira

Overview

In many organizations, Outlook Calendar is where employees already record time off — vacation requests, sick days, business trips. Rather than asking users to enter the same absence twice (once in Outlook, once in Jira), you can set up Outlook as the master system: absence events created, changed, or cancelled in Outlook are automatically reflected as absences in Jira via the User Absence Planner (UAP) app.

This page walks through the two building blocks needed to set this up:

1. Jira side — how the sync request is received and turned into a UAP absence

2. Outlook side — how a calendar change is detected and turned into a create/update/delete call

Note: this is not an out-of-the-box integration. It requires either a no-code automation tool (Power Automate) or a small custom script, configured for your organization's Outlook and Jira setup.

1. Jira side: two ways to receive the sync

Option A — Direct REST API calls

Call the UAP Create / Edit / Delete Absence endpoints directly from whatever runs on the Outlook side.

• Authenticate with an email address + UAP API token (Apps → Manage apps → User Absence Planner Settings → API token tab)

• Since one identity will be creating/editing/deleting absences for many users, that identity needs permission to manage absences on behalf of other users, not just its own

• Simple to set up, but the API token then has to be stored securely wherever your Outlook-side automation runs

Option B — Jira Automation "Incoming Webhook" + UAP Automation Actions (recommended)

Jira Automation supports an Incoming webhook trigger, which gives you a URL and secret. Your automation rule receives a JSON payload and then uses the existing UAP automation actions (Create absence / Edit absence / Delete absence), referencing the payload via {{webhookData.<field>}} smart values.

This is generally the better option when an external system is the master, because:

• No UAP API token needs to be handed to the Outlook-side tool or script — the automation rule's own connection to UAP handles authentication

• Mapping and validation logic (e.g. rejecting an absence type that doesn't exist in your instance, or branching on create vs. update vs. delete) lives centrally in one Jira Automation rule instead of being scattered across scripts

• The rule doesn't care what triggers it — you can swap the Outlook-side tool later without touching Jira

• Automation's built-in audit log gives you a ready-made trail for troubleshooting

In practice, build either one rule per operation (create/edit/delete) or a single rule that branches on an action field you include in the webhook payload.

2. Outlook side: two ways to detect changes and call Jira

Option 1 — Power Automate (no-code, Microsoft-native)

Best suited to teams already working in the Microsoft ecosystem who want something maintainable without writing code. Runs in the cloud, so it isn't tied to a specific laptop being switched on.

• Trigger: When an event is added, updated or cancelled (V3) (Office 365 Outlook connector), scoped to the calendar you want to sync from. This trigger reports a Type (added/updated/deleted) you can branch on.

• Filter: decide up front how an absence event is distinguished from a regular meeting. A dedicated Outlook Category (e.g. "Vacation", "Sick", "Business Trip") is usually the easiest signal, since it doesn't require moving events to a separate calendar.

• Action: an HTTP call to either the Jira Automation incoming-webhook URL (Option B above) or directly to the UAP REST endpoint (Option A).

• Correlating updates and deletes: you need to persist a mapping between the Outlook event and the UAP absence ID returned when it was created — otherwise a later update or cancellation has nothing to target in Jira. Two common approaches:

  • Store the mapping (Event ID → Absence ID) in a SharePoint list or Excel table

  • Write the absence ID back onto the Outlook event itself via a Microsoft Graph PATCH call using a single-value extended property, so the mapping travels with the event and no separate storage is needed

• Licensing note: calling arbitrary URLs (the HTTP action) is a Premium connector in Power Automate — confirm your tenant has the right licensing before planning around this as the "no-code" option.

Option 2 — Script against Microsoft Graph (PowerShell / Python / Node)

More setup effort, but no Power Automate licensing dependency, and easier to run centrally across many mailboxes at once.

• Register an Entra ID (Azure AD) app with the Calendars.Read permission — delegated (per user) or application (admin-consented, can read across mailboxes, useful for a central sync job)

• Use Microsoft Graph's delta query instead of re-scanning the whole calendar on every run:

  • First call: GET /users/{id}/calendarView/delta?startDateTime=...&endDateTime=...

  • Store the returned @odata.deltaLink and call it again next run — Graph returns only what changed since then, with deleted events flagged @removed

• For each changed event: skip anything that doesn't match your "this is an absence" rule (same category/calendar logic as Option 1), map the fields (see below), then:

  • New event → call Create Absence → store event.id → absence.id

  • Already-synced event that changed → call Edit Absence with the stored absence ID

  • @removed → call Delete Absence with the stored absence ID

• Run it as a scheduled job on a server, or — more reliably — as a timer-triggered Azure Function, so it doesn't depend on any specific machine being on.

3. Field mapping

4. Getting started

• Set up the Jira side first (Option B is recommended) — it's reusable and testable on its own, independent of whatever you build on the Outlook side.

• Pick Option 1 or 2 on the Outlook side based on what's already available: Power Automate Premium licensing, or in-house capacity to build and host a script.

• Introduce a dedicated Outlook Category (or calendar) to mark "this is an absence" before building anything else — syncing every calendar entry is unreliable, and there's no single, Graph-queryable "this is out-of-office" flag that behaves consistently across all Outlook clients.

• Plan for updates and deletions from day one: without persisting the event ↔ absence mapping, only the initial creation will work reliably.

We don't currently offer this integration out of the box, but the building blocks above (REST API, Automation Actions with Incoming Webhook trigger, and Microsoft Graph) are enough to build it for your organization's specific setup.