Using the standard solution of autopopulating a person field with the current user(data connection with web service and the form load rule similar to this ) I discovered that the solution works fine for new items, but fails for editing items.

After debugging it a bit, it seems that the DisplayName, AccountId, and AccountType values behind the person field are essentially locked until text field is user populated with something and blurred or check-named.

I set up a button with a rule to write my own username into the field, so just plain static text to take the data connection out of the equation(though the data connection does work fine), and a second button with a rule to copy the display name into another text field.

Once the form has been brought up, the autopopulate does not work, first of all. Then if I click the filler button I described, nothing happens. If I use the other button to push the DisplayName after that, it pushes a blank to the text box. So DisplayName is actually empty. However, if I type anything else and then blur, whether it resolves in the AD or not, using the filler button still shows no changes to what is in the box, but using the other button after that will cause the invisible entry to resolve and my name is pushed to that other text box.

None of this is an issue when creating new items. However, these items are initially created by a workflow copying some relevant fields when a report is made in a different list. Then they are reviewed and handled, so the item never has a new form, only edit form.

There is clearly some kind of a bug in the SP/InfoPath javascript, though I have a sinking feeling this is by design as a "security" feature. Every other field works just fine with editing using rules, just the person field has an issue.

Has anyone else experienced this or have any insight?

  • I'm not sure if this will work for you but I ran into similar behavior in SharePoint 2013 so I decided to ditch the people field and use URL parameters kitmenke.com/blog/2013/10/31/…
    – Kit Menke
    Commented Nov 1, 2013 at 19:14

1 Answer 1


You might be able to work around it. You could have a simple check box field that defaults to unchecked and an additional person field that is unpopulated.

On form submission, the check box field is set. Then you have a rule that checks if the box is checked and if so, set the secondary person field to the current user. Then on submit, set the original person filed to this new field value, then clear the new field to account for additional edits.

I haven't tried it, but it seems like it should work.

  • Not sure how the person field JS would behave on submit so if the user entry into the field was not necessary to "activate" after submit for some reason, then something like your suggestion could very well work. But the issue with that is that users wouldn't see their name in the field and would think to fill it in anyway, negating the point of autopopulating. I've already coded a jQuery and SPServices solution for current user in Nintex forms that would work here (hits the web service for the user, puts the text in the div, and clicks the check names button), but that is a fragile hack.
    – AnalyticD
    Commented Nov 1, 2013 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.