Managing document workflow using AEM Forms 6.1

[benm48734484]

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?

[smacdonald2008]

I am looking into this. Will post back soon.

[sixteenlabsinc · Accepted solution]

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

[benm48734484]

sixteenlabsinc 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.

[kautuk_sahni]

Lee has given you an excellent answer.

I have also asked internal team to have a look into your query.

~kautuk

[workflowuser]

AEM forms J2EE needs a database to run.

The document is stored in that database as it moves from one step to another. As to the security of the workflow, Only users with the appropriate roles will be allowed to interact with the document in the workflow 

[TundraSteve]

This is to completely correct.  Data from a form is stored in a database.  Documents such as attachments are typically stored on the file system.

[sixteenlabsinc]

Keep in mind that Adaptive Forms and PDF really don't share anything in common what so ever other than possibly a schema. If you have users fill in and complete an Adaptive Form, it will not automatically generate a resulting PDF at the end. You will need to use Designer to create your final PDF (which we now call the "document of record" or "DOR") then use your form data XML to accept data from your Adaptive Form and then render the PDF using that same data (this is where it is important to have the shared schema).

In regards to 6.1 and 6.2, there are few differences such as the ability to connect to a web service more easily, but you're likely not to use that and connect to backend services via your own OSGi bundle or a JSP.

That said, there is no reason you can't use a publish instance entirely outside of the JEE instance. In fact, that's my preference.

@leesutton