I am creating a process model which starts and receives some data from email due to a Receive Message Event, then processes this data with some logic and finally sends summary email in response using Send E-Mail Smart Service.
I want that the summary email that my process sends to be displayed in outlook (or any other email program) as a conversation, that means to be grouped and displayed in one thread. Case: - Person X sends email A to Person Y that triggers my process model,- Person Y receives email A,- Process model executes and sends to person Y summary email B as a response to email A,- Person Y receives email B and both emails A and B are displayed in one thread in person's Y outlook
Usually in high code to do this, I need firstly set headers parameters as References, In-Reply-To for my summary email B before sending. I get this headers values of email A with Receive Message Event but I do not know how to set this headers to email B using Send E-Mail Smart Service since there are no such fields available in this Node and there is no information in documentation for such case.
References, In-Reply-To for
Thank you in advance,Marcin
Discussion posts and replies are publicly visible
I have a lot of thoughts here but I will try to be concise.
Sorry I couldn't be more specific but the context of your process matters. Depending on the purpose of this feature, the volumes, the users themselves, the app design could vary.
Thank you very much Mike,
Again, really depends on who your users are, and how the process works, what volume you are looking at on what the pattern should look like. If volumes are low, then sure, go with process listeners. Message listeners can create scale issues at high volumes, are a bit less reliable, you have fewer protocol options (pop3 and imap only), and the emails can get routed to spam. But if you are looking at triaging 100+ emails daily, you should really use one of the mail poller plugins, e.g. https://community.appian.com/b/appmarket/posts/msgraph-email-poller to ingest emails. You can then include a case/process id in the subject line to attach to your transaction or based on who it is coming from. Emails that can't be automatically routed will have to be manually triaged and routed.
As for the license agreement, it depends on the terms, but if you have a per user license, in your scenario, you effectively have users utilize the system through email exchanges (not just notifications) without an account and therefore they should pay for the process orchestration. I am not saying you are in a license violation (for example, they may be using Appian in a different app so licenses are covered, but if that is the case, they should be making direct edits in the app instead of sending emails) but it would be worth checking with the Appian Account Executive. Let me know if makes sense.
See plugin documentation for more info on smart service plugins: docs.appian.com/.../Custom_Smart_Service_Plug-ins.html. The plugins on the AppMarket have source code included in the jar so that may be a good start for something new. To me, if it is indeed lower volumes, it would simply be not worth it and I would just give up on threading.
© 2023 Appian. All rights reserved.