Skip to content

Getting Started

FastSLA is configured from the tenant workspace. The normal setup path is:

  1. Confirm workspace settings.
  2. Create or select a project.
  3. Connect a source.
  4. Import source history.
  5. Map source statuses.
  6. Configure SLA goals.
  7. Review live issues and reports.

Roles

Some areas are only available to tenant admins.

Role Typical access
Admin Projects, settings, source setup, users, imports, resets, and reports.
Member Operational views such as Overview, Issues, and Reports.

If you cannot see Projects or Settings, your tenant role is probably not Admin.

Workspace timezone

The selected display timezone affects how timestamps are shown in the application. Configure the tenant default timezone in Settings. Users may also have an individual display timezone.

The issue lifecycle timeline, report timestamps, and issue deadline displays should be read in the displayed timezone pill in the top bar.

First project checklist

Before relying on reports, complete this checklist:

  • The project exists and has a webhook secret.
  • A source connection exists and credentials are configured.
  • Connection test succeeds.
  • Initial import has completed.
  • Status mapping covers Start, resolution/end states, and any pause states.
  • SLA goals are configured for the priorities you use.
  • The project health panel says the project can track SLA.
  • A small sample of imported issues looks correct in Issues and Reports.

Safe rollout approach

Start with one project and verify it with real imported data. Do not tune all projects at once.

Use imported issue history to validate whether:

  • issue filters include the correct source issue types and priorities
  • the first reliable Start event is observed
  • terminal statuses are mapped correctly
  • paused time behaves as expected
  • compliance percentages in Reports match your contract interpretation

Example: first validation session

After the first import, pick three issues:

  1. One issue that is still open.
  2. One issue that was resolved successfully.
  3. One issue that should be excluded or is known to have unusual history.

Open each issue from the Issues page and compare the lifecycle timeline with the source system.

Check these questions:

  • Does the graph start when the issue really entered SLA scope?
  • Is first response shown only when response is measured?
  • Does pause time appear where the issue was waiting?
  • Does the target marker match the priority policy?
  • If the issue is deadline-based, does the graph show a single Deadline phase?

If these three issues look right, the configuration is usually ready for a broader review. If they do not, adjust status mapping or filters before relying on reports.

Example: when to use collect-only

Use collect-only when you are unsure which source statuses exist.

Example:

  • A Jira project has custom board columns that are not documented.
  • You create the FastSLA project and let webhooks collect statuses for a few days.
  • FastSLA shows observed statuses in the Status Rules section.
  • You map only the statuses that have a clear SLA meaning.
  • You switch out of collect-only when the project health is acceptable.

Where to go next