How RectifAI Works

RectifAI coordinates incident work across three layers:

1. Operational context: teams, systems, ownership, and workspace settings
2. Execution: incidents, status transitions, tasks, roles, and orchestration
3. Connected systems: Jira Service Management, chat providers, paging providers, and meeting providers

The normal workflow

Step 1: model your environment

You define:

• who responds: teams
• what they own: systems
• where notifications go: chat and paging configs

Step 2: connect your tools

You connect providers by function:

• JSM for ITSM
• Slack, Google Chat, or Teams for chat
• PagerDuty or JSM Operations for paging
• Zoom, Google Meet, or Teams for meeting engagement

Step 3: declare an incident

When an incident is created, RectifAI records the event and uses the selected systems and configured providers to decide what to do next.

Depending on your configuration, that can include:

• creating the linked Jira issue
• attaching systems to the incident
• notifying chat groups
• paging the appropriate responders

Step 4: coordinate the response

During the incident, the team can:

• move the incident through statuses
• assign an owner
• assign roles
• add tasks
• add or remove systems
• keep the incident aligned with JSM and any connected providers

Step 5: capture follow-up work

After the incident, RectifAI can help create:

• a problem record in Jira
• follow-up action items
• workspace-level reporting inputs

Why the app is structured by function

Integrations in RectifAI are grouped by what they do, not just by vendor.

That means your team can decide:

• which tool handles chat
• which tool handles paging
• which tool handles meetings

This is why the Integrations area is organized into:

• JSM
• Chat
• Paging
• Engage

What users should expect

RectifAI is opinionated in a few important ways:

• authentication happens through Atlassian
• workspace membership controls access
• JSM is the ITSM anchor for incident and problem records
• integrations are provider-based, but workflows are category-based

This makes the app easier to reason about operationally, especially for teams that already use multiple vendors across the incident lifecycle.