I wanted to understand better how best to manage Document workflow using AEM forms 6.1, where one user needs to complete some content on the form, then send it off to another for further updates, etc... where is the document stored as it's proceeding through the workflow? What is the user security model for participants in that document workflow process?
If you're using AEM Forms, then you have the ability to create an Adaptive Form and associated process that can pass both the form and the form data through a comprehensive workflow.
The process starts when you provide initiators with the form they need to complete to start a process. Once that form is completed and submitted, you can define the forms and form data that will be presented to subsequent users.
The "Assign Task" step that you use in the workflow allows you to select the form that will be presented to the next user in the step, the data that is embedded into that form, and the decisions they can make. For example, an initial user fills in a form indicating that they are on boarding a new employee. The initial form includes personally identifying information (PII) such as birthday, salary, and SSN. One of the steps in the on boarding process is to have this new employee added to the corporate directory. The manager responsible for this addition needs only the new employees name, address, and contact details and no PII or salary information. So, this IT manager is presented with a request to onboard the employee that includes only the information they need. Not only can the irrelevant data be omitted, they can be presented with an entirely different form than, say, the human resources manager responsible for setting up payroll.
At the data layer, the developer decides what data is inserted into each of the task assignments. This data is stored in what we typically refer to as the "runtime" layer. It is a data layer that specifically holds the data of an ongoing long-lived process. This data isn't user accessible.
Outside of the runtime layer, the developer has the option to write any elements of the workflow out to a 3rd party database whether it's MSSQL, Oracle, or other supported database. These can be used for external reporting, etc.
When using Workspace, the default application for initiating form submissions and responding to task, users have access to the forms and form data only for the steps that they are responsible for. Using the on boarding example again, the initiator can reference the initial form at any time and can see what step the process is currently at, but they cannot see the forms or form data of subsequent users. i.e.: The HR manager cannot see step details pertinent to the IT manager and vis versa.
Storage-wise, the "document" technically is not stored unless you specifically write it to a specific destination. However, each variable including document data is stored in the runtime database and includes an instance of that variable for each step the process goes through. Not user accessible data but could be programatically accessed. That said, the best practice for reporting and accessing data externally is to use your own datasource and not access runtime data directly.
As a side-note, upgrade to AEM 6.2 Forms and use Adaptive Forms as your main forms and PDF as a document of record (DOR) only.
@leesutton
wrote...
If you're using AEM Forms, then you have the ability to create an Adaptive Form and associated process that can pass both the form and the form data through a comprehensive workflow.
The process starts when you provide initiators with the form they need to complete to start a process. Once that form is completed and submitted, you can define the forms and form data that will be presented to subsequent users.
The "Assign Task" step that you use in the workflow allows you to select the form that will be presented to the next user in the step, the data that is embedded into that form, and the decisions they can make. For example, an initial user fills in a form indicating that they are on boarding a new employee. The initial form includes personally identifying information (PII) such as birthday, salary, and SSN. One of the steps in the on boarding process is to have this new employee added to the corporate directory. The manager responsible for this addition needs only the new employees name, address, and contact details and no PII or salary information. So, this IT manager is presented with a request to onboard the employee that includes only the information they need. Not only can the irrelevant data be omitted, they can be presented with an entirely different form than, say, the human resources manager responsible for setting up payroll.
At the data layer, the developer decides what data is inserted into each of the task assignments. This data is stored in what we typically refer to as the "runtime" layer. It is a data layer that specifically holds the data of an ongoing long-lived process. This data isn't user accessible.
Outside of the runtime layer, the developer has the option to write any elements of the workflow out to a 3rd party database whether it's MSSQL, Oracle, or other supported database. These can be used for external reporting, etc.
When using Workspace, the default application for initiating form submissions and responding to task, users have access to the forms and form data only for the steps that they are responsible for. Using the on boarding example again, the initiator can reference the initial form at any time and can see what step the process is currently at, but they cannot see the forms or form data of subsequent users. i.e.: The HR manager cannot see step details pertinent to the IT manager and vis versa.
Storage-wise, the "document" technically is not stored unless you specifically write it to a specific destination. However, each variable including document data is stored in the runtime database and includes an instance of that variable for each step the process goes through. Not user accessible data but could be programatically accessed. That said, the best practice for reporting and accessing data externally is to use your own datasource and not access runtime data directly.
As a side-note, upgrade to AEM 6.2 Forms and use Adaptive Forms as your main forms and PDF as a document of record (DOR) only.
@leesutton
Would you be able to provide any more detail regarding limitations with using AEM 6.1 adaptive forms vs. 6.2? Unfortunately, our team is restricted to 6.1 on JEE since the group hosting our environment is using Oracle 11g, and has no plan to upgrade to 12c in the foreseeable future. That being said, I would like to get a better understanding of what limitations might have with 6.1 that would challenge our approach. In our scenario, it is very important that we produce pixel-perfect PDFs as the PDFs will be used as supporting documentation for international trade.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
