Digital Enrollment Experiences with Experience Manager Forms in the Cloud

Transcript

Welcome everyone to this session where we’ll look at building digital enrollment experiences with AEM Forms in cloud. I’m Arun Taneja. I lead the product management for AEM Forms. I’m joined by Salil who’s the senior engineering manager for AEM Forms. So the agenda today, I’m going to go over a quick overview for AEM Forms in the cloud and then Salil is going to do a deep dive and also a demo for us. Let’s look at the AEM Forms vision to start off. We want to build a secure and scalable cloud native solution that offers agility as well as extensibility to deliver customized digital enrollment experiences across all channels. And to do that, we are happy to announce that we will be joining sites and assets on the cloud service and we’ll be able to realize all the benefits that the cloud service has to offer. Always current, versionless upgrades, modular auto scalability and improved resiliency and also secure by default. So you’ll see all these benefits coming to AEM Forms as well as it moves to the cloud service. What we’re starting with the initial release and we are in the pilot phase right now is the digital enrollment use case. What that means is everything our customers need to author and create digital enrollment experiences through their CX Leads and Forms practitioners. All of that functionality will be included in this initial release and then users will be able to engage in an end-to-end digital enrollment journey starting from data capture to e-signature with Adobe Sign. That integration will be available out of the box and including any document records that need to be generated, any workflow processes that need to run as part of the review and approval and as well as any email notifications that need to be sent to the user. All of that is covered in the initial release. Stay tuned for a GA release announcement in the next quarter. This will be the same product that you have been familiar with. Many of our customers have success stories. This is the same product and improved actually to easily create forms using no code interface in many cases, drag and drop interface to reuse the form fragments and centralize your forms repository and also the same adaptive mobile responsive functionality that our customers have enjoyed. We also will have a very easy way to automate business processes using workflows that all this functionality is moving to the cloud. To add to that, we have the automated forms conversion feature that many of our customers have enjoyed on our on-prem and managed services deployments. This is going to be available on the cloud as well with the initial release and this will allow existing paper-based processes and forms to be converted into adaptive forms using our machine learning capabilities that’s powered by Adobe Sensei. And now it’s over to Salil who is going to go over a deep dive into the AIM forms in cloud and also a demo. Salil, over to you. Thank you Arun. Hello everyone. I’m Salil Taneja, Senior Engineering Manager AIM forms. I’m going to give you a high level overview of forms cloud service architecture. I’m also going to show what’s new and what’s better in forms cloud service followed by demo. I’m not going to focus a lot on what’s good about AIM cloud service in general but would rather focus my energies on forms specific improvements. So to start with, I will give a high level architecture of AIM sites. So at the top you see cloud manager that is responsible for managing code and environment and your deployment pipelines. In the center is the container orchestration service with the frontiers as authored here and published here. Authored here contains the author service whereas published here contains the published and the dispatcher services. You also have maintenance task jobs and some internal services running in the container orchestration services. Everything that is running in container orchestration services per environment. At the bottom of the screen you see content repository that contains both node as well as drop store that is again as a little per environment. We have identity management service that is used for authentication. We also have replication service that helps in publishing the content from authors to your publishing services. You can also see CDN in the diagram. CDN comes with every cloud service free of cost. You can also bring your own CDN if you wish. On the right hand side there is asset compute service which use IOU events to interact with the container orchestration service. So with this overview I move to forms cloud service overview. Anything that is in blue is specific to forms. Again the crux here is the forms piece of code running in author and published. Earlier the forms was packaged as an add-on package but now we have modernized it to forms feature archive. You do not have to bother whether it is an add-on package or a feature archive on cloud service because based on your entitlement it is automatically deployed. However if you set a local development environment you need to download this forms feature archive from software distribution and rather than earlier installing it via package manager just drop it in install folder. That is the only major change otherwise for you the functionality remains similar. You can also see a blue arrow going from published by CDN to author. That is to highlight the case where any form submission of the published needs to go to the work flow that is running on the author for review of that form application. There is a blue box in the container orchestration service that is a forms document of record service that is used to merge the form template and the data to contain a blacking period. On the right side of your screen you see automated forms conversion service. That is a Robi’s insight for our deep learning technology that can merge an unstructured PDF to a structured web responsive adaptive form. That is automatically configured and integrated with forms cloud service. There is also a Robi sign block on the right hand side that is also very easy to integrate with forms cloud service. On the top left you see customer backend services and storage that typically contains the pre-filled data and is also storage for the final output data. With this high level architecture in mind I move towards typical request flow for a common digital level code that you see. The box in the center is more or less similar to what I showed in the last slide. It has a bit more details but at a high level it is kind of similar. On the left hand side is how the customer interacts with the service. On the top left you have various types of personas and various different types of interactions with the server. We have forms author that use either AFCS to convert adaptive form from PDF or XDP or they can use various types of editors to author adaptive form form data module. There are approvers who can review the form content as well as the final form applications. There are developers who can push their code and customizations like cloud manager to the forms cloud service. You have customer managed services that could be backend services or some storage. So I cover a request flow where an end user applies for some kind of an enrollment service, fills the form and then signs the form in the same sense. So as the first step is requesting for adaptive form, this request goes to the published service. The published service returns the HTML along with the data. Typically fetches the data from the customer managed service and the customer is presented with a form as well as the data merged. The customer can review the merged data, fill some data and submit the data. The submitted data goes to the published service. Published service checks whether the adaptive form is configured to be signed. If it is signed, it checks for the template that is associated with that adaptive form and it takes the PDF template, takes the data and converts the PDF template and data to a document of record. This document of record is then sent to Adobe Sign. Adobe Sign returns the agreement ID as well as the URL. The end user is then redirected to this Adobe Sign URL where it can complete the signing process. Once signed, the data as well as the signed PDF is then stored to customer managed service. Now with this high level flow and an overview of the architecture of Forms Cloud Service, let’s switch gears and move to what’s new and what’s better in Forms Cloud Service. Starting with enhanced performance. This is kind of obvious that the performance needs to be enhanced on cloud. Apart from the obvious auto scaling, we have done a lot of other things to improve the performance. The prominent one is enabling client-side data merge. Earlier, the data in the HTML is merged on the AM publish server side, but now we have changed this merge to happen in the client or the browser side. This allows the extremal of the adapter form to be easily cached at this patch and CDN level. What that helps is not just increasing the throughput, but also reducing the response time. In addition to the rendition of the form, we have also made significant performance improvement in submission, especially the server side validation. Moving from performance to operational and development efficiency. We have reduced the configurations. Now adapter form conversion service is out of the box configured for Forms Cloud Service. You do not have to create any kind of IMS integration. Similarly, you need some kind of a user on publish, configured to be able to authenticate to the author service and post the forms submitted data to the workflow running on the author server. All that user was earlier manually configured by AM administrator. Now it’s automatically taken care of by us and this kind of a flow is automatically enabled. We have also improved sign integration. We have enabled a new flow here. In this new flow, whenever the end user initiates a signature, the sign agreement is merged with the form data and sent to the submit service without waiting for all the signers in the signing process to complete their signature. This enables the end user to have better control on their signing process. We have also enhanced automatic form conversion service to automatically detect the sign fields and the numbers of signers and the association of fields with the various signers in the previous form. We have also started our foray into core components. Our first core component is form score container component. This would allow seamless integration with site score component as well as enable integration with other headless applications. Moving from operational and development efficiency to enhanced security. We have made quite a number of improvements in improving the security. This is not just providing you the latest for the signature but also give you the latest code with no security issue. Adapted from rules. So we have disabled code editor. Our philosophy is that code should be written by developers, should be reviewed by developers and it should follow code scans. Code should not be written by authors. So we encourage the code to be included only via VSTS and not written in the authoring instance. There is no functionality loss. Anything that you do in code editor can be done by using reusable functions that can be registered via VSTS. We are also improving our visual rule editor. We are making it more powerful so that for simple use cases and common use cases we do not have to rely on writing. Document of record. This runs in a separate container which is more restricted and provides better security control. Team editor, we are adding stricter ACLs to ensure security. Work flow. As I mentioned that right now we are not asking administrator to configure any user and to take care of its credentials. We are using a technical account for invocation of author service from publish. We are also auto rolling over the secrets to ensure security. There is no local persistence on the public service. This will make sure that there is no accidental leakage of any confidential data filled by end user in the form. We encourage to bring your own storage to store the final form data. So sorry we can hear you okay but a little louder would help. Sure. So I move to the migration part. We have announced a couple of migration tooling. So best practice analyzer that was known as cloud readiness analyzer as well. It helps you to identify all the migration challenges, provides you mitigation helps and it also provides you best practices recommendations. We have added form specific patterns to it so that now you can get anything that is specific to forms that needs to be modernized to perform better on cloud service. We are also enhancing content migration tooling by integrating form specific checks with this tooling. Content migration tooling helps you to take your content from your on-prem or AMS service to the cloud service. We are integrating this with forms tooling that helps you to do some kind of pre-migration steps like converting the code editor code to reusable functions as well as changing the older style content to new modern content that gels with the cloud service. Enough about presentation now. I am going to show you a live demo on how to build a digital enrollment experience with AM forms in the cloud. The demo would cover modernizing a PDF form, integrating that web responsive form with Adobe Sign, adding some dynamicity by using visual rule editor and if the time permits and also include a back end workflow review and approval process. For this demo, I am part of weekend site authoring team. weekend is a fictitious company that provides information about various activities going in international city. This form is used by the users of the weekend site to register for various activities. It’s a simple PDF form that contains personal information, some information about the trip and the activity of interest, standard terms and conditions and a signature fee. As a first step to modernize this, I move to my cloud service. I upload this file on my cloud service. Upload is successful. It’s loaded. Close the preview. Select the form and start automatic conversion. Select a cloud configuration that I have already configured, provide some parameters like template, and start conversion. This takes this PDF form to my automated conversion service which uses deep learning technology to convert into a structured web form. It takes around one to one and a half minutes to convert this form. So to preserve time, I move to already converted form. This is the same form that I showed and I show how the raw conversion takes place, how the raw conversion looks like. So I open my conversion UI on the left hand side. I can see the various adaptive form components. And on the middle end, I see a PDF like view to quickly compare and make some small corrections if required like changing the field or maybe if my deep learning technology has missed one of the fields, I can add the field here. I can review page by page as well. For now, the conversion looks okay to me. So I close this view and I go to my main editor. My main adaptive form editor shows the same form but in a different view, more of a web responsive view. I can see various fields converted. I want to group it better so that it starts appearing in some smart panel. And then I also want to rename it to page one to some meaningful names. I do a bit of restructuring and this is how my form starts looking. This is the same form, just a bit of restructuring and just a bit of reading. So in this form, I want to show two things. One is how easy it is to integrate with Adobe Sign. Open the form properties. At the bottom of this, there is an option of enable Adobe Sign. Select it. I select a cloud configuration. My automated form conversion services detected that there is one signer field in the original PDF form. So it has mentioned signer one here. If there would have been more signers, it could have mentioned more signers here. To ask me to map this signer one information, I say yes, the signer one and the person within the form is the same person. And I provide the email ID and map it with one of the fields in the form. That’s all it takes to integrate with Adobe Sign. The other thing that I wanted to do… So just a quick time check. We have 12 minutes to go. Not to rush you. Okay. Thank you. So in addition to integrating with Adobe Sign, I want to show how easy it is to add some kind of dynamic behavior. This is a travel date and I have a rest service. This service, based on the date, returns whether that date is available for travel or not. It returns a bunch of other things, but I’m only interested in this return value. So for a service, this is the definition of this. So I want to show a text message that says the date is available whenever a user selects a date, depending on the availability. So the first part, I add a text field and I also add a text box. The text box would be a hidden key that would be used just to store the value that is returned by the service. Whereas the static text would contain the actual message that the date is available. So let’s start editing the message first. And say the date is available. By default, I want to hide this. So I go into properties. Give it a nice name. This is the message and hide the subject. I also want to hide this. This is just an internal field that is used to capture the status. I do not want to show it to end user. Hide it. Alright. Next, I want to write some rule. I want to write a rule on this travel date. I want to open the rule editor. That’s my visual rule editor. I say when preferred travel date is changed, then I want to invoke a service. I’ve created a cloud configuration and form data model using this REST service. And now the service appears here. It also shows the input and output of the service. I map this input with one of the fields. That is my date field. I’m not interested in other fields. I just map this available field to one of my… The text field I just created. That’s it. I want to write another tool at available. I want to say that whenever this is changed, the condition says that when available is equal to crew, I want to show this field. Show my success message. And… I’m good to go here. I’ll test it, but I’m getting a bit more 3D and I make one more tool. I want to submit this to a backend workflow. I’ve already created a workflow model. That’s a basic review and approval workflow. Based on some condition, it goes to one side of the reviewer or to the other reviewer. I’ll not go into details of this workflow definition. I’ll just show on how to submit to an existing workflow. Go to the submit option. Select… Book name workflow. The name of my workflow model is review membership application. I provide the data path. I provide the attachments path. And that’s it. So this is the form that is ready to be tested now. Enter one, two fields. It’s the dynamic thing that we have added. I know the logic of the result that I’ve written. It says that if I select any of the Fridays, it says this is unavailable and on any other date it shows as unavailable. First I select web, that is Friday. Tap out. It makes a call but nothing happens because I added a rule only when the time is available. So change the date to the next date. Tap out. It says the date is available. So my rule is working. My invocation of the rest service is working. I try to submit. It says, hey, there is another mandatory field that you’re offered to fill. So it takes me there. I accept terms and conditions and try to submit this. So this submission step merges the data of the PDF with the template and then redirects to sign. The sign shows me all the fields that I’ve submitted. It tells me where to sign. I apply my signature. I click the sign. And it shows me a good message that my submission is successful. I can quickly move to my inbox and see whether I’ve got something for review. I refresh this. And there is an application that I’ve submitted a few seconds ago. I open this application. I look at the data that I’ve filled. It looks all okay to me. And I can approve. I can say that I’ve approved the application. And that’s all. So I show conversion of a PDF form to a web form, then integrated with sign, added some dynamicity, and enabled it for back end. With this, I hand over the control to Ari. Great, Ramo Salil. You also saw how easy it is to use the visual code editor to handle scenarios like tabbing out of a field or whatever’s entered in the field. Really awesome functionality. We have improved the visual code editor as well. Like I said before, stay tuned for an announcement for the GA data in the coming quarter. We are very excited to move forms to the cloud service. And have a journey ahead and stay tuned for that. And then just to make a quick plug for the next session, Sakshi in a few minutes is going to start the next session where we’ll have her show how to develop the form. So the entire developer workflow, starting from creating a project to updating configuration in the cloud instance to build custom functions that can be used in the visual editor. And also how to embed a form in a sites page using the forms container component. Very exciting and interesting session. This will be a follow up to what we just covered. So please stay and attend that session as well. Thank you very much for attending.