Using [ME] to Filter InfoPath Form Views Based on Form Metadata
Posted by Clayton Cobb on June 29, 2009
This is something that I ran into a while ago where I couldn’t seem to promote a field from my form into an existing Person/Group column in my form library. Even though the data in my field was correct (domain name or email address), I was unable to connect them due to the Publishing Wizard saying the data types don’t match. This happens even if you use a Contact Selector that has the AccountID attribute – it won’t match. So, I thought up using SharePoint Designer to pull the data from the promoted field in InfoPath and setting it as the value for an existing Person field. Doing it this way will only allow domain name (domain\username) and email address, but it works like a charm. Sure, you have a duplicate column with the same info, but you can just hide the promoted column from InfoPath in your View settings. Here is an article that someone else already wrote that shows how to do this step-by-step. I was going to write it, but someone beat me to it. =)
Create Personal SharePoint Views depending on an InfoPath field using [Me]
One thing to be VERY CAREFUL of is that when you use an SPD workflow to update a field, this is taken as an edit to the record. So, if your workflow is set to automatically run on edit of a record, then you will cause an infinite loop. To beat this, you have to put a condition on the Set Field in Current Item action that states “If <InfoPath promoted field> is not equal to <SharePoint Person Field>” or something to that effect and have an Else statement that simply “Stops the Workflow”. The problem is that the Person field consumes certain data (i.e. domain name) but displays other data depending on how the field is configured – the default is to show Name (with presence), which may cause the conditional statement not to work properly. You want the condition to stop the workflow if the Person field in SharePoint has already been set with the CURRENT info in the InfoPath promoted field. You can’t use the statement “If <SharePoint Person Field> is blank,” because the name may get changed in the form after creation.
Clayton's SharePoint Madness 
Dan Ashby said
Does this make the [me] filter work on a infopath form with WSS 3.0?
Clayton Cobb said
Do you mean as opposed to using MOSS? I’m not sure, since I don’t work in WSS 3.0, but I’m pretty sure it works in all versions of sharePoint 2007, because it is used in built-in views for lists like Tasks and anything with content management turned on. Did you try it?
YBBEST said
I am using the feature receiver(Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver ) to deploy InfoPath form. It will show as a content Type in the Site collection. I promoted a few fields in the InfoPath form ,I am using these fields in my workflow.However , when starting the workflow ,the value is not retrieved from the columns,it is always the default value.
If I deploy using the InfoPath directly to SharePoint , everything seems working fine. Can you shine some light on this? Is this the limitations of the XsnFeatureReceiver or I am missing something
Clayton Cobb said
YBBEST, I saw your thread on this topic on MSDN, but I didn’t reply, because I don’t build any forms with code, so I’m not able to help with XsnFeatureReceivers or anything like it.
Greg said
I am trying to do this in SP2010 with a reusable workflow based on a custom content type. I’m submitting an InfoPath form based on this content type to a form library, and one of the fields submitted is the AccountID. When my workflow runs to copy this field to my Person field, it refuses to copy. I’m not seeing any error message, and the other workflow steps run, but it won’t work. Does it have to do with the custom content type? Have you seen this behavior before?
Clayton Cobb said
No, Greg, I haven’t seen that before. YOu should use “Log to History List” before and after that step to be sure it’s running. I recommend logging the AccountId value in the first log entry.
Greg said
I tried the history list logging, and these entries aren’t being added to the log. And the workflow status on the library view shows up as empty (as opposed to Complete if I remove this step from the workflow). So it looks like trying to run the “Set Field in Current Item” is causing some sort of an issue with this custom content type.