I have a form that requests the person name who is starting the form - IE the "Initiator Name":
The actual name of this column in the list is "Initiator Name" & its set up like this:
I want to send the Initiator an email notification back when this person chooses between three options:
So, when The initiator chooses OTHER i want them to get an email back telling them they chose other & that once they know what the decision is (IE Scrap or Heel) they should update the form to reflect this.
I thought the best way to do this would be a flexitask so that i can do a Nintex approval form that links them back to the form with the option to change the status from other to either Heel or to Scrap ( i have this style working well in other areas)
However, i cant figure out how to get the initiator name into the "assignee's" box in the configure actions box in the Flextask.
When i click on the book i get this page which will allow me to lookup "Initiator Name":
But when i add it i get an error:
Am i being a bit dense or am i missing something?
Is this the best way to go about it?
The reason for going down this route is that i want the initiator to be able to easily get back into the form & update it. As mentioned i have been able to configure a Nintex approval form update to work really well in other areas (so much so i even impressed my local techie/guru type!!) so it seems a good idea to enable the initiator to get back where he started via clicking on the link on the approval email.
Unless there is a better way of enabling the initiator to get back into the form without having EDIT facilities in the list/form entry page - which i don't want to do.
Solved! Go to Solution.
i think this may be overkill.
This workflow starts on item creation right? Can you not just use the sharepoint column "created by" or the workflow constant "initiator" to send an email and inside the email body insert a link to the item (using item URL)?
Trouble is that non of the items in the lookup list seem to work. I get an error against all of them
It is important that the initiator gets back into the form & is able to save the changes.
Your cool trick with the Form will work fine - i just need to be able to send that form to the document initiator.
Is there any other way of getting back to the initiator - maybe with a separate "task" in the workflow?
Is a flexitask the only way of going about this?
have you tried a send notification as follows:
Message body: item URL
What error do you get when you do that? we can easily make the item url into an edit item url if needs be.
There is something else.
The reason that i have had to include an initiator name is that the form before this change could be started by anyone. We have generic "universal" network logins here so that the large number of people without email can log onto the network & thus can therefore create a form anonymously
I want to stop this as it means that the default "created by" column is populated by the network log in credentials rather than the individual. The only way to resolve is to have an "initiator" column that must be filled in on the form.
Its another one of those weird things that i have to take into account when building these types of forms & workflows.
In answer to your last question - i tried this:
But it wont let me publish - i presume because initiator name isnt being recognised as a person on the groups email list.
That in essence is what the problem is isn't it? I want it to look at a list column & not a group email list...
I guess it needs to work in the same way the the "insert Reference" feature works?
OK I got you so you need to have the initiator as a person field in your list - do you have that? note you cannot "type" in that assignees field when you want to look up to an item reference or common property > you have to use the address book and select it (it will then appear underlined and resolved).
I did blog about the edit item actually - see the comments below it in case there is an easier approach:
If you are getting the same error for all items in the Lookup, can you try with new Flexi task freshly added to the workflow?
Sometimes if the task is copy past from an existing Flexi task in the workflow, it tends to act wired.