I would love to connect user names and the custom forms. That way when submitting a project, the requester can choose the users within a custom form and those users would be alerted that the request is submitted or project created.
35 Comments
Former Community Member
8/9/18
Hi all, since this idea has reached the 45 votes threshold, the idea status will be updated in the next few weeks. In the meantime, the Product team has the following question - what values you would need to define for automatically pre-populated user names in a drop-down list, and whether you would expect those values to be the same as or different from user names/labels.
To be more specific, when a custom field of drop-down display type is created today, by default the value for each option in the drop-down is the same as the option label. Though you may need the value to be different from the label. As a friendly reminder, values are used in calculated fields and value expressions. Thanks !
I would like it to work similar to the field Sponsor or the field Assigned To on a project. The field would pull users names from the users in the "People" tab on the system. The displayed values would be the concatenated first name and last name (or if it is stored somewhere hidden, the full name).
I hadn't seen that this had passed the threshold, that's great. In response to Mariam's question: for the sake of user-friendly reporting, I would recommend the parameter label and value both be set to the user's name.
At first, I thought I would want the user ID as the value so we could create reports with filters like newCustomField=$$USER.ID, and someone can see all the objects in which they were selected in that custom field. But, that makes for really messy reports. E.g. "show me all the objects that have a value set for newCustomField and the user selected in each of them." In that scenario, you definitely don't want to see the user ID.
Then I remembered the wildcard $$USER.name which can serve the filtering need. With that in mind, I recommend the name as both the label and the value, since it can be filtered against with a wildcard and also provides friendly reporting. That said, I understand some large instances can have two users of the same name, and that complicates matters for those customers.
I imagine there are use cases for both. Would it be crazy to have two? One that is "customUserName" and the other that is "customUserID", in which both use the name as the label, but only the latter uses ID as the value?
I voted for this idea, but it could quickly fall into the category of "be careful what you wish for." From a development perspective, it's easy to take a hammer to this and say "okay, here's your custom field that validates against the user table." But if your instance has hundreds of users, the first complaint is going to be "That's too many and too long. I only want to see users from specific companies or specific groups or specific teams or specific roles in this field." Those are legitimate user needs, but introduce more complications in how such a field would be executed.
That is a long way to say, I think a lot of careful thought needs to go into how this should work. And, once it's figured out and working well, I'd really like to see the same concept applied to validating against other object types, including projects/programs/portfolios. Companies/groups/teams/roles is another set - which are probably the easiest and most simple to create this kind of field for, since those are simple lists and don't have a lot of attributes to filter against.
Former Community Member
8/28/18
@William English, thanks so much for the great insight into this topic! You are absolutely right - this product idea needs to be carefully thought through from the aspect of different possible use cases and needs before adding the enhancement to Custom Form Builder. Depending on the scope and complexity of the enhancement, it may take significantly different development efforts, which is why the final decision has not yet been made regarding this idea implementation status and timelines.
This would be incredibly useful - if I was building this would add it as a new field type that you can choose when adding fields on a custom field (a lookup) - it would physically store an ID but show the default decode field (eg like project owner stored as a user ID but shows the name of the owner on the project, portfolio, approval etc).
In reporting would then expect to be able to go through the object to its detail (eg project:DE:NewUserField:Name) to access any of the individual items from the object that is linked.
Thanks a lot for the great idea and we highly appreciate your input in making our product better! This looks like very promising product enhancement and we will definitely consider it in future. Unfortunately, for right now, I’m marking this as “Not Planned”, as we won’t be able to deliver this functionality in the coming 12 months. At the same time, please continue adding your use cases to this topic, so that we can take those into consideration when validating the solution.
I'm definitely sad to see this marked as "not planned" with so many upvotes. Does "Not Planned" status mean it will be in queue until it does get planned or that it's basically cancelled?
Thanks for the comment and for following up the idea!
As I mentioned in the response, we are really interested in the idea and would love to implement it in future, so it is surely not cancelled, what "Not Planned" means is that we, unfortunately, won't be able to deliver it in the upcoming 12 months, but it will definitely be considered afterwards.
