Status Mapping and SLA Rules

Status mapping tells SLApulse what each source status does to your SLA.

Keep the first version simple. Map only statuses that clearly affect SLA time. Leave the rest unmapped until you need them.

Workflow meanings

Action	What it does
start	Begins SLA tracking. Issues without an observed start are excluded.
response_received	Records the first response.
pause	Stops SLA time while the issue is waiting.
resolved	Stops the resolution clock.
closed	Marks the issue as closed and also stops the resolution clock.
breach-exempt	Keeps the action above, but excludes a current breach from reporting.

Map each source status to at most one of the first five actions. You may also place the same status in breach-exempt. Source statuses that are not mapped still appear in event history with their original text and do not change SLA state.

A simple example

Source status	SLApulse action
New	start
In Progress	response_received
Waiting for Customer	pause
Ready for Test	resolved
Done	closed

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 mapped to start.

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	Action
Issue enters SLA scope	start
Team starts active work or responds	response_received
Team completes the obligation	resolved
Source issue is closed	closed

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 resolved
• final closure as closed
• waiting states as pause, if the contract allows it

response_received 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