Create a list entry where the CreatedBy is a different account

This might seem link an odd request, and it's possibly a very tall order, but is it possible for a Nintex workflow to create an entry in a list, where the Createdby field is the account of a different sharepoint user which is somehow stored in a variable ?

I've been asked to create a mechanism where someone can email into the SharePoint system using a variety of keywords in the email, and have the system parse the email, and then create an entry in a sharepoint list, where the contents of various fields in the list is parsed from the email, and the list entry has a "created by" fiels that is holds the sharepoint account details of the person that sent the original email.

I'm not sure if there are other (better) ways of achieving this (I'm a fairly novidce SharePoint developer, and only have access to a SharePoint system via Javascript / JQuery calls into the SP Services API (and to Nintex).

There are several ways to impersonate a user to create items in lists. But the only one that works as a variable would be using credential constants. This means you will have to pre-save all users who will be using this app to a site constant. Which means providing passwords, and they will be out of date when passwords change. Not the best method to accomplish your goal.

As Lisa pointed out, we can update the CreatedBy field using object model changes, so it could be possible to update the field using a web service to update/create the list item and providing a value for the field.

I'm not sure. But I know when I worked with the SharePoint Object Model (using C#) we could set the CreatedBy to who we wanted. I would think you should be able to do the same through Nintex but again I'm not sure.

There are several ways to impersonate a user to create items in lists. But the only one that works as a variable would be using credential constants. This means you will have to pre-save all users who will be using this app to a site constant. Which means providing passwords, and they will be out of date when passwords change. Not the best method to accomplish your goal.

As Lisa pointed out, we can update the CreatedBy field using object model changes, so it could be possible to update the field using a web service to update/create the list item and providing a value for the field.

Could you also have it where you create a new people field and populate that with the name so it renders, and hide the created by field from the view ? I'm assuming the list item is being created by a system user as its being created by an incoming email ?

No Dan, because that would be too easy! Hopefully Paul, that Dan's suggestion would be a resolution for you as it provides a means of filtering and sorting just as if it was the created by field. I use a similar method for workflow status by created a custom field just for this effect. It may depend on what you need the to use the value for, but this seems like a good solution as you do not necessarily have easy access to "system" fields to a list item.

I have multiples of processes that are triggered by emails into SharePoint. To resolve this issue I created a new field in all of them called Requestor and when I receive the email into SharePoint I run a workflow which will populate the Requestor field using email from address and that will give me who sent the email.

The created by field sometimes it works sometimes it doesn't. What I have noticed is that if the user has activated their Mysite profile it works if not it says the item was created by system account so that's why I have a field that I can control.