Skip to content

Validate Your Setup

Use this guide before relying on FastSLA reports for contract follow-up.

The goal is not to import everything immediately. The goal is to prove that mapping, filters, calendars, and reports behave correctly on real issues you understand.

Validation flow

  1. Create or select one project.
  2. Connect the source and test the connection.
  3. Import a limited date window.
  4. Map observed source statuses to SLA meanings.
  5. Configure SLA goals and calendars.
  6. Review a small sample of issues.
  7. Check the report result for the same period.
  8. Adjust mapping or filters before importing a larger window.

Choose a small first import

Start with enough history to include complete issue lifecycles, but not more than you need.

Goal Suggested window
Validate mapping 30 to 90 days
Validate a known report period The report period plus enough earlier history to include Start events
Rebuild after reset The same period you want to review

If the window starts after an issue's real Start, FastSLA may exclude that issue because it did not observe a reliable SLA start.

Pick known sample issues

After import, choose examples that represent the real workflow:

Sample Why it matters
One open running issue Confirms targets, current phase, and Now marker.
One resolved met issue Confirms successful completion and report inclusion.
One breached issue Confirms missed targets and explanation details.
One paused issue Confirms waiting time behaves as expected.
One excluded issue Confirms missing Start or filter behavior is understood.

Check each sample issue

Open the issue detail and compare FastSLA with the source system.

Check:

  • the lifecycle timeline starts at the first real Start
  • response labels only appear when response is measured
  • deadline-mode issues show one Deadline phase
  • pause periods match waiting states
  • terminal status ends the active lifecycle
  • target markers match the configured priority SLA
  • no-effect statuses are dimmed and do not change the SLA phase

Validate issue filters

Issue filters decide which source issues are eligible.

Check that the project includes the issue types, priorities, or other source attributes that belong in the SLA contract.

Example:

Source issue Should count? Filter expectation
Customer incident, P1 Yes Included
Internal maintenance task No Excluded
Customer request with unsupported priority Depends on contract Confirm policy

If filters are wrong, reports can look correct mathematically while measuring the wrong issue population.

Validate status mapping

The most important mapping is Start.

FastSLA should not count an issue just because it exists. It should count the issue when it observes the source status that means SLA tracking begins.

Check:

  • every real entry point into SLA scope maps to Start
  • closed or done statuses map to Terminal
  • waiting states map to Pause only when SLA time should stop
  • response and resolution stop statuses match the contract wording
  • internal workflow statuses are left as no-effect when they do not matter

Validate reports

Create a report for the same period you imported.

Check:

  • Total eligible issues matches your expected population
  • met percentages are based on completed measurements only
  • running and paused measurements are shown as unresolved excluded
  • breached issues can be opened and explained
  • terminal issues can appear in reports even when they no longer appear on Overview

Example validation

A team imports the last 60 days and reviews five known issues.

They find that two resolved issues are excluded. In both cases, the first imported status is Ready for Test, because the import window did not include the earlier New status that maps to Start.

The fix is not to mark Ready for Test as Start. That would make the SLA start too late. The better fix is to import an earlier date window that includes the real start of those issues.

When to reset and reimport

Use Reset project data when the imported runtime data was built with wrong assumptions and you want to rebuild from source history.

Typical reasons:

  • status mapping was wrong during the first import
  • the import window was too narrow
  • source filters were corrected after import
  • you want a clean validation pass before go-live

Do not reset as a normal sync method. For ordinary follow-up, use reconcile or live source updates.