Showing results for 
Show  only  | Search instead for 
Did you mean: 

Sending multilingual emails

Sending multilingual emails



Often there is a need to send emails out to users which have multiple languages. Unfortunately, IdentityIQ's default email templates do not support language currently. However, there are still a number of options at your disposal to solve this problem:


Option 1:  All languages in single email

You can put all languages in one email template, and have an HTML section which allows you to "jump" to the correct language setting. 


Option 2: Leverage velocity to render correct language

If your email template has the context of the identity who is being sent the notification, you could use an Identity attribute to render the correct language. 


For example, if you had an identity attribute called "preferredLanguage", you could use this to key the correct language. 


#set ( $language = $certifier.preferredLanguage )


#if ( $language == "de" )

    Hallo! Mein Name ist $certifier.displayName


#elseif ( $language == "fr" )

    Bonjour! Mon nom est $certifier.displayName


#elseif( $language == "es" )

    ¡Hola! Mi nombre es $certifier.displayName



    Hello! My name is $certifier.displayName




if "preferredLanguage" was set to "de" then we could expect a certifier's email to look something like this:


Hallo! Mein Name ist Robert Brown


Option 3: Send email based on language

If you have API control, you have control over selecting and sending the correct email template yourself.  For example:

String emailTemplateName = "Notification Template";

String language = identity.getAttribute( "preferredLanguage" );


EmailTemplate emailTemplate = context.getEmailTemplate( emailTemplateName + " - " + language );


EmailOptions emailOptions = new EmailOptions();

emailOptions.setTo( identity.getEmail() );


context.sendEmailNotification( emailTemplate, emailOptions );


Option 4: Use custom email notifier

In IdentityIQ 6.1, we added the option called emailNotifierClass to the SystemConfiguration.  You can write your own emailNotifierClass which can re-translate the templates. As an example:

<Configuration name="SystemConfiguration">




      <entry key="emailNotifierClass" value="sailpoint.example.MultilingualNotificationSender" />


The custom emailNotifier code might look something like this:

package sailpoint.example;


public class MultilingualNotificationSender implements EmailNotifier {


  public void sendEmailNotification( SailPointContext context, EmailTemplate template, EmailOptions options )

