Workflow modelling patterns capture frequently used business process fragments. They describe higher-level concepts than basic process elements like ‘task’ and ‘decision’, giving us a richer vocabulary for talking about business processes. This article introduces four document workflow patterns.
This article is part of a series of workflow modelling patterns:
- approval patterns
- document patterns
- collaboration patterns
- email patterns.
Many workflows handle ‘documents’ - typically word-processor files and spreadsheets, because we commonly use these documents to capture both information and milestones when we collaborate in teams.
Document Approval
An earlier article already introduced the Document Approval pattern, which is a management approval pattern as well a document workflow pattern.
This is a good example of a workflow pattern that is ‘higher-level’ in the sense that it consists of a decision related to more than one task. It is also a source of related patterns: things you might do with a document once it has been approved.
Document Distribution
The goal of the Document Distribution pattern is to send a copy of the final version of a document by email, to make it available outside Effektif. Examples of document archiving include notifying process stakeholders of input to a workflow, such as a CV submitted to a hiring process, or a document created for a task as part of a process, such as a project proposal.
Email is a kind of systems integration, using a document to make information accessible outside the process and system that created it. A document’s context is often a specific workflow milestone, such as the CV that corresponds to a job application milestone, or the sales report that captures an information gathering task’s completion. Email is suitable for ephemeral documents, when no long-term storage is required.
This pattern has the following structure, as implemented in an Effektif process.
The key part of theDocument Distribution pattern is the automatic Send email task that automatically saves the document, without human interaction. The other participant is of course the form where the document was uploaded, to add it to the case. The document could also be an email attachment, provided via an email trigger.
A consequence of this pattern is publishing a document outside the scope of its workflow. Other business processes may come to rely on these documents, creating a dependency between their workflows.
Related patterns: Document Archive can be used the same way.
Document Archive
The goal of the Document Archive pattern is the same as for Distribute Document: to make a copy of the final version of a document available outside Effektif. The only difference is the destination: saving the file in Google Drive or Box instead of sending it by email.
Saved files are, like email, a kind of systems integration. For many IT systems, this is the simplest way to exchange information, even if it is not the most sophisticated. File archives are more appropriate when long-term storage is required.
This pattern has the following structure, as implemented in an Effektif process.
The key part of the Document Archive pattern is the automatic Google Drive or Box Upload File task that automatically saves the document. The other participant is the form where the document was uploaded, or the email trigger that provides the file via an email attachment.
A consequence of this pattern is publishing a document outside the scope of its workflow. Other business processes may come to rely on these documents, creating a dependency between their workflows.
Related patterns: Document Distribution can be used the same way.
Consultation
The goal of the Consultation pattern is to get input on a draft document from multiple stakeholders. Examples include things like sales reports that require sales data from specific parts of the business or commercial proposals that require feedback from key stakeholders.
Consultation is useful when document preparation requires input from a known list of stakeholders. These stakeholders would normally be defined in terms of roles that relate to the document in question, such as the Project Manager for a project proposal.
This pattern has the following structure, as implemented in an Effektif process. This example shows a proposal that requires feedback from three stakeholders.
The pattern is centred around user tasks for each of the stakeholders who must provide input. These user tasks are surrounded by parallel gateways, to indicate that they will be completed independently, but must all be completed before preparing the next draft of the document can proceed, by consolidating the feedback. Not shown on the diagram are the separate roles defined for each of the stakeholders, which are part of the user task assignment configuration in Effektif.
The main trade-off when using this pattern is between the clarity of making the stakeholders explicit, by modelling a user task for each one, and the loss of flexibility in the number of stakeholders. An alternative, in Effektif, would be to have a single Give Feedback user task, and to create (parallel) ad-hoc subtasks on a case-by-case basis.
The Consultation pattern is related to Document Approval, which can include it as part preparing a draft for review. This is a collaboration workflow pattern as well as a document workflow pattern, so it also relates to other collaboration patterns.