Add <<Current User>> token to "Owner" dropdown on the Job Starter/Work Request Form (VSTS 154422)

Rockell B. (Aprimo Consultant) 2 years ago in Productivity Management updated by bart.theys 12 months ago 17

In the Job Starter, set the currently logged in user as the default owner rather than having to pick themselves.

Work Requests Configuration

Thank you. 
Our client will only go into production later, so we hope to make use of this feature


This is available for participants in the Early Adopter Program for the new Work Request.  We hope to make the feature available to all users late November.

Hi Amelia,
Can you elaborate on where to find this value? For our clients, I do not see <<Work Request Submitter>> in the dropdown lists (Owner or Administrator). I also do not see this mentioned in the release noted of Release 100. 

This has been implemented as part of Release 100.

The Owner and Administrator can be set to <<Work Request Submitter>> which will be at the top of the entire list of users.

In Progress

This work has started.  

Summary of how this will behave.

  • We are adding a new token of <Work Requester> that can be chosen as the default for the Activity Owner and/or Activity Admin fields. 
  • If you set the default to be this token and the field(s) is exposed on the request form, then the field would default to the currently logged in user (the Requester) but the field would be editable so they would be able to change it to a different user if desired.  
  • If you set the default to be the Requester but do NOT expose the field on the request form then when the request is submitted the field will be set to the requesting user in the background. 

The field will still allow you to set a specific user as the default as you can today.  This is just a new option.

This feature is being done as part of the new Updated Work Request feature set so you will need that feature active to get this enhancement.  That feature is currently in EAP but should move to GA for all customers in September or October.

It should also be noted when it's released that allowing users to be Activity Administrators will automatically make them the Project Manager and give them Project, Edit domain rights.


Our plan is to work this into the updates being done with Work Requests around usability.  However, there are a few different ideas combined into this thread.  So here is what I am suggesting that I believe would handle these use cases.

Here is an approach we could take to solve both needs but keep this simple:

Add the ability to pick a token of <Requester> as a default for the Activity Owner and/or Activity Admin fields. If these fields are exposed on the request form, then this field would default to empty and the Requester has to select someone (could be themselves).  If the field is not exposed to the request form, then when the request is submitted the field is set to the requesting user in the background.  I think in most cases if you are setting the Requester to the default then you do not want them to change it so then you will not expose it.  But if you do want to allow them to pick then you probably want them to make a conscious choice for these fields and not have it default to anything.

What are the thoughts of this group on this approach?

that makes sense and would be a huge win....what if the <Requestor> is a contributor user (most of the time it is)...does that mean that contributors can now be owners/admins? if so does that mean that a contributor can also now be a project manager (since the project manager is defaulted to the activity admin) just a thought? will the owner/admin/pm field show "<<Requestor>> or be translated to the actual requestor's name? 

That would meet our business needs but I have one clarifying question:

- If Owner and/or Activity Admin is displayed in the request form, the field would be blank and required

- If Owner and/or Activity Admin is not displayed in the request form, the field is set to the requesting user when the form is submitted.

Would there still be the ability to default the Owner and/or Activity Admin field to someone other than the requesting user and not display the field?

Additionally we feel a need to have an option to pre-filter these lists. Often, not all users in the system are suited to act as admin/owner and so should not be selectable. Today, you can use a filter during configuration of this form, but you cannot automatically apply a filter to the selection list as presented for the requestor. 
Related to above comment of Christine: I think the problem is that both 'Owner' and 'Project Administrator' cannot be left blank in the activity default configuration. Would be great to have an option 'empty' there and only make the field mandatory when the form is actually completed by a requestor. 

Same for us. Some of our end users are complaining about limits on a drop down list. Pre-filters would simplify lot their work.

+1 for Pre-Filtering lists: we get so many users claiming system issues because they don't see their names due to truncation.

We specifically didn't want this option because it doesn't force the requester to choose something.  

We wanted them to have to consciously choose a name to proceed.  

If you add it as a default, we'd like to be able to "opt out" of it.

If there was a token user << Work Requestor >> that would give the flexibility to default Owner and Activity Admin to the requestor like and Activity defaults to or set another user if business process demands it.