Disabled workers

From Cerberus Helpdesk Wiki

An administrator can always delete workers out of the system, but there is a safer alternative found in the disable option. Each workers "edit" window (other than yours) presents you with a 'Disabled' picklist and a 'Delete' button at the bottom. Both methods are designed for marking a worker inactive, but disabling of course will keep them around just in case.

No matter what you decide both options are part of helpdesk setup, Workers

Unlimited Workers (New Licenses)

In the past when you reached your permitted worker cap, you were given two possibilities:

• Delete the worker and free up a license slot,
• or disable them and purchase more workers for you Helpdesk to make room.

Thankfully this tough decision is no longer necessary! In Cerb5, we do not license based on total number of workers, it's based on the number of seats (logged in workers). Because of that fundamental change, every Cerb5 system is technically capable of unlimited workers. Since there is no penalty for creating more as needed, it makes it difficult to endorse deleting a worker in most real-world scenarios.

Disabled

• Login to the Helpdesk is locked until worker is re-enabled.

Your e-mail and password won't work here.

• All existing "Next Worker" assignments (tickets, tasks, ... , opportunities) are kept, but the worker is removed from the assignment dropdown everywhere else. This way no one can assign him more work. i.e. 'John Smith' will still be set as the "Next Worker" for tickets he was already assigned to, however his name will not be available to select from for tickets he is NOT assigned to.
• If the disabled worker was chosen for a 'Worker' custom field, that field will be unset (no selection). Just like Next Worker, 'John Smith' will no longer be a selectable option.

John Smith will be deselected from "Who should handle the next reply?" and 'Worker' custom fields when possible.

• Drafts are saved until you get back. When you return you can continue your progress.

The 'resume' link will be ready for you next time.

• Watcher (E-mail Notifications) and Home Notifications are turned off and they will not receive any notifications. You don't have to disable each one by hand.

Watchers will automatically resume when the Worker is enabled again.

When to use

Traditionally speaking the disable function makes most sense when a worker needs to take a leave of absence, but is expected to come back to work in the future. Workers can be re-enabled later and everything goes back to normal (with the couple of exceptions noted); even things like Workspaces are not purged and will be left as is. Temporarily disabling a worker makes it very easy to pick up where they left off, while at the same time ensuring more work isn't assigned to them while they're away.

• Be careful if a worker is gone for an extended period of time. Tickets and tasks are not released back to the 'Anybody' pool so don't let them go unanswered. It's very easy to forget about timely tickets since they don't appear in the unassigned areas of the 'mail' section (Workflow and Overview's 'Open' sidebar).

Deleted (not recommended)

If you could take a disabled worker and permanently destroy their identity in the system, you'd have a deleted worker.

• Can never log in again.
• Unlike disabled, all "Next Worker" assignments (tickets, tasks, ... , opportunities) are dropped.
• Drafts are kept around and can still be queued up for delivery by an administrator (CHD-1856?)
• Any objects in the Helpdesk that utilize and display the worker id will lose their referential integrity in the interface. You will no longer see their name, and in its place will be a substitute to imply removal. Remember this only affects the owner label and the actual content and date of creation will NOT be purged. (The following examples assume I deleted "John Smith" at john@example.com .)

• Sticky Note -> (Deleted Worker). For whatever reason, Comments are attached to the address id and thus the owner label will not be wiped.
• 

  Remember contact addresses like john@example.com can be replaced with the first and last names in the address book. So if I clicked into the comment address and saved John Smith, that's what would show here instead.

• Audit Log -> (auto). Therefore who made or created a property change on a ticket is lost.
• 

  Notice the Worker Id with the (auto) values and the fact that John Smith became an "Anybody" in one of the "Next Worker" properties.

• Time Tracking -> A worker. The description in the 'Time Tracking' tab of 'activity' is changed to a generic A worker tracked # mins on activity Z.
• 

  The time entries stay but lose their recorder.

• Opportunities, Organizations, Tasks -> anonymous. Here I'm referring to the 'Notes' tab you see when clicking into an Organization or Opportunity.
• 

  See how John Smith was replaced by anonymous in the notes.

• Worker data is removed from reports. You can no longer see his or her statistics in reports like 'Time Spent Per Worker'.
• 

  The John Smith bar graph and description box would be gone!

When to use

Deleting a worker is a good way to clean house in one swoop, but it's obviously much more destructive than the disable option. For the most part the actual content of past messages, comments, tasks, and notes, is kept but the author itself is lost. If you don't care about keeping performance reports and losing track of who wrote what, then deleting a worker may be something to consider. With that said, it's still preferable to disable ALL workers, even those who have no intention of returning (quit, fired, temp). This will keep their history intact as much as possible and be better overall for your records and data integrity.

• A "test" worker is about the only legitimate case for destroying a worker completely.