Jira

1. An Admin or Owner connects Jira Cloud with Atlassian OAuth from Organization → Integrations.
2. Webhooks register automatically for the connected site.
3. Link each monitored worker to their Atlassian account under People. Unmapped assignees are ignored.

Jira Server and Data Center are not supported — OAuth 2.0 (3LO) and webhooks are Cloud-specific. Marketing detail: Jira integration page.

Status transitions become timeline events at high level: created, moved to in-progress, done, and other category-aligned states. Each event carries issue key, transition timestamp, and assignee (when mapped to a worker).

Freshness is near real-time after setup — webhooks fire when Jira changes, rather than waiting for a poll cycle. Overlay Jira flow with Slack and GitHub on Monitoring to see delivery rhythm in context.

Completed issues contribute story points per worker and team into reports and SPACE Performance signals. We count transitions and completed points — not open ticket backlog size or a Jira leaderboard.

“In-progress” engagement is measured by status transitions (flow), not by how many tickets sit in a column.

Custom workflow names roll up through Jira status categories (to-do, in-progress, done). You do not need to rename statuses for WePeople to understand flow.

Today, OAuth scopes apply to all projects in the connected Cloud site. Project-level exclusion is on the roadmap. Until then, use team filters in monitoring and reports to focus on relevant groups.

The Jira connector ingests structured delivery metadata only:

• We read: lifecycle events, story points on completed issues, issue keys, status transition timestamps, assignee account IDs (mapped workers).
• We do not read: issue descriptions, comments, custom field values, attachment contents, or worklog comment bodies.

Full matrix: marketing detail page and trust model.