Case-Based Record Class
The Case-Based Record Class allows you to combine content together associated with a common "case" together into one record. The biggest advantage of using Case-Based Record Classes is so records associated with the case show up for disposition as a single entity, eliminating the need to approve every single file.
A Case-Based Record Class is created by changing the Case Based setting on a Record Class to Yes.
Case File
Case Files can be created manually or automatically (see Case File Rules) and are essentially a special type of child Record Classes. There should be a Case File for each case, which often relates back to business processes such as personnel files, projects, accounts. For example, for each employee of an organization, a Case File could be created.
The Case File is both a Record Class and a Record and contains any number of items. The Case File will be visible primarily in three places; the File Plan, Managing the records on a Record Class, and during disposition.
Case Files themselves cannot contain other Case Files. All Case Files will possess the Lifecycle of the parent Case-Based Record Class and cannot be overridden. All items that are assigned to a Case File will move concurrently through their lifecycle as a single unit, as opposed to a regular Record Class where each item moves independently through its lifecycle.
While Case Files are designed to work as a cohesive unit, moving them through the Lifecycle and the disposition process as a whole, it is possible that the items in the Case File move from phase to phase separately. While it would be unusual, because of the design of the software this is possible. To ensure that all items move together it is important to design a trigger that will work with all the items for a Case File in the same manner.
- Event Triggers - this is the preferred Trigger for working with a Case File. However, if the Event is based on the value of a property and items have different values, the items may not move through the lifecycle together.
- Date Property Triggers - be very careful when using date properties as the triggers as it is likely that none of the items will have consistent dates causing the records to move through the lifecycle separately.
- Rule Triggers - If a Rule Trigger is used, we recommend using a rule that uses a similar rule as the Case File Rule in order to ensure the items move through the lifecycle together.
Case File Rule
When configuring Case-Based Record Classes, it is possible to specify a Case File Rule that enables Case Files to be automatically generated and for items to be automatically assigned to a Case File. If a Case Files Rule is not specified, items will need to be manually assigned to their appropriate Case File and the Case Files themselves will need to be created manually or generated using the API.
A Case File Rule is an expression that will be evaluated against an item’s properties to determine how to assign an item to a Case File and if the Case File does not exist, automatically create it.
To specify a Case File Rule, simply enter a string into the Case File Rules using brackets to specify where the value of an item’s metadata should be substituted. It is possible to use any number of substitution expressions in a single Case File Rule.
Single expression example: “Employee [EmployeeID]”
- Dual expression example: "Employee [firstname].[lastname]”
The output of the Case File Rule evaluation will determine the name of the Case File to be generated and all items that produce the same resulting output will be assigned to the same Case File. In the single expression example above, if the EmployeeID was "1234", then the name of the Case File would be "EmployeeID 1234". In the dual expression example, if the employees name was "John Doe", and both the firstname and lastname where represented properties, then the name of the Case File would be "Employee John.Doe".