Overview
Projects often need to receive multiple documents from the customer to complete a request. In a bank, for instance, a customer must provide valid identification document to request a credit card or a loan. However customers don't have all required documents when they are filing the request, nor they are able to gather them at the same time.
Thus, ideally, Bizagi should be able to receive required documents throughout the lifetime of a single request. A request should be able move forward in a process with some documents (even with no documents), receive the incoming ones anytime and relate them to the process easily. Furthermore, there must be a time in the process when the request does stop until all required documents are gathered to be able to proceed to the next stage. This avoids having to send back home a customer with nothing achieved; to leverage a best customer experience.
Document handling in corporate projects can be complex, and filled with details:
•Integration between Bizagi and an ECM
•Each request has required documents and non-required documents.
•There are document that can be replaced with others (i.e. Drivers license or Passport).
•Required documents depend on the transaction type requested by the customer.
•There are documents that are valid for very long periods of time (5, 10, 20 years) and can be reused between the customer's different requests.
How can we build an efficient solution for document handling in Bizagi
The following approach allows customers to start transactions without having all required documents.
Customers will turn in the missing ones whenever available.
1. ECM integration
Configuring an event-based solution for the integration in Bizagi with the corporate documents repository (a proprietary ECM). When integrating with an ECM indexes must be created to easily identify is any case is expecting such document. Thus, as a document arrives the ECM is able to identify the case in Bizagi and the client related. The ECM should also determine whether a stored document is valid or it has expired (i.e. Passports have expiration date), and send to Bizagi only valid documents.
2. Event-based configuration
Bizagi sends uploaded documents to the ECM with all due metadata and receives the ones already stored.
If Bizagi detects there are required documents missing, the case is able to move on but the ECM is notified.
As documents arrive, the ECM notifies Bizagi and triggers the next step of the workflow (doing this for any number of cases awaiting for that document).
Metadata must be well-defined for all uploaded documents in BIzagi but also for required documents (the missing ones at the moment of starting the transaction). Whenever a document arrives to the ECM later on, the ECM can relate via the metadata which cases are awaiting for that document.
The ECM will trigger the awaiting event of the Bizagi process, via its SOAP web services (using setEvent).
Timers are running to terminate cases for which documents are not received on time.
3. Logic and optimizations
Bizagi can search for already-registered documents in the ECM as the request is filed.
By allowing Bizagi to look up which documents are already in the ECM, hyperlinks are fetched to avoid requesting the customer for a document that he/she has already registered, which meets the requirement.
Not only a better customer experience is achieved but efficiency in the operation (resources such as storage or network, or having to re-process information).
Searching for documents that apply to the current requirement is possible while having parameter entities that map which documents are required for which types of transactions.
This way, when invoking web services from Bizagi, filters and parameters oriented to the useful documents are employed.
Finally, documents uploaded in Bizagi are deleted as soon as they are sent to the ECM using Me.removeRelation function. The idea is that the ECM is the documents repository and storage is optimized with this approach.
Last Updated 1/6/2022 5:20:08 PM