A developer asks: Our application has five phases through which we're rolling in different types of exceptions. Within each phase, we may have three subtypes of an exception type. We're going to link those together under a cover. So for each phase, we will put such related things under a cover because researchers need to resolve all of those together.
But across all the five phases, we want to relate things associatively as well, because a certain type of issue may have caused another different issue, and so on. .
For example, on one account and one security ID, we could have 100 open exceptions, and we want to research how these might be loosely related. Would that business need be a good candidate for folders?
We accept multiple batch feeds in a day. So we're repeatedly opening and closing work objects that will belong to one folder. Is this a possible performance bottleneck?
If work object in a folder becomes resolved, it does not need to remain part of the folder any longer. But it does not matter to us whether resolved work objects remain in the folder, because our reporting will make the status clear, or filter on it.
This scenario is a good one in which to use folders.
One good use of folders and covers, for example, could occur under the following scenario: When someone calls into a call center, she may have three or four things that the customer service rep needs to do, and those could become covered work objects. Then each of those things could also be associated with a folder that includes every request from all calls on that customer's account, so that the business could see and analyze everything done for that the customer across all the various covers and covered items.
The relationship between the folder and the work object is maintained in instances of the Link-Folder instances. The Link-Folder instance holds the keys to the objects being linked from and to.
To add or remove a work object from a cover, you must obtain locks on both the work object and its cover. But with folders, you don't need any locks, because neither the work object nor its cover is updated.
Note that a work object can be in more than one folder. It's a many-to-many relationship, whereas covers operate on a one-to-many basis.