Brief description of what this article covers.

Step-by-Step Instructions

1. First step

1. Second step

Additional Notes

Any additional information or tips.

Manually Removing a Samsara User

When an employee departs, the departed-user automation tries to deactivate their Samsara driver record for them. If it can't find the driver, it can't deactivate it, so it raises a ticket asking someone to finish the job by hand.

This article covers that follow-up: confirm whether the driver still exists in Samsara, deactivate them if so, then set the SamsaraRemoved flag in the database so the departure record is complete.

> Most of the time there is nothing to deactivate. The driver is usually absent because they were never entered into Samsara in the first place, or because someone already removed them manually. That is a normal outcome — you still need to do Step 3.

Prerequisites

• A Samsara admin account with SSO access to the McKim & Creed org
• SQL access to HDCDBS04 → database McKimCreedEntities (write access to ITEvents.DepartedUsers)
• The departing employee's name from the ticket

---

Step 1: Pick up the ticket

The process starts with an automated ticket from IT Process Notifications, subject [ERROR] Error Deactivating Driver in Samsara.

The body names the employee, for example:

> Error Deactivating Akiva Williams in Samsara. User not found.

>

> Could not find Akiva Williams in the Samsara System. Please check Samsara and deactivate manually.

>

> Update Departed User table in McKimCreedEntities and set the SamsaraRemoved flag to 0 for Akiva Williams.

> [!warning] The email says "set the SamsaraRemoved flag to 0" — that is wrong. Set it to 1.

> In ITEvents.DepartedUsers, SamsaraRemoved = 1 means "this person has been dealt with in Samsara". Setting it to 0 would leave the record looking unfinished. Follow Step 3 below, not the wording in the email.

Note the employee's full name — you'll search Samsara by their last name.

Step 2: Check Samsara and deactivate if present

1. Go to the Samsara drivers list — cloud.samsara.com/o/5005417/fleet/drivers

• This should sign you straight in via SSO if you have an admin account.

1. Make sure you're on the Active Drivers tab.
2. In the search box at the top right, type the employee's last name.
3. Look through the results for the person named in the ticket.

If you find them:

1. Click the ... menu at the right-hand end of their row.
2. Choose Deactivate.

Deactivating moves them off Active Drivers and onto the Deactivated Drivers tab — it does not delete their historical driving data.

If you don't find them:

Nothing to do here — they were never in Samsara, or they've already been removed. Move straight on to Step 3.

> Search by last name only. Searching a full name or a preferred/nickname can miss the record — the ticket may say "Akiva Williams" while Samsara lists the username as AWilliams. Watch out for common surnames: a search for williams returns many drivers, so match on the Employeecode column where you can.

Step 3: Set the flag in the database

Either way — whether you deactivated someone or found nobody — the departure record still needs closing out.

• Server: HDCDBS04
• Database: McKimCreedEntities
• Table: ITEvents.DepartedUsers

1. Find the row. This lists the most recent departures, newest first:

SELECT *
FROM ITEvents.DepartedUsers
ORDER BY DepartedUserDate DESC;

To narrow it to just the people still awaiting Samsara removal:

SELECT id, Username, Fullname, EmployeeCode, DepartedUserDate, SamsaraRemoved
FROM ITEvents.DepartedUsers
WHERE SamsaraRemoved = 0 OR SamsaraRemoved IS NULL
ORDER BY DepartedUserDate DESC;

SamsaraRemoved is nullable, so test for IS NULL as well as = 0 — filtering on = 0 alone can hide rows that were never set.

2. Confirm you have the right person by matching Fullname and EmployeeCode against the ticket. Note their id.

3. Update the row, substituting the id you just found:

UPDATE ITEvents.DepartedUsers
SET SamsaraRemoved = 1
WHERE id = {id};

> [!tip] Always update by id, never by name.

> Fullname isn't unique — the same person can appear more than once if they were rehired, and surnames repeat. id is the primary key.

4. Verify the change took:

SELECT id, Fullname, EmployeeCode, DepartedUserDate, SamsaraRemoved
FROM ITEvents.DepartedUsers
WHERE id = {id};

You should see SamsaraRemoved = 1.

Done

Close the Zendesk ticket. If you deactivated a driver, say so in the resolution; if the driver wasn't in Samsara at all, note that too — it's useful signal about whether field staff are being entered into Samsara in the first place.

---

Notes

• Deactivate, don't delete. Samsara keeps the driver's history under Deactivated Drivers. Deleting a driver would take their trip and HOS records with them.
• Why the automation fails. The automated step matches on the Samsara driver record. If the employee was never added to Samsara — common for office staff and anyone who never drove a company vehicle — there is nothing to match, so it errors out and hands off to this manual process. An error ticket does not mean something is broken.
• This is one of several departure flags. ITEvents.DepartedUsers tracks each departure step separately, including SiteDocsRemoved, UserDirectoryRemoved, LicensesRemoved, and ProjectManagementRemoval. Setting SamsaraRemoved only clears the Samsara step — check whether the ticket is asking for anything else before you close it.