Send Email in Workflows Errors with 400

Hello All,

I want to configure a workflow to send an email on an Identity Lifecycle State change.

I have managed to configure the workflow with the appropriate trigger and filters to ensure the email operation is fired on the appropriate change event. I have also managed to select the Identity (Get Identity) to read the information I want to include in the Email.

However, when I run Test Workflow and it gets to Send Email action, it generates an error “unable to send email: unable to send HTTP request: request failed: 400 - 400 Bad Request”.

The error is NOT generated if I remove the content of the ‘context’ box in the send Email action item and the email is sent. This is not a work around as I need to send content from the Identity record.
I have tried various content in the ‘context’ box based on the information in the provided docs but nothing seems to work.

I have also seen references to this error in other topics posted here that suggest it was a bug that has been fixed or I needed to include an @sailpoint.com address in the From and Reply To fields (which I have tried with no success).

Does this problem still exist for some tenants? Has anyone else seen this issue and found the solution?

Any help you can provide would be very much appreciated.

Hi Adrian,

I am able to reproduce your issue. I have opened a bug report with engineering to look into it. In the meantime, there is a workaround for this. Rather than use the templating context, you can use inline variables. First, delete you email action so you don’t get the error anymore. Then, create a new email action and use inline variables in your email body. For example:

That has fixed it!

Many thanks for the quick response and fix Colin

@colin_mckibben,

Could you confirm if the workaround supports a way for us to render the body using Apache Velocity? In the past we were able to use the quiet reference notation (e.g. $!email vs $email) to suppress the output of the reference if it is undefined.

In addition, could you also confirm if the workaround supports HTML formatted bodies? In my testing, it does not appear to.

Would love to know the status of the defect.

Some Apache Velocity code seems to work when typing directly in the Email Body, however, when using if statements for checking if a variable exists or not, we get another 400 Bad Request error.

Example of velocity code that works: #set ($mobile = {{$.getIdentity.attributes.mobilePhone}})
$mobile

Example of velocity code that doesn’t seem to work(but works in regular email templates):
#if($mobile)Mobile Number: $mobile #else Mobile Number is missing #end

(BAD REQUEST 400 if no value, works with value)

Just an update. The issue with the context variables has been fixed. Please let us know if you continue to see issues.

Hello @colin_mckibben,

Unfortunately, I am still seeing the same issue persist.

Have you tried deleting the email step and adding it back? It might be a caching problem.

I tried creating a net new workflow, but it still errors out with the same response. I have attached the workflow and an image of the test result. Perhaps I am doing something else wrong?

Workflow.txt (1.2 KB)

I just identified the cause. The UI saving the context attribute as a JSON string, not a JSON object.

For Example:

			"Send Email": {
				"actionId": "sp:send-email",
				"attributes": {
					"body": "Hello ${var1}!",
					"context": "{\"var1.$\":\"$.getIdentity.attributes.displayName\"}",
					"recipientEmailList.$": "$.getIdentity.attributes.email",
					"subject": "Test Email Notification"
				},
				"nextStep": "success",
				"type": "action",
				"versionNumber": 2
			},

Should Be:

			"Send Email": {
				"actionId": "sp:send-email",
				"attributes": {
					"body": "Hello ${var1}!",
					"context": {
						"var1.$": "$.getIdentity.attributes.displayName"
					},
					"recipientEmailList.$": "$.getIdentity.attributes.email",
					"subject": "Test Email Notification"
				},
				"nextStep": "success",
				"type": "action",
				"versionNumber": 2
			},

I believe this is a UI issue, as I created the workflow through the UI. Correcting the JSON file and reimporting it resolves the issue.

Thanks for identifying it. I’ll communicate this back to engineering.

Looks like I jumped the gun. The fix is not yet released in production. It will be rolled out soon.

Hey Colin,

Do you know when this fix will be rolled out in production?