Status Mapping and SLA Rules¶
Status mapping tells SLApulse what your source workflow means for SLA.
Keep the first version simple. Map only the statuses that clearly start, pause, or stop SLA time. Leave the rest as no-effect statuses until you need them.
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 response/resolution policies. |
Stop Resolution |
Records resolution or completion. |
Terminal |
Marks the issue as finished. |
Source statuses that are not mapped still appear in event history. They do not change SLA state.
A simple example¶
| Source status | SLApulse meaning |
|---|---|
| New | Start |
| In Progress | Stop Response |
| Waiting for Customer | Pause |
| Ready for Test | Stop Resolution |
| Done | Terminal |
This is enough for many teams. You can add more detail later if the reports need it.
Start is required¶
Start is the most important mapping.
SLApulse does not count an issue just because it exists. It counts the issue when it sees a source status that means SLA tracking has begun.
Check that every real entry point into SLA scope maps to Start.
Example:
New -> In Progress -> Waiting for Customer -> Done
If New maps to Start, the issue can count. If the first imported status is already Done, SLApulse cannot know when SLA started, so the issue is excluded.
Pause statuses¶
Map a status to Pause only when SLA time should stop.
Good examples:
- Waiting for Customer
- Waiting for Vendor
- Blocked by External Team
Avoid using Pause for normal internal work. Too many pause statuses can make reports look better than the real contract allows.
Response and resolution¶
Use response/resolution mode when the contract measures first response and final resolution separately.
Typical mapping:
| Contract moment | Mapping |
|---|---|
| Issue enters SLA scope | Start |
| Team starts active work or responds | Stop Response |
| Team completes the obligation | Stop Resolution |
| Source issue is closed | Terminal |
Deadline mode¶
Use deadline mode when the contract only has one completion target.
In deadline mode, the lifecycle shows one deadline phase. You usually map:
- entry into scope as
Start - completion as
Stop Resolution - final closure as
Terminal - waiting states as
Pause, if the contract allows it
Stop Response is not a measured phase in deadline mode.
Default and project-specific rules¶
Most teams should start with tenant default rules.
Use a project-specific override only when one project really has different:
- priorities
- target times
- business hours
- holiday calendar
- workflow meanings
If a project follows the normal contract, keep it on the default rules. This makes setup easier to maintain.
Business hours¶
SLA rules can count continuously or only during business hours.
Business-hours policies use the project calendar and holiday calendar. Continuous policies count evenings, weekends, and holidays.
Example:
If a P2 issue starts Friday at 15:30 and the project only counts Monday-Friday 08:00-17:00, the target may move into the next workday.
Issue filters¶
Issue filters decide which source issues belong in SLA.
Use filters when the source project contains mixed work, such as customer incidents and internal tasks.
Example:
| Source field | Include |
|---|---|
| Issue type | Incident, Bug, Service Request |
| Priority | P1, P2, P3 |
If filters are wrong, reports can measure the wrong issue population even when the SLA math is correct.
Go-live checks¶
Before relying on a project, check:
- at least one real Start status is mapped
- done/closed statuses are mapped
- waiting statuses are paused only when the contract allows it
- a few imported issues have the expected lifecycle
- reports exclude issues with missing Start
- Command Center shows the project as ready or live
- Operations shows the kind of risk your team expects