FastSLA User Guide¶

This site is the user handbook for FastSLA.

It explains the thinking behind FastSLA, how to configure projects, import source data, understand SLA state, review issues, and use reports.

How this guide is organized¶

The guide is grouped by how users normally work:

Section	Read it when
Start	You are new to FastSLA or setting up the first project.
Configure	You need to connect sources, map workflow statuses, set SLA rules, or administer the workspace.
Operate	You need to read current issues, inspect timelines, or produce report follow-up.
Reference	You need definitions or troubleshooting steps.

Start here¶

Use these guides in this order when you are setting up FastSLA for the first time:

Main product areas¶

Area	Use it for
Overview	See issues that need attention now and understand current SLA pressure.
Projects	Configure source connections, filters, workflow meanings, SLA goals, notifications, and destructive project actions.
Issues	Inspect live issues, filter by SLA state, and open detailed issue explanations.
Reports	Measure contract-correct SLA compliance over a selected date window.
Settings	Manage workspace timezone, holiday calendars, and team/workspace settings.

Key concepts¶

FastSLA does not replace the source system where issues are managed. It listens to source issue history and maps status movement into SLA meaning:

Start begins SLA tracking.
Pause stops counting SLA time while an issue is waiting.
Stop Response records first response for duration-based policies.
Stop Resolution records resolution for duration-based policies.
Terminal marks the issue as finished.

Deadline-based policies use one deadline target instead of separate response and resolution phases.

For a fuller explanation, read Concepts.

Example setup path¶

Imagine a support team has Jira statuses like this:

New -> Selected for Development -> In Progress -> Waiting for Customer -> Ready for Test -> Done

A common first mapping could be:

Source status	FastSLA meaning
New	Start
In Progress	Stop Response
Waiting for Customer	Pause
Ready for Test	Stop Resolution
Done	Terminal

After import, the team should inspect a few real issues before trusting reports. If an issue starts with Done and no earlier Start was observed, it should be excluded. That is expected: FastSLA only counts issues where it saw a reliable SLA start.

When to use troubleshooting¶

Use Common user problems and Troubleshooting when an issue is missing from reports, appears excluded, imports show unexpected progress, or the lifecycle timeline does not match your expectation.