I’ve had a number of questions about when and where to use Workspace, the Portal, and AEM Inbox. This article covers the use cases of each of these as well as where they may be used. This decision may be a little more difficult for JEE customers who have access to Workbench and Workspace for development and deployment.
AEM Forms Workspace
AEM forms workspace is a part of the AEM Forms JEE-based product. The primary function of workspace is to provide knowledge workers with the ability to both initiate work and interact with work they or their group have been delegated on the JEE platform. It is not available for OSGi-only deployments.
Workspace can display forms as either PDF, HTML, or Adaptive Forms. Both the PDF and HTML formats are rendered from an XDP source file created with AEM Forms Designer.
- XDP to PDF – an XDP is an XML representation of a PDF form. It is the ‘source code’ to the PDF
- PDF to PDF – a form created with Designer but saved as PDF instead of XDP
- XDP to HTML – a form created with Designer, saved as XDP but rendered as HTML
- Adaptive Forms – created using the embedded web-based authoring tools
AEM Forms workspace is designer to be used by internal workers only. It does not provide out of the box functionality to allow task assignments to users that are not designated to your corporate directory. Basically, do not put workspace in your DMZ.
For forms to be exposed and available to users in Workspace, a developer must create a process with a start point. This is not a task a typical form author can perform. The “Start NewProcess1” in the image below is the start point that tells workspace that a form should be exposed and available to a user to start this long-lived process.
The Workbench developer can chose which form is to be rendered and in the case of an XDP, whether it should be rendered as a PDF or an HTML form. With most modern browsers a developer must select HTML rendering or users will be prompted with the “The document you are trying to load requires Adobe Reader 8 or higher…” message. This is due to the fact that modern browsers no longer allow plugins to be deployed and to make things worse, they include their own PDF render technology that can be used to display static PDFs (ie: documents of record) but not dynamic forms.
From a development perspective, Workspaces’ integration with Workbench is very tight. Along with Workbench, a developer can create a form, create a service to pre-fill that form, and a process to accept and process the data of that form within a relatively short period of time and lower level of effort than other typical coding environments.
Due to the fact that each form displayed inside Workspace requires a start point to be created inside a unique process with Workbench, Workspace is NOT a forms repository. You should only see forms in Workspace that have a long-lived process that is run when submitted. You should not create a 1:1 relationship with forms and processes just because you want them to be displayed in Workspace.
For the official comparison documentation: Actions and capabilities of Form-centric AEM Workflows on OSGi and AEM Forms JEE workflows
For more information, see Introduction to AEM forms workspace.
AEM Forms Portal
Technically, there is no such product as the AEM Forms Portal but the technology that makes up this “portal” is referred to quite a bit by this name. While there is no “portal” per se, all the parts that you require to create a portal are provided.
A forms portal can be created to serve both internal and external users separately. Because different portals can be placed on separate AEM content pages you can create multiple forms portal that serve different purposes and audiences.
I highly recommend before trying to create forms portal that you complete the Getting Started with AEM Sites – WKND Tutorial. It is by far one of the best learning resources out there and while the tutorial is specific to AEM and not AEM Forms, the more you understand about AEM, the better you will be overall with your AEM Forms skills.
To create a forms portal you start with an AEM Content Page. This is a standard page that can be created using the AEM Sites web interface.
Once your site page is ready, you are ready to create the forms portal from the two components provided:
Search and Lister Component
The Search and Lister component is used to list forms on a page. It also provides a search ability for end-users to find forms.
Drafts and Submissions component
The Drafts and Submissions component lists all the forms that are in the draft state and the forms that are already submitted by an authenticated user. Users can view only their drafts and submitted forms.
Providing your forms authors with a forms portal allows them to quickly create and replicate forms out to their consumer environment. On the Author instance where form design takes place, users can create, upload, and then replicate their changes out to publish environments very quickly.
There is no tight integration with Workbench. Developers can create forms that can call AEM JEE processes very easily but created pre-fill services for forms deployed on a Publish instance is a higher level of effort than those inside Workspace.
AEM Inbox
For all intents and purposes, the AEM Inbox is the modern OSGi-version of JEE’s workspace. It provides OOTB functionality for users to interact with their task assignments.
While Inbox does have similar features and functionality of workspace there are some feature differences.
One of the very noticeable differences between Workspace and Inbox is the handling of in-form attachments. In Workspace all field-level attachments are removed and users are expected to consolidate their attachments into a single panel. With Inbox, we can create and use field-level attachments to have users place and interact with attachments directly inside the form. This helps developers answer questions like “Did the user attach a file that we required in section B”. With Workspace we can determine if attachments exist but they have no relation to the form or form data.
The Inbox is not integrated with Workbench. Items displayed in the AEM Inbox are assigned by workflow models, or AEM workflows that are developed using the browser-based model editor.
Workspace, Portal, or Inbox
If you are not a JEE customer and only have OSGi deployed then you will be using a combination of the Portal and / or the Inbox along with likely another custom interface / page. There is no Workspace with OSGi, only Inbox. This is a more modern approach to the deployment of AEM Forms technology.
Note that you can absolutely use Workspace, a Portal, and Inbox all within the same environment. Just be certain to educate your users as to which types of activities are driven from which interface.
Some simple rules / questions that may help you:
- Does the form require a long-lived process or other server-side processing and you are a JEE customer? If Yes:
- Create a process in Workbench
- Have it appear in Workspace via the start-point
- Does the form require a long-lived process or other server-side processing and you are an OSGi customer? If Yes:
- Create a workflow model
- Use a portal or custom UI to deploy the form
- Use Inbox to handle the associated tasks
- Note that for new forms and processes I strongly urge you to take this approach even in a JEE environment. It is the modern path to forms development and processing.
- Do you need to handle field-level attachments? If Yes:
- Create a workflow model
- Use a portal to deploy the form
- Use Inbox to handle the associated tasks
- Do you have a large number of forms that you wish to be accessible to end users but those forms do not need to be received and processed by the AEM server? If Yes:
- Use the Author instance to create and upload forms
- Use a portal to deploy the form
- Do not create unnecessary workflow models or workbench processes simply to expose forms
PDF or Adaptive Form
I recently had a friend ask me for guidance on whether or not they should start a project using a Designer-based XDP with an HTML rendition or an Adaptive Form. The conversation went something like this: “Do you have a calendar on your wall or computer?”, “Yes”, “Is the year 2020 or higher?”, “Yes”, “Then use an Adaptive Form.”.
Joking aside there are still a couple of valid use cases where you may need to use PDF:
- Do you need to support Digital Signatures directly inside your form as part of your workflow process? Before answering “Yes” to this question, be absolutely certain what your requirements are around Digital Signatures. If you just need a scribble signature or can support Click to Sign then you don’t need to use a PDF. More than half of users I’ve encountered don’t have a clear definition of what their real signature requirements are and go straight to this definition of the signature they require. Unless you are a government institution with CAC cards are an existing signature infrastructure, it is likely not the case. Please read this before deciding you need PDF. Do you still need PDF? Are you sure? If Yes:
- Use an XDP rendered as PDF
- Digital Signatures are not supported inside XDP’s rendered as HTML or Adaptive Forms.
- Note that Adaptive Forms allow you to generate PDF’s at the end of the submission or anywhere throughout the process. If you need a “document of record” or “receipt” of your action to be generated, this does not preclude use of PDF initially.
- Do you need to support Document Security and Encryption within your workflow? If Yes:
- Use an XDP rendered as PDF
- Note that Document Security is a separately licensed product and does not come with AEM Forms. It can also only be deployed in the JEE environment and is not available for OSGi.
- Do you have a large number of XDPs (source code to PDF) that you wish to deploy as HTML quickly? If Yes:
- Render your XDP’s as HTML to immediately solve the “The document you are trying to load requires Adobe Reader 8 or higher…” issue.
- Note that the JavaScript and business rules that worked inside your PDF rendition may not necessarily work in your HTML rendition. Expect a level of effort to make this transition.
- If neither of the two cases above fit, use Adaptive Forms. In particular for new forms projects. If you are creating a brand new form that needs to be compatible across multiple browsers and devices then Adaptive Forms first.
Additional Resources
The Search and Lister Component: https://docs.adobe.com/content/help/en/experience-manager-65/forms/use-forms-portal/creating-form-portal-page.html#search-amp-lister-component
The Drafts and Submissions component: https://docs.adobe.com/content/help/en/experience-manager-65/forms/publish-process-aem-forms/draft-submission-component.html
Creating a portal page: https://docs.adobe.com/content/help/en/experience-manager-65/forms/use-forms-portal/creating-form-portal-page.html
Manage Forms applications and tasks in AEM Inbox: https://docs.adobe.com/content/help/en/experience-manager-64/forms/publish-process-aem-forms/manage-applications-inbox.html