Skip to main content
marcinw1932
marcinw1932
January 3, 2023
Question

How to set email header parameters in Send E-Mail Smart Service

  • January 3, 2023
  • 3 replies
  • 0 views

Hi everyone,

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.

Thank you in advance,
Marcin

 

 

3 replies

mike.cichy
mike.cichy
Employee
January 4, 2023

I have a lot of thoughts here but I will try to be concise.

  1. You cannot control email headers with the send email node.
  2. Receive Message Event works but there are better patterns for ingesting email.
  3. Depending on who person Y is this may not the best use of business processes management software (are you just replicating an email client?) and may be a violation of the license agreement (you have users participating in the process that are not logging into Appian).

Some suggestions:

  1. If they are internal users - they should be in Appian collaborating and having a conversation.
  2. If the users are external, maybe they could log into Appian, if not, then I wouldn't worry too much about threading, just send them a notification with the details that they need at the time they need it. Seems like a nice to have to me. Email presents a lot of challenges as an integration pattern since it can be end user edited, so I would recommend rethinking your design, e.g. what happens if the user sends another email to the original address? Is it a new case/process?
  3. I would suggest implementing email ingestion using one of the poller plugins - that way you can triage the emails, display them to someone if they cannot be routed automatically, and generally have more flexibility in handling them.
  4. If you really, really want to do this the way you want to, you will have to create a custom node that will allow you to send emails with custom headers. You may have luck with existing plugins.

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.

    marcinw1932
    marcinw1932Author
    January 10, 2023

    Thank you very much Mike,

    1. Could you elaborate what are these better patterns for ingesting email?
    2. Generally, I do not want to change the process I described above. These emails are kind of notifying, people got used to work this way (by sending emails to the same one email address mentioned as Person Y) and we would like to keep it as it is. What kind of license should such people have? Are all people that receive emails from Appian treated as users that should be paid?
    3. How to create custom node in Appian? Is there any documentation or guidelines? 
    mike.cichy
    mike.cichy
    Employee
    January 10, 2023

    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.

    Terms & ConditionsAccessibility statement