By default, the Select User field (or more precisely, Check if User Exists Using Email Address button next to it) on Submit Incident (Advanced) form only accepts user's primary e-mail, not user's name. There have been questions about why it works like this and how to make it work with user's name.
The simple reason behind this is that it is supposed to be a simple and quick input field and this works best with unique identifiers (which in case of ServiceDesk/Workflow is user's primary e-mail). When searching for users by name, it is not uncommon to get multiple results and having a popup for clarifying the correct user would be functionally close to or same as the already existing Search for the User subdialog.
However, Submit Incident (Advanced) form is even in ServiceDesk 7.5 an open project name SD.Feeder.TechnicianIncidentForms and it can be customized to do things it does not cater for out-of-box.
Note that the steps in this article are considered a customization and this is not supported by Symantec Technical Support.
As a base, I will use the SD.Feeder.TechnicianIncidentForms project from KB article: Point fixes For ServiceDesk 7.5 SP1 (TECH212326). Same project for ServiceDesk 7.5, 7.5 MP1 and 7.5 SP1 should look mostly the same and identical in the parts we will be looking at.
I will use couple verbose additional descriptions and explanations (in quote blocks) about how relevant sections work or how to find or follow the flow for components/models, maybe it will help if you are not too familiar with Workflow. The idea and its implementation is to add functionality for searching affected user by name while making as few changes to the existing project as possible. There are definitely different ways fo implementing this and this is just one example.
The model doing the search behind that button is Model [8]: Check For User.
If you want to find this yourself by following the flow, open 'Primary' model and look at the 'Create Incident [1.7]' Form Builder component that is pretty much in the middle of the model (double click on it, or right-click and choose 'Web Form Editor') . The 'Check if User Exists Using Email Address' button settings (double click on it, or right-click and choose 'Edit Component') show that 'Path Name' is configured to be 'Check For User'. Going back to the 'Primary' model, you see a 'Check For User' path out of 'Create Incident [1.7]' form leading to Linked Model component called 'Check For User [1.59]'. This component links to 'Model [8]: Check For User'.
The section of this model that deals with actual user search that we need to be looking at is between 'exists' path out of 'Is there a primary contact [8.43]' and 'Map User to Process Contact [8.6]' component.
What happens in this section of the flow?
- 'SearchUser [8.32]' components searches for users by primary e-mail address using the contents of the 'Select User' field on the form. The contents of the textbox is now in variable called 'PrimaryContactDisplayName'. This returns a Collection (Workflow name for an array) variable with any users it found.
- After that, 'Configurable Collection Filter [8.41]' component goes over the returned users (as there can at least theoretically be several, especially as Search User component does a 'contains' search as opposed to 'equals') and filters out any users whose primary email does not match 'PrimaryContactDisplayName'.
- 'Users List =0 [8.122]' then checks if the result still contains any users (maybe all were filtered out). If users still exist, flow continues, otherwise flow goes to exit the model without finding matching users.
- 'Initialize User Location [8.35]' does not really have an impact on the search part, it is just located here for some reason.
- 'For Each Element in Collection [8.55]' is a typical Workflow loop component. In this case, it goes through the remaining results one by one and does a check with 'Text Equals Rule [8.56]' component for whether the primary email of collection element matches 'PrimaryContactDisplayName' ('Select User' field contents from the form). As soon as this matches, flow goes out of the loop to map user and do all the other stuff it is supposed to do.
Now, to keep as much original components as possible intact, I chose to simply add another search and checks for the user by Display Name after the ones that do the same with primary e-mail address. Display Names are mostly unique but at the same time it is not uncommon to have people with the same name. By following the exact same logic as primary e-mail check described above, first match will always be selected. Search by First or Last Name can be done but that would require more complex changes as both first and last names are in most cases not unique.
1. Make a copy of 'SearchUser [8.52]', 'Configurable Collection Filter [8.41]' and 'Text Equals Rule [8.56]' components. The usual copy-paste functionality whether from right-click menu or Ctrl+C and Ctrl+V works fine in Workflow Designer.
2. Connect newly copied 'SearchUser' and 'Configurable Collection Filter' components on the 'Not Found' path of 'SearchUser [8.52]'. Connect the outgoing path from newly copied 'Configurable Collection Filter' to 'Users List =0 [8.122']. Connect the 'Not Found' path out the newly copied 'SearchUser' component to 'Error On User [8.23]'.
3. Similarly, connect the newly copied 'Text Equals Rule' component on the 'not equals' path of the original and connect its outputs: 'equals' to 'Map User to Process Contact [8.6]' and 'not equals' to 'For Each Element in Connection [8.55]'.
To make these confusing descriptions simpler, the new or changed connections are the red ones in this screenshot:
4. Edit the new 'SearchUser' component and in Inputs tab Input section remove the 'PrimaryContactDisplayName' from 'Email' and add it to 'Display Name'.
To remove a variable from parameter, click the '...' button on the right of the parameter (Email in this case), select the variable to remove and click 'Remove'.
To add a variable, click the '...' button on the right of the parameter (Display Name in this case), set the 'Value Source' to 'Process Variables', click 'Add' and find the variable (in this case 'PrimaryContactDisplayName') in the 'Select Variable' dialog.
5. Edit the new 'Configurable Collection Filter' component, in 'Configuration' tab 'Filter' section click '...' button to the right of 'Filter Model'. Edit the 'Email Equals [5]' component in the model that opens and change the 'Compare Variable' from [Element.PrimaryEmail] to [Element.DisplayName].
Click '...' to the right of 'Compare Variable', select 'Element.PrimaryEmail' in 'Value From Process Variables' list and click 'Remove'.
Now the list will be empty. Click 'Add' and find the 'Element.DisplayName' in the 'Select Variable' dialog. Note that you will need to expand the 'Element' variable for this.
6. Edit the new 'Text Equals Rule' component and in 'Evaluation' tab change the 'Variable Name' from 'UserToCheck.PrimaryEmail' to 'UserToCheck.DisplayName'.
7. Save, test, publish.
This is a Webform type project, so it can comfortably be run in Debug for testing. Note that actual incidents will still be created if you submit in the form even when running this feeder in Debug mode.