RocketChat/Rocket.Chat · error · Meteor.Error
error-archived-department-cant-be-enabled
error-archived-department-cant-be-enabled
Error message
Archived departments cant be enabled
What it means
Thrown by `livechat:saveDepartment` when the department record being updated has `archived: true` but the incoming `departmentData.enabled` is truthy. Archived departments are frozen; Rocket.Chat refuses to flip `enabled` on them in the same save, forcing an explicit unarchive step first.
Source
Thrown at apps/meteor/server/lib/omnichannel/departmentsLib.ts:58
: null;
if (departmentUnit && !departmentUnit._id && department && department.parentId) {
const isLastDepartmentInUnit = (await LivechatDepartment.countDepartmentsInUnit(department.parentId)) === 1;
if (isLastDepartmentInUnit) {
throw new Meteor.Error('error-unit-cant-be-empty', "The last department in a unit can't be removed", {
method: 'livechat:saveDepartment',
});
}
}
if (!department && !(await isDepartmentCreationAvailable())) {
throw new Meteor.Error('error-max-departments-number-reached', 'Maximum number of departments reached', {
method: 'livechat:saveDepartment',
});
}
if (department?.archived && departmentData.enabled) {
throw new Meteor.Error('error-archived-department-cant-be-enabled', 'Archived departments cant be enabled', {
method: 'livechat:saveDepartment',
});
}
// TODO: Use AJV or Zod for validation (or the lib we are using rn)
const defaultValidations: Record<string, Match.Matcher<any> | BooleanConstructor | StringConstructor> = {
enabled: Boolean,
name: String,
description: Match.Optional(String),
showOnRegistration: Boolean,
email: String,
showOnOfflineForm: Boolean,
requestTagBeforeClosingChat: Match.Optional(Boolean),
chatClosingTags: Match.Optional([String]),
fallbackForwardDepartment: Match.Optional(String),
departmentsAllowedToForward: Match.Optional([String]),
allowReceiveForwardOffline: Match.Optional(Boolean),
};View on GitHub (pinned to b2c16d5842)
Solutions
- Unarchive first via `unarchiveDepartment(_id)` (the lib exported at departmentsLib.ts:165), then save with `enabled: true`
- If the department should stay archived, do not send `enabled: true` in the update payload
- If the intent is a brand-new active department, create a new one instead of reviving the archived record (mind error 900's quota)
Example fix
// before
await saveDepartment(depId, { ...deptData, enabled: true }); // dep is archived
// after
if (department.archived) {
await unarchiveDepartment(depId);
}
await saveDepartment(depId, { ...deptData, enabled: true }); Defensive patterns
Strategy: validation
Validate before calling
const dep = await LivechatDepartment.findOneById(_id, { projection: { archived: 1 } });
if (dep?.archived && deptData.enabled) {
await unarchiveDepartment(_id); // unarchive first, then enable
}
await saveDepartment(_id, deptData); Type guard
const isArchivedDepartment = (d: { archived?: boolean } | null): d is { archived: true } =>
d?.archived === true; Try / catch
try {
await saveDepartment(_id, deptData);
} catch (e) {
if (isMeteorError(e, 'error-archived-department-cant-be-enabled')) {
await unarchiveDepartment(_id);
await saveDepartment(_id, deptData);
}
} Prevention
- Show an 'Archived' badge in edit forms and block the enabled toggle until unarchived
- Make unarchive an explicit, separate user action
- Never blindly upsert full department payloads that include enabled:true
When it happens
Trigger: Updating a previously archived department (one whose document has `archived: true`) through `livechat:saveDepartment` with `enabled: true` in the payload — e.g. reactivating an old department straight from an 'edit department' form that always sends the enabled checkbox.
Common situations: Admin archives a department for decommissioning, later tries to bring it back by just toggling 'Enabled' in the edit screen; automation scripts that upsert departments with a full payload including enabled:true; stale UI state that does not surface the archived flag.
Understand the failure class
Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.
Related errors
- error-forwarding-department-target-not-allowed
- error-invalid-department-unit
- error-unit-cant-be-empty
- error-max-departments-number-reached
- error-validating-department-chat-closing-tags
AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18).
Data as JSON: /api/errors/c6aafe4331eadb17.
Report an issue: GitHub.