• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1344
  • Last Modified:

Workflow Lookup on List won't send email after upgrade to Sharepoint Foundation

I have numerous workflows set up throughout our Sharepoint site that look up email addresses from a 2nd list based on the name of the person they selected in the form.  These workflows ran flawlessly before.  But ever since we upgraded our Sharepoint site from WSS3.0 to Sharepoint Foundation, these emails no longer get sent.  Instead the workflow errors out and says "The e-mail message cannot be sent. Make sure the e-mail has a valid recipient.".

While troubleshooting, I added an action in the workflow to log to history the email address I am supposed to be pulling from the list.  Doing this showed me that the workflow is pulling no information, in other words, the data being pulled was blank, so there was no email address at all.  I know for a fact that all of the lookups were created correctly because they worked perfectly fine before.  However, I also tried recreating the look up action to see if it would work and it still produces the same problem.

This issue is only happening with the workflows that pull email addresses from a 2nd list and not from the current item's form.  

Does anyone know how I can fix this?  This is a huge issue as no one is getting notifications now and some of these items are time sensitive.

Thanks for your help in advance.
0
deeayrian
Asked:
deeayrian
  • 7
  • 4
  • 4
1 Solution
 
colly92002Commented:
Check your lookup column - I would imagine this is at fault.  If this has no values in it when you try to edit it, then the lookup has broken, possible because the GUID of the lookup list changed when you upgraded.
0
 
sharepointguru14Commented:
Did you say you recreated the lookup and it still had no info? Seems that the lookup column did get messed up through the upgrade. I think reconfiguring this to the 2nd list and column would fix it.
0
 
deeayrianAuthor Commented:
In response to both, I apologize for my delay...I wanted to do some more troubleshooting.
To troubleshoot further....I created a new look up column and attached it to the same 2nd list. I updated my workflow to pull from the new look up column.  I got the same error.  I created a new item in the 2nd list and used that as the lookup choice and it didn't work.  So I recreated the 2nd list and linked it to a field on the main list, updated the workflow to pull from the 2nd list and associate it with the correct field on the main list and it still didn't work.  When I log the email address it's supposed to be pulling to the Workflow History List, it is blank.  Ugh!!
0
NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

 
colly92002Commented:
Your new column should solve any issues with the GUID that I mentioned.

Can you add a new item to the list and see if you can select an email adress from the lookup column?  This will prove that the column is working OK in the front end.
0
 
deeayrianAuthor Commented:
Yes,  I can select items from the 2nd list just fine when create a new item.  But for some reason the look up in my workflow doesn't pull the information....so I was certain it was the 2nd list with the issues...but creating a completely different 2nd list didn't work either.  

Workflow Lookup
0
 
colly92002Commented:
Its a while since I used SPD for workflows so I apologise if I've misunderstood, but it looks like you are joining:

Current item->New Buyer --------------------join to----------------TEST Buyer Codes & Names->Names

Is this correct?

Write the "New Buyer" value in your debug and make sure it has a matching lookup value.
0
 
sharepointguru14Commented:
is new buyer an email address?
0
 
deeayrianAuthor Commented:
On the form, the New Buyer field is a drop down linked to the 2nd list (TEST Buyer Codes & Name).  It pulls up the Buyer's name and it's assigned code number.

TEST Buyer Codes & Name list has 2 columns.  Column 1 is "Names" and has the Buyer name and code number that is selected in the form from the lookup field.  
Column 2 is "email addresses" which has the email address for that buyer.

So the workflow look up is configured to Pull the "email addresses" from the TEST Buyer Codes & Name list for the New Buyer that matches the data in the "names" column in TEST Buyer Codes & Name list.

I don't think the workflow look up is incorrect since it was working perfectly fine for several months before the upgrade.  But...you never know with Sharepoint. I've learned not to rule anything out.

Next in my troubleshooting, I am going to create a completely new workflow and see if the workflow lookup works with the same lists in there.  Stay tuned.
0
 
colly92002Commented:
Create a simple one step workflow and see if that works on the lookup before you create a full workflow.  

You are correct that Sharepoint is a bit of a nightmare - that is why I develop everything using code and visual studio solutions now rather than using SPD.
0
 
sharepointguru14Commented:
What I'm trying to confirm is if you are actually pulling the email address back or not. I'm assuming not since you say it's blank. Have you tried putting a log to history list action and logging the New buy Name as string and I right before that would set the email address value to a variable that you could also write to the log. This will show what the values are at least. If you have the values you expect to have then everything would work. I'd imagine you would see values that were incorrect or none at all which means that lookup is not retrieving the data correctly.
0
 
deeayrianAuthor Commented:
I have written the expected pulled email address to the history list and that is what is coming up blank, so it's not pulling the address for some reason and that is the problem.
0
 
deeayrianAuthor Commented:
Ok, so I created a whole new workflow with only 2 steps.  First step is to log to history list the email that I am trying to pull from the 2nd list and the second step is to stop the workfow.

Even in the new workflow, it still pulls up a blank value.  

So then I created a look up to pull from the TEST 2nd list I created during all this troubleshooting. (A newly created list with a look up from a newly created workflow) and it's STILL not working.  This is so frustrating.
0
 
sharepointguru14Commented:
OK so log the New buyer value to the history list. I don't think you are actually finding a match to get an email address. I would suspect when you log New buyer to the list so you can see what you are trying to find a match of you won't have a corresponding value in the lookup list.
Basically I think its a formatting issue from the lookup column to the display format that you are trying to match it to. I bet you are trying to match that column ID to its display name which would result in no matches.
0
 
deeayrianAuthor Commented:
Field ValuesWow, you are so right!  Why on earth is Sharepoint Foundation pulling the field and automatically including the ID number in it?  I never had this issue with WSS3.0.  See my screenshot below (I've blocked out my last name)  The first comment is the New Buyer field value it is pulling from the list, the second comment is what it's supposed to be matching it to in the 2nd list.  

So how do I get the ID number and other characters removed from the beginning of my value (ie. 64;# )?
0
 
deeayrianAuthor Commented:
SolutionAh ha....so I was able to fix it...and much to my surprise, this was not an easy find on the Internet.  When creating the lookup from the field, you must set it as text and not a string.  The string option automatically appends the ID;# to the front of the value, but the text does not.
0

Featured Post

NEW Veeam Agent for Microsoft Windows

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

  • 7
  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now