Status Mapping and SLA Rules¶
FastSLA converts source statuses into SLA meaning. This mapping is the most important configuration step.
Workflow meanings¶
| Meaning | What it does |
|---|---|
Start |
Begins SLA tracking. Issues without an observed Start are excluded. |
Pause |
Stops SLA time while the issue is waiting. |
Stop Response |
Records first response for duration policies. |
Stop Resolution |
Records resolution for duration policies. |
Terminal |
Marks the issue as finished. |
Example mappings¶
Response and resolution policy¶
Use this when the contract measures both first response and resolution.
| Source status | Meaning | Why |
|---|---|---|
| Backlog | Start | The issue has entered SLA scope. |
| Implementation active | Stop Response | A person has started active work. |
| Waiting for customer | Pause | The team is blocked by an external party. |
| Ready for test | Stop Resolution | The team has completed the resolution obligation. |
| Closed | Terminal | The issue is finished and should not need operational attention. |
Deadline policy¶
Use this when the contract only measures a final completion deadline.
| Source status | Meaning | Why |
|---|---|---|
| Backlog | Start | The deadline starts when the issue enters scope. |
| Waiting for customer | Pause | Optional, if waiting time should not count. |
| Ready for test | Stop Resolution | The obligation is complete. |
| Closed | Terminal | The issue is finished. |
In deadline mode, Stop Response is not shown as a measured phase on the lifecycle graph. If a source response-like event exists, it can still appear as a dimmed no-effect marker.
Start is required¶
FastSLA requires an observed source status mapped to Start.
A technical snapshot or created event is not enough unless the status in that event maps to Start. If the earliest observed status is already closed, terminal, paused, or resolved, the issue is excluded until a real Start event is observed.
Excluded issues do not count in SLA reports.
Example: missing Start¶
This history should be excluded:
Portfolio.closed
Kanban.implement.done
Customer.readyForTest
Portfolio.closed
None of those source statuses maps to Start. Even if the issue has many later events, FastSLA cannot prove when SLA tracking should have begun.
This history can count:
Kanban.backlog -> Start
Kanban.implement.active -> Stop Response
Customer.readyForTest -> Stop Resolution
Portfolio.closed -> Terminal
FastSLA observed a real Start event, so the issue can be included.
No-effect statuses¶
Source history may contain statuses that are not mapped to an SLA meaning. They are still visible in event history and on the lifecycle timeline, but they do not change SLA state.
On the lifecycle graph, no-effect status markers are dimmed so you can distinguish them from meaningful SLA transitions.
Example: no-effect statuses¶
If your workflow has Code review, QA active, and QA done, you may not need all of them to affect SLA.
You might map:
| Source status | Meaning |
|---|---|
| In Progress | Stop Response |
| Ready for Test | Stop Resolution |
| Closed | Terminal |
Then Code review and QA active can remain no-effect statuses. They still appear in event history, but they do not change response/resolution timing.
Issue filter¶
The issue filter controls which source issues are eligible for SLA tracking.
Use it to include only the issue types or priorities that belong in the SLA contract. The filter applies to reports and operational lists based on current project configuration.
Example: exclude internal tasks¶
If the source project contains both customer issues and internal engineering tasks, configure the issue filter to include only customer-facing issue types.
Example:
| Filter field | Include |
|---|---|
| Raw issue type | Incident, Bug, Service Request |
| Priority | P1, P2, P3 |
After changing the filter, Reports should reflect the new eligible set. Existing imported issues do not have to be deleted for the filter to affect reporting, but you may need reset/reimport if you want runtime issue state rebuilt under new assumptions.
SLA goal modes¶
FastSLA supports two measurement styles:
| Mode | Use it when |
|---|---|
| Response + resolution | The contract measures first response and final resolution separately. |
| Deadline | The contract measures one deadline for completion/resolution. |
Deadline-mode timelines show a single deadline phase. Response markers are not emphasized because response is not measured.
Business hours¶
SLA rules can run continuously or inside configured business hours.
Business-hours calculations use the project calendar and holiday calendar where configured. Warning notifications for business-hours SLAs are scheduled and sent during open business time.
Example: business-hours warning¶
If a P2 issue starts Friday at 15:30 and the project only counts Monday-Friday 08:00-17:00, the warning should not be sent during the weekend. FastSLA schedules and sends business-hours warning notifications during open time.
Continuous SLAs do not wait for business hours.
Breach-exempt statuses¶
Some workflow statuses may exempt an issue from breach processing. Use this carefully. Breach-exempt statuses should represent real business states where SLA breach should not apply.
Go-live checks¶
Before relying on a project:
- At least one Start status is mapped.
- Resolution or terminal statuses are mapped.
- Pause statuses are mapped if the workflow has waiting states.
- A sample of imported issues has the expected lifecycle.
- Reports exclude issues with missing Start.
- Deadline-mode priorities do not show response phases in the lifecycle graph.