# Service Leave

# Service Leave

<h2 id="bkmrk-overview">Purpose and when to use this record</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelserviceserviceleave-overview-service-leave.png" alt="Brisk Service Leave overview screen displayed with fictional documentation-demo data." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The Service Leave overview screen in the Brisk documentation demo.</figcaption></figure>

Block a technician’s dispatch availability for PTO, illness, training, meetings, or another approved absence.

## At a glance

- **Identify it by:** **Technician**, **Leave Type**, **Start**, and **End**.

- **Check its business context:** **Technician**.

- **Why care:** Customer, equipment, scope, priority, technician availability, parts, labor, and status must stay aligned from intake through billing.

## Before you begin

You need the Brisk permission for the action you are taking on service leave. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.

Have valid **Technician** records ready first. Those selections determine where this Service Leave belongs and which later screens can find it.

<h2 id="bkmrk-create">Create a Service Leave</h2>

<figure class="brisk-doc-media"><img src="https://help.brisksystems.us/uploads/images/gallery/2026-08/article-modelserviceserviceleave-create-service-leave-create.png" alt="Brisk Service Leave create screen displayed with fictional documentation-demo data." loading="lazy" style="max-width:100%;height:auto;"><figcaption>The Service Leave create screen in the Brisk documentation demo.</figcaption></figure>

Create a Service Leave after searching for the person, organization, item, location, or resource under alternate names and identifiers. Merge or correct an existing master record instead of creating a duplicate.

1. Select the business context first: **Technician**.

2. Enter the required identifying and operational values: **Technician**, **Start**, and **End**.

3. Review **Leave Type**, and **Approved** deliberately; these choices control availability or workflow rather than merely describing the record.

4. Save the Service Leave, then confirm **Technician**, **Leave Type**, **Start**, **End**, **Approved**, and **Notes** on its detail page before continuing.

After saving: Verify this Service Leave in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-delete">Delete a Service Leave</h2>

Delete this Service Leave only if it is an unused duplicate or setup mistake. Once other records refer to it, preserve that history and make the value inactive when the screen provides that option.

On the confirmation page, verify **Technician**, **Leave Type**, **Start**, and **End**. After confirmation, return to the Service Leave list and make sure only the intended Service Leave was removed.

<h2 id="bkmrk-detail">Review Service Leave details</h2>

Use the detail page as the shared record of what this Service Leave currently means. Verify **Leave Type** before relying on it for a decision.

Follow **Technician** to determine whether the issue is on this Service Leave or on one of those linked records.

Next check: Verify this Service Leave in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-update">Edit an existing Service Leave</h2>

Edit this Service Leave to keep the same real-world party, item, location, or resource accurate. Do not repurpose it for a different entity after activity is attached.

1. Open the detail page. Compare **Technician** with the supporting document or approved request.

2. Recheck **Leave Type**. These values are most likely to change intake, estimating, dispatch, parts, labor, completion, and billing.

3. Save the change, return to the list, and confirm that the Service Leave now appears under the expected **Leave Type**, and **Approved**.

After the change: Verify this Service Leave in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

## Fields and business rules

Brisk stores 6 user-relevant fields for this Service Leave, including 1 linked-record selection and 1 controlled-choice field. Create and edit screens may hide calculated or workflow-managed values from this full reference.

| Field | Required | What it controls |
|---|---:|---|
| **Technician** | Yes | The technician associated with this service leave. |
| **Leave Type** | No | The leave type recorded for this service leave. Available values: PTO, Sick, Training, Meeting, Other. |
| **Start** | Yes | Date and time recorded for start on this service leave. |
| **End** | Yes | Date and time recorded for end on this service leave. |
| **Approved** | No | Whether the approved option applies to this service leave. |
| **Notes** | No | Additional internal notes about this service leave. |

## What happens next

Verify this Service Leave in the next transaction or assignment screen before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

## Common mistakes and troubleshooting

- **The record will not save:** Recheck **Technician**, **Start**, and **End** and any message beside the field. A required related record may also be inactive or unavailable to your role.

- **The values look right but the result is wrong:** Open **Technician** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.