The question here is really, why would you treat something as a "case" as opposed to more of a process. Elsewhere on this site, I have used the rule of them that a "case is the work, and a process is the path it follows as it is completed." By this definition, any type of work would be a case. And this is in fact the case (no pun intended). But what are the truly cardinal characteristics of work that requires a more case management (as opposed to a traditional BPM approach). From my work, I would say there are three things:

1) A case will typically involve multiple parallel work streams (sub cases) to be completed. These sub cases all roll up to being the "case" itself.

2) Cases "care" about other work that is being performed. i.e. they are not transactional, whether and how they move forward is tightly coupled to the progresion of other work. This work could be sub cases, or it could be less tightly coupled cases, cases that are related to the primary case in any number of ways.

3) A case typically requires the addition of ad hoc work, both known kinds of work (think of a bunch of blocks that the user assembles at run-tim), and new ad hoc work, e.g. work to handle a previously unencountered situation.

4) A case doesn't typically have a 1:1 relationship of case:process, but a 1:many relationship--i.e. a case typically has several processes that might be used to resolve it.

The way pega treats work, everything truly is a case. However, not all of the work has these four characteristics that are the hallmark of dynamic case management.

What do you think makes a case a "case"?