    throws GeneralException, EmailException {


  // Step 1: Derive email addresses

  List<String> emails = template.getTo();


  // Step 2: Process each each email individually, because language can vary

  for( String email : emails ) {


    // Step 3:  Get the language for this person

   String language = getIdentityLanguageFromEmail ( email );


    // Step 4:  Get the correct email template based on the language

    EmailTemplate selectedTemplate = selectNewTemplate ( template, language );


    // Step 5: We send an email to them with the correct language

    sendEmail( selectedTemplate, email );






Hello Neil,

Thank you for your post!

I do not believe the fourth option, 'Use Custom Email Notifier', is a feasible solution. I attempted to implement this solution and noticed the following difficulties:

  • The EmailOptions variable supplied to the 'sendEmailNotification' method is always empty. This prevents us from retrieving the necessary variables required when recompiling the email in a new language. To be honest, I am not too sure why this variable is provided as a parameter.
  • The EmailTemplate variable supplied to the 'sendEmailNotification' method is post compilation. This leads me to believe the EmailNotifier is not the appropriate point in the sequence to inject logic for supporting multilingual emails, as it is too late in the sequence and IdentityIQ will be performing redundant work.

Perhaps the better approach would be to extend the 'compile' method for the EmailTemplate class?

Let me know your thoughts!

blaise.bostelmann​ - Yes, the fourth option is post-compile.  However, I disagree with you, it is still an option.  We have had customers add their custom email notifier and then do a lookup on the person, gather their preferred language, and then change place-holders (think string tokens) of the email template to suit the language.  The values coming into the email template won't change, but the rest sure can.   We've had others that

For instance, if your email template is something like this:

<EmailTemplate name="Certification Reminder">


GREETING $recipient.displayableName,


#if ($certification.expiration)  CERTIFICATION_FINISH $spTools.formatDate($certification.expiration,3,1).#{end} 






This might get rendered as:




CERTIFICATION_OPEN Manager Certification Q4 2017



ACME Administration

Your EmailNotifier could look up who this is being sent to (e.g. John Doe), and then look up their language:

In the case of German:

Subject: Erinnerung: ein Zugriffsüberprüfung braucht deine Aufmerksamkeit


Hallo John Doe,

Die folgende Zugriffsüberprüfung ist noch offen und muss abgeschlossen werden: Manager Certification Q4 2017

Dies muss beendet werden durch 12/31/2017

Vielen Dank im Voraus,

ACME Administration

In the case of Spanish:

Subject: Recordatorio: una revisión de acceso necesita tu atención


Hola John Doe,

La siguiente revisión de acceso sigue abierta y debe completarse: Manager Certification Q4 2017

Esto debe ser completado por 12/31/2017

Muchas gracias,

ACME Administration

Hopefully you get the drift.

Regarding your other comments.  EmailOptions are not always null, these can be set via API, BeanShell, Workflow, etc.  We also don't advocate extending or overriding SailPoint code by changing the EmailTemplate.compile() method.  This is definitely not supported, so do not go this route.

Hello Neil,

Thank you for your response, although I am not quite certain I understood. Are you proposing we conduct a search on the EmailTemplate for the values injected into the tokens to build out the initial list of arguments?

The issue I am experiencing is with the EmailOption parameter, as I am finding the it is always empty. I have triggered emails from Certification, Workflows, and Rules, yet when I log the '.getVariables()' method of the provided EmailOption parameter a null is always returned. As you can see, not having access to the original variables supplied to the EmailTemplate can complicate this solution quite a bit. If this solution has work for others in the past then perhaps it is dependent on the version of IdentityIQ; I am developing this using a vanilla instance of IdentityIQ 7.1p0.

In addition, how do we actually send the email. It seems to me the purpose of this method is to execute the logic to send the message, am I correct?

Think of this as a two pass template.  The first pass uses standard IdentityIQ product functionality to populate variables, as it always does.  In the second pass, the words in the rendered email template like "GREETING" are then replaced by the the localized message like "Hola" or "Hallo", etc.  The first pass is all standard IdentityIQ; the second pass is part of the custom email notifier.

I think you are expecting EmailOptions to do something other than they were intended.  EmailOptions are intended to control how emails are sent, and are really used pre-compilation - which is how emails are typically sent.  The methods you are calling are actually used when the emails are sent, and might be empty post-compilation. 

For sending emails, this is done via the context.  Heres an example:

  EmailTemplate emailTemplate = context.getObject( EmailTemplate.class , "Some Email Template" );

  EmailOptions emailOptions = new EmailOptions();

  emailOptions.setSendImmediate( true );

  emailOptions.setNoRetry( true );

  emailOptions.setTo( "" );

  emailOptions.setCc( "" );

  context.sendEmailNotification( emailTemplate, emailOptions );

Ah, I now understand your approach to building out the translated EmailTemplate object. You are proposing to replace the static text before and after each piece of dynamic text in the compiled email, instead of compiling a new email in the translated language and replacing the tokens with the dynamic text; the second method is what I was trying to attempt.

I believe we have a similar understanding for the EmailOptions class. I had always considered it to be the class which stores the arguments to be applied to the EmailTemplate. What I don't understand is why the object is being cleared before it is passed into the 'sendEmailNotification' method.

I am a bit confused with your proposed method for sending emails. The below method you are invoking to send the email is the same method we are implementing, so wouldn't this cause the thread to go in an infinite loop? Are you using a different implementation of the EmailNotifier class?


Another option:  the Enhanced Email Notifier in the SSD.  See

Hi ,

I have a requirement where I need to schedule an email to be triggered after a few days. Can I do that in IIQ? Is there any OOTB method to schedule emails in future date?




Hi @neil_mcglennon - is there any option to set "reply-to" using custom email notifier. Appreciate your inputs on this. Thank you.  

Version history
Revision #:
3 of 3
Last update:
‎Jul 28, 2023 02:24 AM
Updated by: