BPM and Document Generation: Two Common Use Cases Involving HotDocs

Given the relative flexibility of the major BPM suites and HotDocs (the most powerful and flexible of thedocument generationRAD platforms), an almost infinite number of use cases could emerge. However, early in the relationship between HotDocs and BPM vendors, two particular use cases seem to be common: (1) database-driven cases and (2) transaction-driven cases.

Database-Driven BPM/Document Generation

With a database-driven use case, a data record already exists in some data storage application, such as a CRM. Under this scenario, the BPM would receive the data payload from the CRM and route it based on various conditions. In the event that documents needed to be generated from the data payload, the data could be passed on to HotDocs for assembly purposes. In the event that the data payload did not include all the data necessary to generate the document, a supplemental HotDocs interview could be exposed within the workflow to gather the necessary additional data, in which event, the additional data, along with the generated document(s), would be passed back to the workflow for storage and/or routing.

Transaction-Driven Cases

With transaction-driven use cases, the workflow often begins with extensive data gathering that could be based on sophisticated decision-tree logic. For this sort of case, the BPM may want to call on HotDocs early in the process, given its prowess at gathering sophisticated data sets. The HotDocs interview could itself be routed throughout an enterprise for input from various members of the staff, or even be routed to external sources for additional input. The data from the interview could then be used to drive the workflow through its completion, which, in many cases, might involve the generation and stage approval of a documentation set.