This document is no longer current. Please go to the 
following URL for more information:  
 
http://www.nationalarchives.gov.uk/electronicrecords/reqs2002/default.htm 

## B.4  :   Case Management And Workflow

This module has been developed with contributions from Cornwell Management Consultants plc1 and consultation with central and local government representatives.  It is not intended to form a part of any future generic functional requirements testing by TNA. 

 
This section lists requirements for an ERMS which handles casework, or case folders.  The requirements it contains are relevant *only* where casework and/or workflow are business needs; in other situations they can be ignored.  They include only requirements related to the records management functionality of a case management system; they are unlikely to suffice for the specification of a complete case management application. 

Case Management This section explains the use of the term "case management" and "case folder" in this module.  There is no universally-accepted definition of these terms, nor of the distinction between case folders and the other kinds of folders often managed by an ERMS.  The following is therefore developed for, and intended to facilitate the understanding of, this module; its applicability in other situations is not guaranteed. The term "case folder" is here taken to mean the set of records relating to one or more transactions performed in a structured or partly-structured way.  The records themselves may be structured (e.g. completed online forms) or unstructured (e.g. e-mail messages or scanned images of paper forms), in any combination; but the key distinguishing characteristic of case folders, compared to the "policy2" folders dealt with elsewhere in this specification, is that they result from processes which are at least partly structured. 

In the language of the eGovernment Unit's e-Services Development Framework3, case folders are sets of records which pertain to either a specific occurrence of a service interaction, or a series of service interactions that concern a single person, company or other subject entity, where the service interaction(s) is/are the subject of procedural rules4. Examples include case folders containing records pertaining to: 

" applications for permits, licences, benefits, passes, funding etc. 
" FOI enquiries 
" investigation of an incident " regulatory monitoring 
" particular instance papers5 
" other transactions directly supported by a pre-programmed workflow (i.e. not an 
ad hoc workflow created for use once). 
 
Typically, case folders contain predictable content, albeit with numerous variations.  For example, a Benefit Application case folder might always contain a completed application form, then either a request for clarification or an approval record, and so on.  They normally rely on business rules (implicit or explicit) which state that specified documents must automatically be considered as records.  By contrast, the content of policy folders is unpredictable, and is determined solely by the users who declare the records. Typically, though not necessarily, other characteristics of case folders are that: 

" they are numerous " they are structured or partly structured " they are used and managed within a known and predetermined process " they need to be retained for specific periods, as a result of legislation or 
regulation 
" they can be opened and (in many cases) closed by practitioners, clerical staff or 
data processing systems without the need for management approval. 
Case management frequently involves an application system which is external to the ERMS 
(a 'line of business' system), for example: 

" a benefit application processing system " an FOI enquiry tracking system " an order processing system.   
Many of the additional requirements for case management are related to the need for an ERMS to integrate closely with such systems. 

Workflow Case management generally implies following a well-structured process.  This in turn often means that it will be beneficial to apply workflow technology.  Workflow is defined by the Workflow Management Coalition as The automation of a business process, in whole or in part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.6  In this definition, a "participant" can be a user, a work group (a team), or an application system. The Workflow requirements as described here relate only to the definition of a standardised business process external to the ERMS.  Consequently, processes defined for delivering ERMS functionality will not generally satisfy these requirements. 

Organisation and Use of this Section The requirements in the remainder of this section are organised under headings which reflect the headings of the *core requirements* specification.  Where a heading from the body is not shown below, no requirements specific to case management have been identified.  Further headings specific to case management and workflow have been added. The requirements for case management and workflow require careful tailoring.  Perhaps more than most of the requirements elsewhere, they can vary according to the nature of the transactions and the supporting systems.  For this reason, few of the requirements below are considered mandatory in the general case, though many will be mandatory in any specific environment. 

## Record Organisation Classification Scheme And Fileplan

