Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Email task notifications with form attachment for approval

Avatar

Former Community Member
I have a process that is started in Workspace and I have the preferences set for each of the users in the workflow to get task notifications via email with the form attached so they can approve/deny tasks in Reader/Acrobat without having to go back into Workspace.



The email works fine, the form is sent to the assigned user, however I'm a bit lost as to what to do in my process so when the user clicks the submit button the XDP data is sent to the right place. Poking around here it looks like I need to set up a Complete Task with an email endpoint? My forms have the Process Fields component already attached to them and looking at the data.xdp it is populating with the task ID and other data.



If that's that case a little bit of instructions on how to configure the Complete Task is in order for me. Do I put it on after each of the steps in the process that the form is transferred to different users, thus initiating more emails.



Thanks,



Mike
7 Replies

Avatar

Level 10
The Complete Task process is a process that already exists that LiveCycle uses to complete tasks in processes.



If you create an email endpoint to that process, then you can send an email to that process and it'll take care of completing the task for your.You don't need to add that step in your process.



For example if you have a 2-user step process called "MyProcess" and that process has two steps called "stepA" and "stepB". When a new form is initiated, the first user gets the form and the form has a task id associated with it (let's say 111). When they send the email back to the Complete Task process, it'll be smart enough to know that task id 111 refers to the process "MyProcess" and will complete that task, which will then create a new task for the second user in the process.



Make sense?



Jasmin

Avatar

Former Community Member
Yes it makes perfect sense now, with the advice you dished out on https://forum.adobe.com/webx/.3c05c334 it appears my email task submission is working!



Thanks,



Mike

Avatar

Former Community Member
Like Jasmine mentioned, I have

Start -> User A -(approve)-> User B -(approve)-> End



the task is created, and USER A gets the email with the PDF attached.

They open the email, approve and submit.



The email gets sent.



We receive the email in the LC mailbox.



But it never continues, and the logs see no activity.

No chron job, no listening.

We set up the pop3 and all for 30 second intervals, but it doesnt seem to work.



Does this mean that for every process I must put an email end point in it for LC to listen to its inbox, and for the process to continue?



Thank you,

Mish

Avatar

Former Community Member
I have added an Email endpoint to the process.<br />The mail gets removed from the inbox as i would expect but i get an error email.<br /><br />LiveCycle ES has tried to process your request and encountered the following error:<br />Cannot coerce object: <document state="active" senderVersion="3" persistent="false" senderPersistent="true" passivated="false" senderPassivated="true" deserialized="true" senderHostId="127.0.0.1//10.64.128.161" callbackId="0" senderCallbackId="27" callbackRef="null" isLocalizable="true" isTransactionBound="false" defaultDisposalTimeout="600" disposalTimeout="600" maxInlineSize="65536" defaultMaxInlineSize="65536" inlineSize="2326" contentType="application/xdp" length="-1"><cacheId/><localBackendId/><globalBackendId/><senderLocalBackendId/><senderGlobalBackendId/><inline><?xml version="1.0" encoding="UTF-8"?> <?xfa generator="XFA2_4" APIVersion="2.6.7120.0"?> <xdp:xdp x...</inline><senderPullServantJndiName>adobe/idp/DocumentPullServant/adobejb_server1</senderPullServantJndiName><attributes file="form_data.xdp"/></document> of type: com.adobe.idp.Document to type: class com.adobe.idp.taskmanager.form.impl.xfa.XFARepositoryFormInstance<br /><br />I had to set the mapping to *.xfa otherwise the email would just be ignored.<br />It seems to me that livecycle is not clever enough to pick up an email that its own form sent to the server.<br />Furthermore it would seem that an inbox must be unique for livecycle to pick up any submitted forms. That makes the whole send form to user thing worthless, since the form send to the user ALWAYS has the standard livecycle submit email address. That means per livecycle server you can have exactly one process that has an email endpoint for in process form submissions/reminders.<br />An email inbox should work exactly like watched folders, i.e. email patterns per workflow.

Avatar

Former Community Member
After digging some more i found a "Complete Task" service, and after looking at the process and further digging:<br />ADD AN EMAIL ENDPOINT TO "Complete Task" ONLY<br /><br />This will give you exactly what should work out of the box when you select "enable incoming emails" in the server configuration about email notifications.<br /><br />(i am sure this has been mentioned a number of times, but since there is no sticky, no moderation and no useful search ...)<br /><br />Although this got me to the point of actually being able to complete forms offline i cannot actually start new processes with this.<br />A quick look at the result and it would seem that a newly submitted form produces a different xfa/xdp than a continued form. (the root node is replaced by <FSFIELDS_>)<br /><br />If anyone has any info on how to properly start processes with "Complete Task" ...

Avatar

Level 10
"Furthermore it would seem that an inbox must be unique for livecycle to pick up any submitted forms. That makes the whole send form to user thing worthless, since the form send to the user ALWAYS has the standard livecycle submit email address."



That's not true. The inbox and email settings are configured on the Email endpoint. You can have as many email endpoints as you want, all using their own email inbox.



I think you're getting confused with the email endpoint and the email notification that can be generated by LiveCycle.



The email endpoint will just take care of initiating a process, just like a watch folder. Once the process is initiated its job is done. If your process uses a User service, and you use Reminder and Deadlines notification, then those notification are coming from LiveCycle and not the email endpoint.



I hope this clears things up a bit.



Jasmin

Avatar

Former Community Member
@Jasmin



I wont start a discussion of the usefulness of out-of-the-box functionality.

I think these forums are proof enough.



However ...

Email notification with attached form does not work "out-of-the-box". Period.

"Enable incoming email" does nothing. Reminders with form attachment does nothing.

Notifications with email attachment does nothing if the user has not logged into workspace at least once and selected "include pdf in email".

Selecting "include pdf email" does nothing if not enabled in the backend. (known issue i believe, supposedly "fixed" in SP2, however SP2 broke notifications)



Creating a different mail account for each process IS useless. That may have nothing to do with notifications HOWEVER forms that need to work for offline initiation AND offline continuation either

* need to have two different email addresses coded into the form

* only one process on the entire server can have both at the same time



Configuring pdf notifications also means that offline continuation (and in turn initiation) is enabled by default for all processes, rendering the email endpoint for individual processes useless. (as already "enabled" through complete task)



My comment was related to the email endpoint option, and that it is not only misleading but all in all useless. (for regular business processes such as purchase orders, holiday requests, etc)

I was also referring to the impracticality of adding an active directory account (+mail) for every single process.