+11
I have a customer who would like the sender in the flexi-task to be something beside 'NintexWorkflow@...' because there are other systems that send out Nintex workflows. She'd like to be able to differenciate between the systems when the emails appear in her Inbox. If I change that to something more user-friendly, what else does it affect? We're here about 2 days from deployment time and I don't want to break the system. Can I put an alias there that still points to the old stand by?
Lisa
In the flexi-task, notification settings tab, you can provide a From address.
The From field sets the user or domain group that will appear as the sender of the message. This setting
applies to emails only. If no From user or domain group is specified, the From address configured in Global
Settings will be used.
+11
FIrst I did not mark this correct. I don't know how that happened.
Anyway, yes I am aware of those two things. But what I need done, is not use a person's email. I just want it to say something different but still go to the Nintex workflow that is set in the global settings. Example, say I want it to say 'New Budget App' instead.
You want the address to be the same from each site, but have a different display name in the From section when the email comes in?
+11
There are other sites that have different requirements. However, in this site I'm working on I do not want it to use the default sender. And whatever I change it to, I don't want it to affect other sites. I was hoping it didn't have to be an email address. Just an alias.
I see what you mean. I believe the only way to do that is to actually setup an alias in Exchange. Use that address in the action and not change the global settings. You can override at the action level to not effect other workflows.
But I remember in the old days doing something in an app like the following "burkslm <community @nintex. com>"
If you use the < > in the From line, is that allowed?
+11
No it removes it and replaces it with a ";". Dag, this should be allowed.
+11
The funny thing is I found out yesterday that if you put in an email there instead of just plain text when doing a lazy approval it does put the nintex email there in the reply email. That's great! But I'd prefer to put a non-email address in when the approval email goes out. It just keeps blanking it out.
+11
I created a workflow variable and used that variable in the 'From' and when I got the email it had replaced it with the Nintex email.
what was the value of the variable?
+11
It was text. Let's say "abc def".
I can set the 'From' to a made up email. Which I hate. It works for the flexi-task. With the email notification action it works but you can't reply because the made up email becomes the reply. Also, on an email notification it appears in the Junk folder.
So to summarize:
Flexi-task actions:
*Does not take text
*If you try to use a workflow variable and set to text it appears as Nintex email address in email
*Takes made-up email
*Replies to real Nintex email
Email Notification actions:
*Does not take text
*If you try to use a workflow variable and set to text it appears as Nintex email address in email
*Takes made up email
*Replies to made up email
*Email notifications appear in junk folder when 'From' is not Nintex email
I found similar results with some testing. Just note, as soon as you put a valid email in, however, the reply to will use that valid email address in its response. I think making up addresses in this way could work - but I do like the idea of creating valid Aliases in the system if that is an option.
+11
And I hate the fact that the notifications goes to the Junk mail. I don't want my customers having to go there to get notifications.
Yeah, I'd agree. You should be able to white list those email addresses in whatever Spam filtering system they are using. If you do go with the alias route, you should be able to white list those (or may not even need to). The process for white listing these addresses will depend on whatever appliance they have in place. It is sometimes possible for this to be a setting on the client side email as well, but each env. is very different and sometimes it needs set in both places.
+17
Andrew,
I did this as a test for what a user was wanting to do and it still sent an email from the system, even though I went in and set the from field.
Any other thoughts or is that overridden by the global settings.
What kind of address did you put in the from field? Adding an address should work, what Lisa needs is to put an alias and is interested in the display name primarily.
Here is her findings so far:
Flexi-task actions:
*Does not take text
*If you try to use a workflow variable and set to text it appears as Nintex email address in email
*Takes made-up email
*Replies to real Nintex email
Email Notification actions:
*Does not take text
*If you try to use a workflow variable and set to text it appears as Nintex email address in email
*Takes made up email
*Replies to made up email
*Email notifications appear in junk folder when 'From' is not Nintex email
You may be passed this, but what if you created an AD user just for this use. A user with the display name you want, with the email address you want. Log in as this user in SharePoint at least once to make sure the data gets in the user table - may not be necessary though.
Then use this user in the from field. It seems like it should work out as you need it.
+11
I don't think the AD admin group will allow me to create an AD account for just this one person's request. Although, I think this would solve the problem. This was a good idea!
+11
Good summary Andrew!
+6
This seems to work at design time at least:
Update: I'll merge the result here - it works.
+6
Worked for me. The key is to use External address section in the picker popup and not try to input the address directly.
+11
Does the email notification you allow you to reply to the email? You are actually getting the default NintexWorkflow from External Address?
I want it to behave just like the default NintexWorkflow email that appears, just with an alias.
+6
Yes, I can reply, but our default sender email is an unmonitored address, so no use substituting it for sender if we wanted to process replies. I hardcoded the From email.
That's exactly what I meant, awesome, thanks for the snapshots Alexey Krasheninnikov
+6
Do you expect the default farm's outgoing email settings to change? How often? If you use Export and Import, and store current workflow templates in a version control repository, changing the email is as easy as Ctrl+H in a decent text editor.
I think hardcoding the actual address or a dedicated address should not be an issue for email processing.
+6
I think an account just for being the sender would be overkill. But should it also act as a security context for some actions in the workflow, that could justify a 'service account' creation.
Moreover, I think that rather than sticking to some farm-level setting it's better to use a distribution list or a public folder for sender/reply to if you intend to process the replies consistently even when the farm undergoes reconfiguration or someone changes duties or leaves the company.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