It is a requirement of BS-ISO 154897 that all records are positioned within the Business Classification Scheme of the organisation.   Most case records are to an extent self classifying, in the sense that the 'subject' of the case identifies it from other instances of the same business process; for example, in a permit application case management system the folders may be identified by "permit application number", and all the records within the folders will bear that number. This means that, *if case records only are to be stored in the system* many of the requirements listed under A.1 Record Organisation may not be strictly essential for case records beyond specifying a fixed location in the organisational scheme for the case records.  The case records as a whole will still require a logical positioning within the business classification scheme of the organisation and this will need to be identified according to the ontology of that scheme and the nature of the casework8.  Additionally, if there are more than one discrete set of case records, they may logically require positioning at different parts of the classification scheme. In practical terms, these may be mostly theoretical positionings, only made explicit once case records are exported into another environment and prefixed accordingly to comply with other referencing systems in place. If the system is to store both case records and policy records, or if there is any possibility that this will be a future requirement, then all the requirements of section A.1 may apply. If only case records are to be stored, then it may be good practice to allow for the requirements in A.1, but they are generally not essential below this level [on export of any the records from the system, it may be necessary to prefix the classification of the case records to the case identifier[s] according to this logical position. In particular, under these circumstances case folders generally do not need to be further classified within a hierarchic arrangement of classes containing folders - a "flat" structure of folders is often all that is needed to exert good controls over the records; so the requirements in the following sections may be disregarded: 

" Classification scheme and fileplan " Class metadata. 
Additionally, much of the concept of *Class* becomes unnecessary owing to the absence of the descendent levels, and requirements throughout the specification have to be interpreted accordingly.  In particular, *inheritance* may not apply from this point and should be removed throughout the remainder of the specification9. 

'Zero' folder 

B.4.1 
(HD) The ERMS must support the capture of a standard case process, including its 
graphical representation (as described in the *Workflow* requirements below), in a 
case folder (hereafter called the "Zero" folder). 
B.4.2 
(D) The ERMS may permit the validation of the numbering of the "Zero folder" as 
having number Zero as its case identifier in the folder metadata and, if so, must prevent its assignment to any other case folder. 

## Folders

B.4.3 
 (M) The ERMS must provide facilities for the opening of case folders including 
appropriate validation checking (see following requirements). 
B.4.4 
(HD) When case folders are opened as a result of direct user action within the ERMS, 
the ERMS should provide an interface to allow the folder identifier entered manually to be validated against an external system. 
B.4.5 
(HD) The ERMS should allow case folders to be created and opened automatically 
on receipt of a valid request from an external application. 
B.4.6 
(M cond.) Where the ERMS is configured to support automated folder opening 
(B.4.5), it must provide error processing for the event of receipt of an invalid request 
to create or open a folder (for any reason, such as a request to open an existing folder).  The nature of the error processing is not specified here; its essential 
characteristics are that: 
" receipt of an invalid request does not create a new folder " receipt of an invalid request must not result in a software failure in either 
the ERMS or the external application 
" it must provide a mechanism to alert an appropriate user so that 
corrective action can be initiated. 
B.4.7 
(HD) When creating a new electronic folder, the ERMS should allow the folder 
reference to be supplied by an external application (this requirement is related to 
A.1.26 & A.1.27). 
B.4.8 
(HD) The ERMS should allow case folders to be closed automatically on receipt of a 
request from an external application. 
B.4.9 
(HD) The ERMS should be capable of configuration so that the ability to create new 
folders can be controlled according to both user role and the class in which the folder is to be created (this requirement is related to A.1.40, and is needed typically when 
the ERMS is to hold both policy and case folders - for which different approval may 
be needed). 

## Folder Metadata

B.4.10 (M) The ERMS must support the capture of folder metadata consistent with these 
requirements. 
B.4.11 (M) When the ERMS is to store both policy and case folders, it must allow for 
different metadata for each. 
B.4.12 (M) When the ERMS is to store both policy and case folders, it must include a 
metadata element which differentiates between them10. 
B.4.13 (M) When the ERMS is to store both policy and case folders, it must allow for 
different referencing mechanisms for each (i.e. a structured numerical or alphanumerical reference as described in A.1 for policy folders, and a case identifier, often generated by an application external to the ERMS, for case folders.  The 
requirement is usually that users can, within one classification scheme, refer to policy folders and carry out all operations on them, by using the structured reference; and 
can refer to and carry out all operations on case folders using only the case identifier or using the structured reference.  Note that this is similar to, but more flexible and more general than, requirement A.1.26). 

B.4.14 (M) When two naming mechanisms are simultaneously in use (as in B.4.13) the 
ERMS must allow users all features with both schemes (e.g. users must be able to 
search for, declare to etc. folders using only the naming mechanism applicable to the 
folder(s) in question). 
B.4.15 (M cond.) When the ERMS allows case folders to be created on the receipt of a 
request from an external application (B.4.5), it must populate the relevant folder metadata using data provided by the external application.  
B.4.16 (D) The ERMS may support a folder metadata element which records the case 
status, allowing authorised users (including an application system) external to the 
ERMS to change the status using a controlled list such as a drop-down list (examples 
of values might be "application received", "Form B2 sent", "Awaiting Clearance" etc). 

## Record Capture, Declaration And Management Capture

B.4.17 (M) The ERMS must be capable of configuration so that it can capture and declare 
records from external applications ('line of business systems') either with or without direct user action within the ERMS (*this requirement is related to A.2.3*). 

## Declaration And Record Metadata

B.4.18 (M) When the ERMS is configured to capture records from external applications 
without direct user action within the ERMS, it must be capable of configuration to extract and/or derive from the records (or from transactions provided by the external 
application) sufficient metadata to classify the records automatically, and to meet the 
metadata standard; and it must then classify the records automatically, associating 
the metadata with the records. 
B.4.19 (HD) When the ERMS is configured to capture records from external applications 
without manual intervention, it should provide error processing for the event of receipt 
of a record which cannot be captured and declared properly (for any reason, such as incomplete mandatory metadata, internal inconsistency, specification of a folder 
which is closed or non-existent).  The nature of the error processing is not specified 
here; its essential characteristics are that: 
" an invalid record  is not created in the ERMS; " receipt of a record which cannot be captured and declared should not 
result in a software failure in either the ERMS or the external application 
" it should provide a mechanism to alert an appropriate user so that 
corrective action can be initiated.  
B.4.20 (M) The ERMS must record the date and time of declaration (to the level of accuracy 
appropriate for the specific application11) as a metadata element attached to the 
record; this data should in addition be recorded in the audit trail (this replaces A.2.44 
for case processing applications in which the time of receipt is relevant at this level of 
accuracy; in all other applications, A.2.44 stands unchanged). 

## Permissions, Search, Display And Presentation

B.4.21 (D) The ERMS may allow users who have opened an ERMS case folder to switch to 
the external application and open the corresponding case in the external application, 
within one keystroke or mouse click. 
B.4.22 (HD) The external application should be able to provide an interface with the ERMS 
which allows users who have opened a case in the external application to open the corresponding case folder in the ERMS, with one keystroke or mouse click. 
B.4.23 (D) When the ERMS is able to interact with some external application(s), it may be 
possible to grant access permissions to the application(s) as if the application(s) were 
a user (so as to allow good control, e.g. when some records bear privacy markings). 
Retention, disposal This requirements module the scenario where structured case records are passed from a lineof-business case management solution to an ERMS solution [that should itself be compliant with the core requirements specification]; and explicitly not where the records are retained and managed within the line-of-business system which already contains reliable and acceptable retention and disposal logic. This approach nonetheless may transfer reliance for retention and disposal scheduling away from the ERMS and to the external application system, although the case records are being passed to the ERMS.  It can therefore only be used when the external application system's processing is considered correct and reliable12.  The approach has the benefit that it prevents inconsistencies arising between the two systems. 

In these circumstances, it is likely that aspects of section A.4 (Retention and Disposal) may be disregarded insofar *as they relate to specific casework requirements of the ERMS itself* 
(along with other requirements which refer explicitly to disposal schedules13), but the following mandatory requirements should be considered the absolute minimum: 
Retention and disposal 14 
 

B.4.24 (M) The ERMS must retain case folders and their contents intact until a valid request 
for destruction is received. 
B.4.25 (M) The ERMS must allow the external application system to mark for deletion one or 
more case folders scheduled for destruction (but not any other folders). 
B.4.26 (M) When the ERMS is configured to support marking folders for destruction (B.4.24), 
it must provide error processing for the event of receipt of an invalid request to 
destroy a folder (for any reason, such as a non-existent folder).  The nature of the error processing is not specified here; its essential characteristics are that: 
" receipt of an invalid destruction request must not result in any destruction; " receipt of an invalid destruction request must not result in a software failure 
in either the ERMS or the external application; 
" it must provide a mechanism to alert an appropriate user so that corrective action can be initiated. 

B.4.27 (M) The ERMS must require the confirmation of the destruction of case folders by an 
administrator before executing the destruction. 
B.4.28 (HD) When any folder is destroyed at the initiation of the external system, the ERMS 
should retain a metadata stub to record its former existence. 
B.4.29 (D) The ERMS may provide tools for the subsequent deletion of metadata stubs 
recording the former existence of destroyed folders by an administrator. 

## Audit

B.4.30 (M) When the ERMS is configured to capture records from external applications 
without direct user action within the ERMS, it must record such capture, and the related classification, in the audit trail automatically. 
B.4.31 (M) When any folder is opened, closed or marked for destruction at the initiation of 
the external system, the ERMS must record such actions in the audit trail automatically. 

## Reporting

B.4.32 (M) When the ERMS is configured to capture records from external applications 
without manual intervention, it must provide tools for the reporting of capture statistics 
(*this requirement is related to A.7.7*). 
B.4.33 (M) When the ERMS is configured to delete folders automatically on instruction from 
an external application system, it must provide tools for the reporting of deletion 
statistics. 
B.4.34 (HD) When the following three conditions are met: 
" the ERMS is integrated to an external application system " the external system produces reports which can be regarded as records 
(e.g. some MIS reports) 
" the ERMS stores 'policy' records as well as case records 
then the ERMS should be able to capture these reports automatically in a policy folder defined by a suitably authorised user (note that the metadata to be captured is not defined here in detail; however, it will be necessary to specify the rules for the metadata of such records). 

Workflow  
The following requirements are based on workflow requirements set out in the MoReq Specification,15 with additions and changes. As noted in the introductory section to this module, these generic workflow requirements are especially relevant in defining standard processes for case management environments and 
                                                     

## Should Be Read In Conjunction With The Preceding Case Management Requirements. Potentially, They Can Also Be Useful In Other Circumstances. Workflow Rôles16

B.4.35 (M) The ERMS must allow the authorisation of users as workflow process 
"participants" by an administrator. 
B.4.36 (M) The ERMS must support the definition of distinct workflow roles to different users.  
Examples, of "distinct workflow roles" include: 
- 
a workflow administrator (having permissions to reassign tasks or actions to another user or group but not necessarily wider administrator powers within the ERMS);  
- 
a local administrator or manager (having permissions to designate a workflow for exceptional handling); or 
- 
ordinary workflow users (or "participants"). 
B.4.37 (M) The ERMS must recognise as workflow "participants" both individual users and 
work groups. 
B.4.38 (HD)  Where the participant is a work group, the ERMS should include a facility to 
distribute incoming items to group members in rotation, or on a member's completion of the current task, to balance team members' workloads. 

## Workflow Definition

B.4.39  (M) The ERMS must provide workflows which consist of a number of steps, each 
step being (for example) movement of a record or folder from one participant to 
another for action. 
B.4.40 (M) The ERMS must not impose any practical limit on the number of steps in each 
workflow. 
B.4.41 (HD) The ERMS should support the setting of a practical limit to the maximum 
number of steps permitted in a workflow process as a configuration option.  
B.4.42 (M) The ERMS must allow pre-programmed workflows to be defined and maintained 
by an Administrator. 
B.4.43 (HD) The workflow definition and maintenance tools should include support for 
graphical representation and/or editing of the flows. 
B.4.44 (M) The ERMS workflow feature must not allow pre-programmed workflows to be 
changed by users other than an Administrator, or by approved users authorised by an Administrator. 
B.4.45 (HD) The ERMS should support the export of a standard workflow process or any of 
its constituent parts according to any relevant finalised XML schema[s] published on 
http://www.govtalk.gov.uk. 

## Workflow Alerts

B.4.46 (M) The ERMS must provide a function to alert a user participant that a folder or 
record(s) have been sent to them for attention, specifying the action required. 
B.4.47 (HD) The ERMS should integrate with an e-mail client to notify on behalf of a user (or 
the workflow) to notify other users of records requiring their attention. 

## Workflow Administration

B.4.48 (HD)  An authorised user should be able to designate that individual users are able to 
reassign tasks/actions in a workflow to a different user or group (for example, a user may wish to send a file or record to another user because it requires exception processing, or because the assigned user is unavailable). 
B.4.49 (M) The ERMS workflow feature must record all changes to pre-programmed 
workflows in the audit trail. 
B.4.50 (HD) The ERMS should support the capture of a defined workflow process as a 
record in its own right (case management requirement  B.4.1 refers). 
B.4.51 (M) The ERMS workflow feature must record the progress of a record or folder 
through a workflow so that users can determine the status of a record or file in the process by a simple enquiry. 
B.4.52 (M) The ERMS must not practically limit the number of workflows which can be 
defined. 
B.4.53 (HD) The ERMS should manage the folders and records in queues (or some similar 
construct) which can be examined and controlled by an authorised user. 
B.4.54 (HD) The ERMS should be capable of letting workflow participants view queues of 
work addressed to them and select items to be worked on.  
B.4.55 (M) The ERMS workflow feature must provide conditional flows which depend on 
user input or system data (for example, a flow may take a record to either a credit control participant or an order consolidation section, depending on input from a sales 
supervisor; or the flow may depend on the value of an order, as computed by the system). 
B.4.56 (HD) The ERMS workflow feature should provide a reminder, or bring-forward, facility 
for folders and records. 
B.4.57 (D) The ERMS workflow feature should allow users to interrupt a flow (i.e. to suspend 
it) temporarily in order to be able to attend to other work. 
B.4.58 (HD) The ERMS workflow feature should include the ability to prioritise items in 
queues. 
B.4.59 (M) The ERMS workflow feature must include "rendezvous" processing (this requires 
the workflow to be paused to await a specified event, such as the receipt of a related 
electronic document, or the completion of another workflow action; when the awaited event occurs, the flow resumes automatically). 

B.4.60 (D) The ERMS workflow feature may be able to associate time limits with individual 
steps and/or process in each flow, and report items which are overdue according to these limits. 
B.4.61 (HD) The ERMS workflow feature should allow the trigger events (such as receipt of 
an electronic document) to initiate workflows and trigger actions automatically. 
B.4.62 (M) The ERMS must provide comprehensive reporting facilities to allow management 
to monitor workflow volumes, performance and exceptions. 
B.4.63 (HD) The ERMS should be compatible with the Workflow Management Coalition 
Reference Model.17 

## Other

B.4.64 (HD) The ERMS should support automated recognition of electronic and scanned 
forms (using barcodes, form recognition or any other appropriate technique).18 
B.4.65 (HD) The ERMS should support the automated extraction of case identifiers from 
form fields. 
B.4.66 (HD) The ERMS should support the automated extraction of other metadata (e.g. 
data, names) from form fields.  
B.4.67 (HD) The ERMS should automatically declare forms from which the form identifier 
and case identifier have been extracted into the correct case folder, without user intervention, using the extracted metadata. 
by the ERMS itself.