> For the complete documentation index, see [llms.txt](https://teranoapps.gitbook.io/time-tracking-custom-field/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://teranoapps.gitbook.io/time-tracking-custom-field/use-cases-and-best-practices.md).

# Use Cases & Best Practices

This page shows how different teams use Time Tracking Customfield to solve real problems. Each use case includes what you need, how to set it up, and what the result looks like in practice.

{% hint style="info" %}
**Not sure which field type to use?** Time Tracking fields store three values (original estimate, time spent, remaining) and support work logging. Duration fields store a single time value without work logging. See [Two field types, one app](/time-tracking-custom-field/readme.md#two-field-types-one-app) for a detailed comparison.
{% endhint %}

***

## Separate QA time tracking

**Problem:** Your team needs to track QA effort separately from development effort — but Jira only has one built-in Time Tracking field.

**Solution:** Create a dedicated **Time Tracking** field for QA.

{% stepper %}
{% step %}

#### Create the field

Go to **Jira settings → Issues → Custom fields → Create custom field** and select **Time Tracking**. Name it **"QA Estimate"**.
{% endstep %}

{% step %}

#### Add to screens

Add the field to the **Create**, **View/Edit**, and optionally **transition** screens for your projects.
{% endstep %}

{% step %}

#### Use it

QA engineers enter their estimate when work begins (for example `4h`). As they test, they log time against this field. The remaining QA time decreases automatically.
{% endstep %}
{% endstepper %}

**Result:**

{% columns %}
{% column width="50%" %}
**On the issue**

Each issue shows both **Jira Time Tracking** (dev effort) and **QA Estimate** (QA effort) side by side. Teams can see at a glance how much QA time is left.
{% endcolumn %}

{% column width="50%" %}
**In JQL and dashboards**

```jql
"QA Estimate".RemainingEstimateSeconds < 3600
AND status != Done
```

Find issues where QA time is almost used up — and build dashboards around it.
{% endcolumn %}
{% endcolumns %}

{% hint style="success" %}
**Best practice:** Use clear, team-specific names ("QA Estimate", "Dev Estimate") so users immediately know which field to log time against.
{% endhint %}

***

## SLA monitoring with Duration fields

**Problem:** Your support team needs to record an SLA response or resolution time limit on each request — but Jira has no native duration field.

**Solution:** Create a **Duration** field to store the SLA threshold.

{% stepper %}
{% step %}

#### Create the field

Go to **Jira settings → Issues → Custom fields → Create custom field** and select **Duration**. Name it **"SLA Limit"**.
{% endstep %}

{% step %}

#### Configure time units

Open the field's configuration and set **hours per day** and **days per week** to match your support team's working hours (for example 8h/day, 5d/week).
{% endstep %}

{% step %}

#### Add to screens and portals

Add the field to your service project's **request form** and **issue view** screens.
{% endstep %}

{% step %}

#### Set values per request type

When creating or triaging requests, set the SLA limit (for example `4h` for high priority, `2d` for low priority).
{% endstep %}
{% endstepper %}

**Result:**

{% columns %}
{% column width="50%" %}
**On the issue**

Each request shows its SLA limit as a clear, formatted duration (for example **4h** or **2d**).
{% endcolumn %}

{% column width="50%" %}
**In automation**

```jql
"SLA Limit".DurationSeconds > 28800
AND priority = High
```

Trigger alerts when high-priority tickets have SLA limits above 8 hours — a sign that something may need re-prioritisation.
{% endcolumn %}
{% endcolumns %}

{% hint style="info" %}
**Duration vs Time Tracking for SLAs:** If you only need to *record* the SLA threshold, use a Duration field. If you also want to *log work against the SLA* and track how much time is left, use a Time Tracking field instead.
{% endhint %}

***

## Contract hour tracking

**Problem:** You sell services by the hour and need to track how much of a client's contracted budget has been used — without mixing it into the team's regular time tracking.

**Solution:** Create a **Time Tracking** field for contract hours, optionally with a workflow validator.

{% stepper %}
{% step %}

#### Create the field

Create a Time Tracking field called **"Contract Hours"** and add it to your project screens.
{% endstep %}

{% step %}

#### Set the budget per issue

When a new task for the client comes in, set the original estimate to the allocated budget (for example `8h` or `2d`).
{% endstep %}

{% step %}

#### Log work against the contract

As team members work on client tasks, they log time against **Contract Hours**. Remaining time decreases automatically.
{% endstep %}

{% step %}

#### Add a workflow validator (optional)

Add the **Require time to be logged** validator to the **Done** transition so issues cannot be closed without logging at least some contract time.
{% endstep %}
{% endstepper %}

**Result:**

{% columns %}
{% column width="50%" %}
**On the issue**

The **Contract Hours** field shows original budget, time used, and remaining — separate from dev or QA effort.
{% endcolumn %}

{% column width="50%" %}
**In reports and exports**

```jql
project = CLIENT-A
AND "Contract Hours".TimeSpentSeconds > 0
```

Export all issues with logged contract time. Use `TimeSpentSeconds` in CSV exports for billing calculations.
{% endcolumn %}
{% endcolumns %}

{% hint style="warning" %}
**Watch out:** Make sure your team knows the difference between logging time on **Contract Hours** vs **Jira Time Tracking**. Clear field names and a short team briefing prevent confusion.
{% endhint %}

***

## Multi-team estimation with native Time Tracking sync

**Problem:** Dev, QA, and DevOps each need their own estimates, but your PM still relies on Jira's built-in Time Tracking for total effort on dashboards and reports.

**Solution:** Create multiple Time Tracking fields and sync them to native Time Tracking using a **bucket set**.

{% stepper %}
{% step %}

#### Create the fields

Create three Time Tracking fields: **"Dev Estimate"**, **"QA Estimate"**, **"DevOps Estimate"**. Add them to your project screens.
{% endstep %}

{% step %}

#### Configure a bucket set

Open **Project settings → Time Tracking Custom Field** and create a new bucket set. Add all three fields to the set.
{% endstep %}

{% step %}

#### Teams work independently

Each team sets their own estimate and logs work against their own field. Dev logs to Dev Estimate, QA logs to QA Estimate, and so on.
{% endstep %}

{% step %}

#### PM sees the total

Jira's native **Time Tracking** automatically shows the combined remaining and time spent across all three fields. Existing dashboards and reports continue to work without changes.
{% endstep %}
{% endstepper %}

**Result:**

{% columns %}
{% column width="50%" %}
**For teams**

Each team has a dedicated time bucket. They see only what's relevant to them and don't interfere with each other's estimates.
{% endcolumn %}

{% column width="50%" %}
**For project managers**

Native Time Tracking aggregates everything. Existing Jira reports, gadgets, and automation rules that rely on Time Tracking continue to function as before.
{% endcolumn %}
{% endcolumns %}

{% hint style="success" %}
**Best practice:** Use bucket sets when you need both granular per-team tracking *and* a combined total. If you only need separate fields without aggregation, skip the bucket set — the fields work independently by default.
{% endhint %}

***

## Time-based workflow gates

**Problem:** Issues are being moved to "Done" without any work logged, making time reports unreliable.

**Solution:** Add a **Require time to be logged** workflow validator to enforce a minimum before closing.

{% stepper %}
{% step %}

#### Open the workflow editor

Open the workflow for your project and select the **In Progress → Done** transition.
{% endstep %}

{% step %}

#### Add the validator

Choose **Require time to be logged** and set the minimum to **`30m`**.
{% endstep %}

{% step %}

#### Publish the workflow

Save and publish. From now on, any attempt to move an issue to Done without at least 30 minutes logged will be blocked with a clear error message.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
You can set **different thresholds** for different transitions. For example, `15m` to leave "To Do" (ensures someone acknowledged the task) and `2h` to reach "Done" (ensures real work was logged).
{% endhint %}

***

## Best practices summary

{% tabs %}
{% tab title="Naming" %}
**Use clear, team-specific names** so users immediately know which field to use:

* **"Dev Estimate"** — not "Time Tracking 1"
* **"QA Estimate"** — not "Custom Time Field"
* **"SLA Limit"** — not "Duration"
* **"Contract Hours"** — not "Extra Time"

A good field name is self-documenting. If you need to explain what a field is for, the name is too vague.
{% endtab %}

{% tab title="Field type choice" %}
**Pick the right type for the job:**

| Need                                                 | Use               |
| ---------------------------------------------------- | ----------------- |
| Track effort with original / spent / remaining       | **Time Tracking** |
| Store a single time value (threshold, limit, budget) | **Duration**      |
| Log work over time and see remaining decrease        | **Time Tracking** |
| Record a one-time duration without work logging      | **Duration**      |
| {% endtab %}                                         |                   |

{% tab title="Rollout" %}
**Start small and expand:**

1. Begin with **one project and one field** to validate the setup.
2. Show a quick demo to your team — most users understand it in under a minute because it mirrors Jira's built-in Time Tracking.
3. Add more fields and projects only when the first one works well.
4. Use **bucket sets** only if you need aggregation into native Time Tracking.
   {% endtab %}

{% tab title="Reporting" %}
**Use seconds aliases for reliable data:**

* Always use `*Seconds` aliases (`RemainingEstimateSeconds`, `DurationSeconds`) in JQL, automation, and exports.
* Use the string aliases (`RemainingEstimate`, `Duration`) only for display or text matching.
* In CSV exports, treat the seconds values as your primary metrics for charts and calculations.
  {% endtab %}
  {% endtabs %}

***

## See also

{% content-ref url="/pages/6w425lHclRfD32iGma1n" %}
[Configuration](/time-tracking-custom-field/configuration.md)
{% endcontent-ref %}

{% content-ref url="/pages/6LJ2VJ6MbD6ZkDsaDwqS" %}
[Use Time Tracking fields](/time-tracking-custom-field/user-guide/use-time-tracking-fields.md)
{% endcontent-ref %}

{% content-ref url="/pages/9LfENLgpBBif5Na29Onv" %}
[Use Duration fields](/time-tracking-custom-field/user-guide/use-duration-fields.md)
{% endcontent-ref %}

{% content-ref url="/pages/iTN2uwuLQOAEvgN8H4xq" %}
[Search & Reporting](/time-tracking-custom-field/search-and-reporting.md)
{% endcontent-ref %}