'@' in email is getting replaced with '+' when assigned to description field in inbound email

shri5
Mega Guru

'@' in email is getting replaced with '+' when assigned to description field in business rule.

we have used following code while assigning value

 

 

inc.description = current.u_description.replace(/<\/?[^>]+(>|$)/g, "");
5 REPLIES 5

Robbie
Kilo Patron
Kilo Patron

Hi @shri5,

 

The email address and value can easily be mapped within your inbound action as follows:

//You can map to any field from the description field, or as below to the comments field

current.comments = "received from: " + email.origemail;

 

To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Helpful.

 

Thanks, Robbie

Hi @Robbie,

 

Sorry for the confusion, this code is written in business rule to auto create incident when new record is added in that respective table.

 

Thanks for your reply.

 

Thanks,

Shrikant.

Hi @shri5,

 

No worries.

So, to clarify, you would like the business rule to copy the value from the 'u_description' field into the newly created incident 'description' field. In addition, the 'u_description' field contains an email address eg: abc@abc.com. 

Is that correct? 

For further clarity, what type of field is the 'u_description' field? Eg String? And what are you trying to achieve via the regex? Assume this is to strip out the ''&#43;' value that is being displayed.

 

To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Helpful.

 

Thanks, Robbie

Hi @Robbie ,

 

Yes that's correct, we have a email inbound action to create interaction and there is a ui action to create incident, when we click in ui action incident should be created and value in u_description which is string field should be copied to description of incident.

 

While copying value to incident we are getting this error.

 

Need to resolve this.

 

Hope I was able to explain the scenario correctly now.

 

Thanks,

Shrikant.