Workflows provide a structure method for storing a sequence of states over which the a document will progress. Workflows keep track how a document has been processed so far.
Workflows work by storing a series of states to help you know the “status” of a document. To move a workflow from one state to another, transitions are used.
Transitions connect two different states and help provide context to know which state is possible to transition to, from a previous state. Transitions provide and order for the sequence of possible states changes.
Transitions can be executed manually by users if they have the required access level as configure by the system administrator.
Besides being able to be executed manually by users, transitions can also be programmed execute automatically based on system events. This is called in Mayan EDMS transition triggering and is one of the tools available to automate business processes.
- Move a document from a “scanned” state to a “billed” state when a tag is attached to the document.
- Move a document from a “uploaded” state to a “OCR ready” state when the OCR engine finishes processing the document.
The other tool provided for process automation is being able to execute an action when a workflow state is reached or leaved. These are called state events.
Some examples of state actions currently provided are:
- Attach a tag to a document
- Remove a tag from a document
- Do an HTTP POST request to an external IP address
- Edit the label or the description of a document.
Other time more state actions are being added. Some state actions like the one that creates an HTTP POST request allow Mayan EDMS to trigger processes in external systems based on the state of a document. One example of this is triggering the billing process of an accounting system when an invoice is scanned in Mayan EDMS.
Workflow state actions and transitions triggers are new features and are still evolving.
Workflows allow translating business logic into a series of states. With the addition of state actions and transition triggers, the workflows in Mayan EDMS are no longer just informative but can be part of your actual business automation process.
Internally, workflows are implemented as a finite state machines (https://en.wikipedia.org/wiki/Finite-state_machine). And have the limitation that only one state can be the current active state for a workflow being executed. The other limitation of the current implementation is that every workflow needs at least one state marked as the initial state. These limitations are the result of a compromised in the design between flexibility and ease of use.
The graphical representation of a workflow (or a finite state machine style in Mayan EDMS’s case) is similar to a flowchart. The states are represented with circles. The transitions are represented with arrows. Circle with a double border represent the initial state of the workflow.
To view the graphical representations of workflow use Preview button of the workflow in the setup view.
We are working now on workflow transition trigger filters to have the trigger move the state of the workflow on certain conditions. For example: Attach a tag if there is a specific word found in the OCR text.
Mayan EDMS supports two types of document signatures: embedded and detached signatures. When a document with an embedded signature is uploaded, this signature is readily detected as part of the document inspection step. The status of the signature can be verified by accessing the signatures sections of a document.
Signed documents are tamper-proof. That means that if any part of the document’s file is edited (even just one character or one pixel), the document’s signature becomes invalid alerting that an unauthorized change has occurred.
Existing non signed documents can be signed in one of two ways: by downloading the document, signing it, and uploading the signed document as a new version of the existing one or by creating a detached signature for the non signed document and uploading such detached signature file.
Maintenance of the public keyring can be done using the
functionality in the
From this menu, key servers can be queried and the results imported. Public keys no longer needed can also be deleted from this menu.
Only GNU Privacy Guard signatures are support at the moment.
Only version 1 of GNU Privacy Guard is supported at the moment.
Metadata is the name of the attribute of a document. The concept of metadata is divided in two: metadata types (size, color, distance) and metadata values for those types. Metadata types are defined in the setup menu and associated with document types. Then when a document is uploaded, a value for that metadata can be entered. There are two kinds of metadata type to document type relations: optional and required. When a metadata type is optional for a document type, it can be left blank for a document being uploaded and the upload will still be successful. On the other hand required metadata type must be given a value or it will not be possible to upload the document at hand.
Examples of metadata type: Invoice number, color, employee id.
The data entry of metadata types can be set to allow any value to be provided
(the default) or a list of possible values can be entered in the
configuration option and users will be presented with a drop down list of options
instead of the default text entry box.
If metadata types are setup to allow any value to be entered a
option can be chosen to block the entry of invalid data. Metadata types also
parsers which will not block the entry of data but are able to
interpret and modify the value provided by the user to a conform to a specific
format. An example of a provided parser is the date parser which will interpret
and correct dates provided by users regardless of the format in which they are
Transformations are persistent manipulations to the previews of the stored documents. For example: a scanning equipment may only produce landscape PDFs. In this case a useful transformation for that document source would be to rotate all scanned documents by 270 degrees after being uploaded. By adding this transformation to the Mayan EDMS source that is connected to the scanner, all pages scanned via that source will inherit the transformation as they are created. The result is that whenever a document is uploaded from that scanner, it will appear in portrait orientation, instead of landscape orientation.
Transformations can also be added to existing documents by clicking on a document’s page and then clicking on “transformations”. In this view the Actions menu will have a new option that reads “Create new transformation”. Currently, the available transformations are: rotation, zoom, crop, and resize. Once the document image has been corrected, resubmit it for OCR for improved results.
Transformations are not destructive and do not physically modify the document file, they just modify the document’s graphical representation.
Mayan EDMS has the ability to store different versions of the same document. A comment field is provided to allow users to summarize the new version changes in comparison with the previous one. If a new version was uploaded by mistake or such new version is no longer necessary the option to revert to a previous version of the document is provided.
Only the interactive document sources (Sources)
Staging folders) are available to upload new document versions.
There is no limit to the number of versions a document can have.
By default, the last version will be showed when working with the document but any of the versions can be inspected and viewed.