This page details Known Issues for Adobe’s AEM Forms as a Cloud Service offering. Although there are similarities with an on-prem solution, the focus of this page are the Known Issues in AEM Forms as a Cloud Service.

Sandbox environments automatically enter hibernation mode (see illustration) when no activity is detected for more than eight hours. When this happens, users will see the Environment Hibernated message (see illustration) and we need to click Developer Console and de-hibernate the instance.

We can also see our environment in a Hiberated status in the Cloud Manager. Click the three ellipses and select De-hibernate to move the instance back to a running status. The process usually takes from 5 - 10 minutes to complete. We are not be able to access the instance until it completes.

Unless and until we configure advanced networking, we must use REST and SOAP data sources that run on port 80. If we have AEM Forms Workbench REST and SOAP services running on port 8080, they will not work as data sources on AEM Forms as a Cloud Service. We will not receive any messages about this when we create the data sources. But we will receive an ERROR IN FETCHING DATASOURCE message in a Form Data Model based on one of these unsupported data sources.

The FSI-Customers Form Data Model is a popular out-of-the-box sample Form Data Model in AEM Forms. But it does not work on AEM Forms as a Cloud Service due to a missing JAR file. The Cloud instance is missing the derby-10.13.1.1.jar file that is available in the aemforms-refsite-common application in on-prem installations of AEM Forms (see illustration).

We can not install this application on AEM Forms as a Cloud Service because it is not supported at runtime.