The term work activity coordination was coined in the 1996 NSF Workshop on Workflow and Process Automation in Information Systems , as a reminder that fields such as workflow in business domain, software process, and workflow in scientific domains have similar but not equal concerns regarding processes and the coordination of activities.
Within the area of workflow for business applications there is a growing concern with flexibility, adaptability, and the ability to deal with exceptions [2,9]. It is widely accepted that office procedures are much more creative and mutable than the initial workflow literature would suggest. In dealing with real workcases office workers creatively subvert the ``standard'' processes to get the job done. From a workflow management system point of view, it means that at enactment time, users should have more flexibility to replan and modify how a particular case will proceed. But businesses have concerns that this flexibility must be controlled, in some way, so that certain organization rules and goals are not violated. Exactly how to define this controlled flexibility is still a elusive goal.
Another important concern is that of the dynamic change  of workcases when the process models are changed. It seems that competition, the changing environment, changing business philosophies, and such are pressuring business to adapt their process models with increasing frequency. Dynamic change refers to the idea that process instances that are following the ``old'' process model can sometimes be dynamically changed into the ``new'' process model.
The area of software development [6,7] deals with process representations that have both well defined components and very ill defined components. For example, a software development organization may have a very specific and well defined process of software inspection, which will be a part, at the appropriate time, of the less well defined process of developing software, following, let us say, the waterfall model. The waterfall model  is a very high level description of the process which cannot even be regarded as an abstraction of the real process . It is at most a guideline for the real development process. But when it is time to perform a software inspection review, the process becomes very specific and well defined.
As another example let us say the organization has policies regarding who can call a meeting with a certain customer, how much in advance those meetings must be scheduled, and so on. Thus if during the process development there is the need for a meeting with that customer, then the software development process spawns a very ritualized sub-process (of scheduling meetings with customers) only to return to the less defined process once the meeting is concluded.
The concerns of the workflow community about (controlled) flexibility are not dissimilar with the software development's concern with well and ill defined sub-processes, that are both part of a larger software development process. In these cases, what is needed is a language to represent the processes that can be as vague or as precise, in different dimensions, as necessary. This paper argues that some form of temporal logic is the appropriate language, and more that this representation language also allows one to model diferent uses of the work activity coordination software.
Next section describes the different uses of a process representation in different fields. We call this the different uses of a work activity coordination software. Section 3 describes a minimal representation language that allows the representation of work activities and temporal relations among them. Section 4 extends the semantics of the logics (but not the language) so that the same representation of a process can derive stronger conclusions, specially regarding what activity can start in the next moment of time. Section 5 expresses the diferent modes of uses of work activity coordination software as definitions in our logic language. Section 6 shows that a logical representation allows for a very rich way of dealing with exception handling (within the workflow domain). Section 7 is a first attempt to define using the logic represenation and definitions some concepts related to the problem of dynamic change within the workflow domain; and section 8 present some conclusions and limitations of the approach.