Configure case types¶

A case type defines how a category of work is handled. It supplies starting defaults and rules for participants, staff parties, workflow families, stages, closing outcomes and supporting documents. For example, a general operational review can require a responsible case owner, a reviewer and a linked record before it can close.

Availability: These instructions describe the intended Case types journey in the inspected Final Screens. The backend supports reading and managing types; the inspected frontend still uses sample data and preview navigation. Connected use, complete failure screens and environment delivery have not been verified. This is a draft guide for review.

Before you start¶

You need permission to view cases to read the available types, and permission to manage cases to create or change them. Protected HR types also require the appropriate HR access: HR viewing or management for reading, and HR management for changes. An administrator title alone does not establish those permissions. Ask your workspace administrator to confirm your access.

Agree the business process before configuring its type. Identify the responsible office and position, who will participate, which staff members the matter concerns, which workflow families are appropriate, and what evidence and outcome are needed to finish. A successful save does not prove that the chosen rules describe a workable process.

Keep these concepts separate:

Find and inspect a type¶

1. Open Cases, then Case types in the intended navigation.
2. Use the name, code or family search and lifecycle-state selection shown in the design. Include inactive types when looking for one that has been retired from new use. These controls still need a connected implementation; preview counts and results are examples.
3. Choose Open on the type you want to inspect.
4. Review its short code, name, family, active state, target duration, confidentiality and file policy. Then read its closure outcomes, participant and staff-party rules, permitted workflow families, stages, transitions and required linked work.
5. Check whether it is marked Protected. Protected describes restrictions on changing the type's rules; Active describes whether it is available for new case creation. They are different properties.

A missing HR type may reflect your access. An inactive type is retained for existing cases and can still be inspected by an authorized reader. Do not interpret the preview's “Archived” label as deletion or as a separate backend lifecycle.

Create a general type¶

1. From Case types, choose New case type.
2. Enter a unique Short code, Display name and a useful description. The code is stored in uppercase and cannot be changed later. An inactive type still reserves its code. Use a code of at most 64 characters, a name of at most 256 and a description of at most 2,000 to fit current storage limits.
3. Choose the category and starting defaults: target duration, owning office, accountable position and confidentiality. Use a positive number of calendar days for the duration, or leave it unset. It is not a business-day calculation or a guarantee that work will finish on time.
4. Choose the file policy described below.
5. Define closure outcomes, participant roles, staff-party roles and permitted workflow families. Include Case owner if you configure a list of allowed participant roles: new cases automatically add that role and cannot be created when the type excludes it.
6. Define the default stages and permitted transitions. The first stage is the normal starting stage; an empty stage list falls back to Intake. Check that each intended route through the process can reach closure.
7. Decide whether a linked record, correspondence or both must be present before closure. These requirements concern supporting work; they do not automatically create it.
8. Review the entire form, then choose Create case type. The inspected design saves directly from this form. A newly created type is active immediately; there is no separate draft or approval stage in the inspected backend.
9. Read the saved type back and confirm its code, active state and complete rules before people use it. Do not treat a preview success page as evidence that a real type was saved.

The current design still needs clearer controls for some policy choices and required values. If the connected form cannot represent the rule you need, stop that configuration and ask the product owner or support team to resolve it. Do not substitute an unrelated role or file policy just to proceed.

Choose the file policy deliberately¶

A dossier is a governed file that groups related records. A Personnel file belongs to the staff context; a case file belongs to the matter. The design's “Personnel file policy” heading does not fully express all four choices. See Create a case for pending outcomes and recovery, and Records for the separate records responsibility.

Understand how the rules behave¶

Default stages do not provide a complete process validator. In particular, creation can accept an explicitly supplied starting stage without checking that it belongs to the configured lanes. Have the process owner check the starting stage, every transition and the path to Closed before adopting a type.

Update an existing type¶

1. Open the type's detail and choose Update case type. For a protected type, the entry is Update allowed details.
2. Confirm the identity of the type. Its short code is fixed even though the inspected general update design shows a short-code field.
3. Change the permitted values and review every rule that should remain. Saving a general type replaces its lists of rules. Check unchanged rules as well as your additions before saving.
4. Choose Save changes, then reopen the detail and compare the saved values with your intended change.
5. Tell the people responsible for affected cases about any rule changes and check that their work can still progress.

Changing defaults does not recalculate existing cases' saved office, position, confidentiality or target date. However, workflow linking, stage decisions and closure consult the type's current rules. A change can therefore affect existing cases' next action. There is no type-version approval or automatic migration of existing cases in the inspected administration flow.

Coordinate edits with other administrators; the current save process has no documented protection against overlapping edits. If the details changed while you were editing, reload and reconcile them before resubmitting.

Protected HR types¶

Zerohive provisions four protected types. Their initial settings are summarized below; the target duration and other allowed defaults may subsequently have been changed in your workspace.

All four initially use restricted confidentiality, require a Case owner participant and permit the Human Resources workflow family. Optional staff parties vary by type. Review the actual saved definition rather than copying sample durations or roles from a design image.

An authorized administrator can update only the display name, description, target duration, default owning office, default accountable position and default confidentiality. Their code, family, lifecycle stages, transition rules, roles, outcomes, workflow families and file/link rules are protected. They cannot be deactivated through the normal administration action. The protected update form and its recovery companions still require final-screen verification; the six-field limit here comes from the implemented rules.

Provisioning adds missing system types and preserves existing system definitions. It does not automatically refresh every saved rule when the software catalog changes. Ask support to investigate a missing or inconsistent protected type rather than creating a custom replacement under its reserved code.

See HR case and query management and employee responses for those journeys. The inspected investigation rules also need reconciliation with ordinary closure: they end at Completed, while that closure path requires a transition to Closed. Do not assume a displayed final stage guarantees that every closing action will succeed.

Make a type inactive or active again¶

For an ordinary active type, open its detail, choose Deactivate, read the confirmation, and select Make inactive. Choose Cancel to leave it unchanged. Inactivation prevents new cases from being created with the type. It retains the definition and existing cases; it does not delete, close or archive those cases.

To return an ordinary inactive type to use, include inactive types when browsing, open it, choose Activate, and confirm Make active. Review its rules before encouraging new use. Reactivation does not reset old cases or restore earlier rule values.

Existing cases still use their saved data and applicable current type rules. Making a type inactive does not by itself prevent an existing case from linking a workflow, recording a stage decision or closing. The other permissions and business rules still apply.

Recover from a problem¶

Give support the workspace, type code, action and approximate time. Keep confidential case contents out of unrestricted support channels. Return to the case overview, case register guide or case creation guide.