# Employees

# Employees

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

Maintain the worker record used for sales, time, payroll, service, approvals, and accountability.

## At a glance

- **Identify it by:** **Employee Code**, **First Name**, and **Last Name**.

- **Check its business context:** **User**, and **Department**.

- **Why care:** These master records supply defaults and choices to later transactions. Correct duplicates and inactive records before staff build more activity on the wrong record.

## Before you begin

You need the Brisk permission for the action you are taking on employees. 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.

<h2 id="bkmrk-create">Create an employee</h2>

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

Create an employee 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: **User**, and **Department**.

2. Enter the required identifying and operational values: **First Name**, **Last Name**, **Address Line 1**, **City**, **State**, and **Zip**, plus the remaining screen fields.

3. Review **Employee Code**, **Initials**, **Address Line 2**, **Secondary Phone**, **Fax**, and **Email**, plus the remaining screen fields against the source document or approved setup decision.

4. Save the employee, then confirm **Employee Code**, **First Name**, and **Last Name** on its detail page before continuing.

After saving: Verify this employee in **Departments**, **Payouts**, **Payroll Profiles**, and **Payroll Run Employees**, plus the remaining screen fields before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-delete">Delete an employee</h2>

Delete this employee 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.

Before confirming, check for related **Departments**, **Payouts**, **Payroll Profiles**, **Payroll Run Employees**, and **Sales**, plus the remaining screen fields. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.

On the confirmation page, verify **Employee Code**, **First Name**, and **Last Name**. After confirmation, return to the Employees list and make sure only the intended employee was removed.

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

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

Use the detail page as the shared record of what this employee currently means. Verify **Employee Code**, **Initials**, **First Name**, and **Last Name** before relying on it for a decision.

Follow **User**, and **Department** to determine whether the issue is on this employee or on one of those linked records.

Next check: Verify this employee in **Departments**, **Payouts**, **Payroll Profiles**, and **Payroll Run Employees**, plus the remaining screen fields 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 employee</h2>

Edit this employee 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 **User**, and **Department** with the supporting document or approved request.

2. Recheck the identifying information shown on the screen. These values are most likely to change future transactions, defaults, assignment, pricing, and reporting.

3. Save the change, return to the list, and confirm that the employee now appears under the expected **Employee Code**, **First Name**, and **Last Name**.

After the change: Verify this employee in **Departments**, **Payouts**, **Payroll Profiles**, and **Payroll Run Employees**, plus the remaining screen fields before staff build new activity on it; correct ownership, classification, and active state now rather than after transactions accumulate.

<h2 id="bkmrk-list">Find and review employees</h2>

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

Use the Employees list to find the correct record before opening or changing it. Compare **Employee Code**, **First Name**, and **Last Name**. Records with similar names or numbers can still belong to different **User**, and **Department**.

- The initial order emphasizes **First Name**, and **Last Name**. Select a column heading when you need a different comparison.

Open the employee whose **Employee Code**, **First Name**, and **Last Name** match the task. If it is missing, clear the list filters and recheck the identifying information shown on the screen rather than creating a replacement immediately.

## Fields and business rules

Brisk stores 17 user-relevant fields for this employee, including 2 linked-record selections and 0 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.

| Field | Required | What it controls |
|---|---:|---|
| **Employee Code** | No | Short code used to identify this employee. |
| **Initials** | No | Unique initials used to identify the employee at transaction entry. |
| **First Name** | Yes | The first name recorded for this employee. |
| **Last Name** | Yes | The last name recorded for this employee. |
| **Address Line 1** | Yes | The address line 1 recorded for this employee. |
| **Address Line 2** | No | The address line 2 recorded for this employee. |
| **City** | Yes | The city recorded for this employee. |
| **State** | Yes | The state recorded for this employee. |
| **Zip** | Yes | The zip recorded for this employee. |
| **Primary Phone** | Yes | The primary phone recorded for this employee. |
| **Secondary Phone** | No | The secondary phone recorded for this employee. |
| **Fax** | No | The fax recorded for this employee. |
| **Email** | No | The email recorded for this employee. |
| **User** | No | The user associated with this employee. |
| **Job Title** | No | The job title recorded for this employee. |
| **Time Clock Pin** | No | Optional PIN for kiosk clock-in/out. |
| **Department** | No | The department associated with this employee. |

## What happens next

Verify this employee in **Departments**, **Payouts**, **Payroll Profiles**, and **Payroll Run Employees**, plus the remaining screen fields 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 **First Name**, **Last Name**, **Address Line 1**, **City**, **State**, and **Zip**, plus the remaining screen fields 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 **User**, and **Department** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.