change the user ID in the Fusion scenario

[#1]

Description -

How would you like the feature to work -

 attempted testing to change the user ID in the Fusion scenario, but it can't be updated. The Fusion Admin name appears because it is part of the API table.

The ownerID represents the Primary Contact, which is separate from the enteredByID field, and therefore, it can't be used to override it.

Current Behaviour -

 Workfront API does not currently support passing "Entered By" information for these types of calls. The API does not have the capability to act on behalf of another user when making requests, meaning that any changes, updates, or requests made via API will always be attributed to the user through which the connection is established (in this case, the Fusion  Admin).

[#2]

I would very much like it if this were easier to do in Fusion. Until then, these should get you started. Implemented in my instance because I needed Fusion to attach variable approval paths when issues were submitted and having the receiving team unable to tell who had actually asked for approval wasn't acceptable.

Audit/Ethics Note: This does not completely obscure the audit trail, which is why I'm comfortable using it in this instance. In the System Activity feed, you'll see it appear as <Fusion Integration Account> changed the status to <approval path triggering status> and submitted this to approval on behalf of <user>' for my sample below. What you're doing here is telling the Fusion account to 'log-in as' the person, but you will still be able to tell the actions taken by the Fusion account apart from real actions taken by the user themselves. 

On that note, I've only ever used this trick for this use-case. Definitely suggest testing whatever way you want to use it to make sure you get a similar audit record. If you find it does appear to be the real person somehow, then add something to the scenario that makes a comment or leaves some record that a human being didn't take the action. 

1. Read a record - Get the Primary Contact's Email Address
2. Custom API Call - Use the URL 'login?username=<the email address from #1>
   1. Out of this you have a session ID for that user
3. HTTP module - Use that sessionID to PUT a URL just as if you were that user in their browser. The ID variables in the Request content are the ID of the issue that triggered this flow and the ID of the approval path retrieved in another module.
   1.